Recorded live on twitch, GET IN / theprimeagen MY MAIN YT CHANNEL: Has well edited engineering videos / theprimeagen Discord / discord Have something for me to read or react to?: / theprimeagenreact
Stop watching powerpuff girls, greens are tasty. Go is like a bad attempt to replace cpp as a next c. Insluters of cpp should atleast do a better job than cpp. How can people who wrote c and unix do a worse job and make go. I dont know why people like go and java. Its like tom in large scale.
Thank you! I really enjoy doing this because it gives me a bunch of perspectives, I can think about them and argue with myself and with chat. It's a really fun time
Several years ago I did a Go rewrite of a Perl codebase of a task scheduler program and its utility programs used by an ERP system. The task scheduler is used by the ERP system to run reports and ERP processes at scheduled times, days, and dates. It was becoming increasingly difficult to distribute the Perl code due to its reliance on external dependencies. Go's single binary distribution is what sold me on the project. The ease of the rewrite and the ability to use Go's goroutines to implement per O/S process monitoring instead of the Perl version's status loop monitoring was great.
It's definitely not perfect, though what language is, but I do love Go. It's brilliantly simple, easy, efficient, and has a lot of excellent tooling built around it.
You should really check out some of James Coplien's talks, he works with shops that successfully rewrite their codebases every 3 years. The problem people have with rewrites, is that they don't do them often enough. The longer you wait to do a rewrite, the more of a pain it's gonna be. Rewrites should be undertaken when the relevant domain knowledge is still fresh, so that the lessons learned from building the last iteration can be transferred to and codified better in the structure of the next one. If no one knows why something is there in the original codebase, then it's already too late to have a smooth rewrite. It's literally the same dynamic as refactoring smaller chunks of code, except that smaller refactorings are forced to keep the overarching structure of the system the same instead of rethinking it as well. Focusing exclusively on small refactors just leads to the silly situation of having fresh clean code for an outdated/clunky system design. Rewrites are just the holistic logical conclusion of refactoring.
This outro resonated with me. I had a similar experience with Haskell at the end of my Undergrad, only to find there were no jobs for it that didn't require 10 years experience or a PhD, so I wound up at my current company mostly writing Java and Python, until getting roped into the Docker/Kubernetes ecosystem, which is all in go, so now that's 90% of what I write now. I do like it for its simplicity, but find it somewhat restrictive (less so now that we have generics), but I still find my perspective and problem solving instincts are still colored by my time with Haskell, and I imagine it'll be the same if rust ends up imploding on itself.
Go is just vegetables until you start delving into channels and goroutines, they are delicious. I feel like a lot of people just look at Go and think, it's just a C with GC and inverted syntax, without realizing how elegant and powerful the goroutines and channels are (CSP)
This. Only gripes were using struct{} in worker pools doubled overhead (deep in the reflect library every handoff was duplicating the object), and the lack of generics until 1.18. All the people complaining about Go error handling either : a) didn't have the foresight to write their own error handling b) worshipped uncle bob martin's minimal line rules and forgot about the other rules (a function should do one thing in one layer of abstraction) c) didn't have a language server installed with an autocomplete feature and were grumpy they had to write the same thing repeatedly d) junior devs used to only writing javascript or python happy path code
@@davidmcdonnel4831well the current error handling approach is still somewhat controversial. There are quite a few issues about it in go repo with solid arguments on both sides. I'm certainly not going to pass judgment on the current error handling solution - I use it as it is, it doesn't bother me much, but (hopefully) there's always room for improvement. The most unpleasant thing for me personally is when error checking is done several times in one scope in the following form: `if err != nil { return err }`. Really? This looks questionable for two orthogonal reasons: 1. Either it's poor error handling: no additional context is added to the error in the format `return fmt.Errorf("expect file to be writable: %w", err)` (as an example) 2.Either additional context is not important in current scope at all: all possible errors belong to one particular process in general, from which the error context will be clear even on stacks above. And then the repetition of the same constructions `if err != nil { return err }` looks excessive. And how am I supposed to figure out which particular case I'm looking at? Anyway, go has accustomed me to unhappy path and early return approaches and I use it effectively even in other languages.
@@user-zm3ys9ym3q I'm sure everyone wants to handle their errors differently, and there's a lot of flexibility. Golang has always had the ability to return multiple outputs which allows for errors to bubble up without using panic or try/catch. You could also use error channels to early cancel a unit of work from any stack depth. Breaking your app into layers, having error types specific to each layer (api, database, business logic, etc.), having an app wide logging channel for a fmt.Errorf that includes stack traces and other context, and another channel for application halting errors so you know when to gracefully terminate the process would be the most generic overall coverage (look into thread spooling for graceful failure logging). Just bundle it all up into a single object and append it to function arguments. Added benefit of being an entry point for a dummy test harness. You can use a closure like a try/catch/finally it just will be less performant than writing the error check and more hassle for a single error check. In general though, it's good hygiene to add context to errors right where they occur. Most developer time is spent debugging in the long run. Better to pay the toll up front.
Until you start hitting race conditions, and writing convoluted code because golang doesn't have futures or tasks that allow returning values from them and synchronizing on them, and don't forget to pass context.Context everywhere and make sure you handle it correctly.
@@zhamed9587 You are obviously way under qualified on this topic, and you're just making a fool of yourself. I would suggest reading "Do not fear first class functions" by Dave Cheney and watching Bryan Boreham's "An Actor Model in Go" presentation from Golang UK Conference 2016.
I used to work in company were we had to migrate from spring boot 1.5 to 2 and as a result we had to rewrite our entire microservice stack . it was a nightmare because we ended having two teams where the first team keep adding new features to the old code and another team that keep migrating to the new one , the whole process took us about 3 years to finish and deploy
go is probably my favorite language so far, i'm doing some projects in it for fun and i can see myself being productive in it, also the performance is pretty good
Go is one of my favorite languages because how simple it is, how robust the standard library is, and how few updates it gets. Learn a Go standard package and that knowledge will be viable for years. Big fan.
Look, simple language like Go lets you focus on the product, on deliveries. Compare that to C++. Should you use this feature, or that feature, east pointers, west pointers, consts? auto? constexpr? constexpr if? Move? Or just copy? Pointers or references? And virtual tables? And standard library? And templates? Shared pointers? What about unique pointers? Why not raw pointers? Inheritance? Composition? Abstract classes? Who owns this piece of data?! And modules, And everything under the Sun... and you spend more time with the analysis paralysis and days go by. Go is simple, there is only one way to do it, just do it. Go! DGAF, just Go.
C++ is complicated because it solves complicated problems. It's pointless to compare with a language that declared all the hard problems to be outside of its scope; of course that language will be simpler.
Most of your questions have clear answers: use the new features over the old ones that they replace, don't use raw pointers, avoid c-isms, don't use raw pointers, use smart pointers or RAII and for the love of Odin, don't use raw pointers.
@@elcugo I find raw pointers are often the best option for class members because they usually have the right semantics I want and aren't implicitly const, so they don't ruin the compiler-generated assignment operator and/or force me to use dirty hacks like std::launder. But I agree, _owning_ raw pointers have to die in a fire. In general I find this whole hemming and hawing about how complicated and awful C++ is to be vastly overstated in practice. I work with a lot of people with science backgrounds and little development experience. Juniors, essentially. We often do that thing where prototype code is written in python and later translated to C++. Basically all of them end up telling me how much python frustrates them and how much nicer C++ is to work with. "Oh but everyone will be paralyzed by indecision because the language doesn't force an opinion on how to align the */& with pointer/reference types!". It's ok, I do, and I set up clang-format to handle it and nobody has to think about it anymore. The compiler error messages are bad, that's true, but at least they don't happen 5 hours into a test because of a typo.
A straight rewrite is hard to justify unless the current code is so bad that you’re losing enough revenue to justify the cost (both the direct cost and opportunity cost). But a re-platforming can be more easily justified. If you do a rewrite as part of creating your “next generation” platform, now you can gain support outside of engineering by offering a better feature set that should help to bring in more revenue
Go is great for getting working done quick. And I enjoy that feeling at the end of the task. If there was a measurement for dev cycle to performance, Go would probably top that list, all other things being equal.
@@zhamed9587 I disagree. It's only an illusion if you determine work done by LOC, but then you have bigger issues. Go simplified high level programming much like what Rust does for low leveling programming.
@@zhamed9587 The most obvious thing that pops into mind is its concurrency/parallelism handling. The way it handles "classes" with interface and structs is also much simpler and more enjoyable DX. Deployment is much simpler as it doesn't require an interpreter (java) while maintaining cross platform compatibility (c#). Sure maybe it's concurrency is the only "real" thing it *bought*, but it also cut out the many ways to similar tasks. ie you iterate using for...range, regardless of whether it's an array, slice or map. Perhaps the most telling is the fact that Go is 25 keywords in total compared to 67 and 79, for java and c#, respectively. It's pretty much accepted that it's simpler; I don't think there's a simpler language that lets you do as much and gives you the same performance. You can even read all the comments below. Now whether simplicity is actually a negative or a positive is a whole different topic.
In Regards to Go: I'm stuck in Java for the forseable future due to my University not having updated our courses in forever - however, after having written a small service, unit & integration tested it and deployed it to prod with no hassle, nothing is going to prevent me from making Java Go - as in, implementing the features, or similar concepts, I really enjoy about Go. Newer versions of Java (after v. 17 afaik) got pretty good implementations of generics and functional features. So, don't mind me as I remove the entire "Exceptions" concept from Java as well as a shit ton of boilerplate through records, generic types, functional and behavioural patterns. Java sucks less when its less Java.
I love Go, such a simple language, with really clean syntax. It is a dead simple language and anyone can pick it up very quickly, however, I feel like Go sometimes tries too hard to make things simple, and they actually get more complex, like the critical lack of built-in methods. Why can't I have a Contains(array, element) on the standard library, no I fucking have to write it myself. It's not like it takes more than 2 minutes but damn is it annoying. Then there is Rust, it is so similar to go, yet it is almost a complete opposite. Rust is an extremely complex language with possibly hundreds of built-in methods for everything you could imagine, even more so than python, with a complex and expressive syntax, that will make it very clear what you are doing but also sometimes ends up with shit like Vec
you just described the exact reason why shifting to go from a Node and Js experience is tough. Some common string manipulation you'd expect, casting integers and decimals but like they purposefully not support it to make it more cryptic
Prime is literally the only objective person in the Go versus Rust eternal debate. Everyone else is just stuck in my-tribe-your-tribe mentality. Is everyone egotistical? Evolve!
Some people are just too competitive and RUST is a good tool for them to show off they do better than others... Btw he is like 99% of developers who love to shove hundreds of libraries into a project. BUT must be in RUST. 😉
@@jamesnewman9547 And most people don't even know all the bells and whistles of PHP. A nice one is the automatic initialization of arrays. $a['b']['c']['d']='e'; That statement just works and creates three arrays. Throw an exception in most other languages. So, no need to check if there is an array; just use the append operator: $a['b']['c']['d'][]=1; $a['b']['c']['d'][]=2; The first line would create an array of array of array of the array with 1. The second line would append 2 to the most profound array. I would not use PHP anymore though 😂
You can compile python into static binaries with nuitka. It will produce somewhat oversized binaries, but much smaller than shipping python in docker. Also startup times get way better.
@@arjix8738 I don't know what nuitka does but what pyinstaller does is essentially bundle an interpreter, extract everything to a tmp folder, and run everything there. It's a little silly tbh, and if you care about the startup times, all that unpacking makes it even worse.
@@isodoubIet Nuitka is a very cool python translator it replaces the interpreter loop with hardlinked calls to the functions that would have been called by the bytecode. If you have never tried it and you use python in production - you should try.
Go is my favorite language, because its just super productive. Its indeed not sexy, but when you just care about getting the problem solved, its your best friend.
My biggest lesson during a language transition: Use a newer structure but make your outputs match exactly, even the weird bits and refactor after you’ve moved off the old bit. Also, find a way to do it incrementally. A hard cutover will take 10x longer than replacing 1 endpoint/query/service cal at a time.
It depends on scale and context. Huge rewrites taking months to finish (and to finally get something usable at all) are problematic. But otherwise, I'm more of a pro-rewrite person. I have so far rewritten 1 c++ and 2 python services in go. In case of c++, just better db client has made huge difference (pgx with statement caching and connection pool). And local results caching (very easy to implement in go) has made even bigger difference. I could do the same in c++ theoretically, but I think it was just faster to rewrite it completely. Besides that go has other advantages like tooling, safety and simplicity. And in case of python it was to gain speed and reduce memory footprint. And to join codebases in the other case. In general if there is some problematic component/service (okeyish most of the time, but sometimes not so much) and it's known how to solve it a better and more robust way, then I would be for rewrite instead of fixing and babysitting it repeatedly.
For whatever reason, your voice sounds like Fry from Futurama when you're reading. I'm sorry, I don't know why I felt the need to bring that up, but I just keep noticing it. XD
For reference: Domotic application: Python: 3 years of development by a team of 10, delivery not implementing 100% of the features, slow and crashing. Totally unusable. Go: Almost a week of development by a team of 1, system trialed in production (yep), 120% of the features, speedy, actually used.
I've been looking at Golang a bit recently, and I'm considering switching to it. - It's got easy, clean syntax - It's not too different a paradigm from what I'm used to (JS/TS) - It's pretty fast
The struct-align thing is readable IMO, but the real issue with it is that sometimes adding a single new field ends with a lot of lines of diff. Go is not super-sexy but it gets shit done and is a great tool. And it's easy to onboard new people.
I love go for it's simplicity and the fact that it's cross-platform. Tried Rust but it has a steep learning curve and I have trouble to understand some of that language. Maybe it's because I didn't code in C before.
I was listening to this in the background not watching the video. "This blows my mind that you could build a backend in scratch." I thought this was some sort of hobby project where someone was actually rewriting their back in Scratch, not in Go from scratch. Big difference. It took me too long to realise that he wasn't talking about writing backend code in a coding language aimed at primary school students.
The single binary reason is a pretty good one. I was looking at static site generators a while back and Jekyll always made various lists for popularity. I went to install it and saw I needed Ruby, RubyGems (and the gems that Jekyll needs), gcc, and make. I then looked at Hugo and saw it was a single binary (written in Go) that didn't require any installation. I kicked Jekyll to the curb and went with Hugo.
The language doesn't matter so much if your CI anyway runs containers for jobs/steps etc. All what matters is that you write clean modularized functions, test them and ship them in a container. Of course Go/Rust are nice because they boil down to a single execubtale which you need to download for your system. So if you get the right executable for your platform, you can also just get the container and run that, and everybody will be happy. A container offers even more benefits, because you can deliver at the same time config files and other stuff with the tool you run etc etc. But I agree writting in compiled static-typed languages is better as you are full-speed and can even containerize as well at the end.... Go on the other hand needs more boilerplate for CLI tooling out of the box than python out of the box with its standard library.
Doing a rewrite can be a great way to learn, but don’t count on it if you need to be finished in reasonable time and depend on getting things right. One of the hardest things for beginners and novices and probably even experts is to look at a piece of software and realize how many people it took how many hours to incrementally build the mess in front of you. If you’re not that many people and do t have that many hours and try to build it in a single piece you’re in for trouble. You could always try to build a piece, and then another and then another and maybe someone else will build a piece and eventually you’ve got something nice. This is advice from someone who has a strong urge to rewrite almost any piece of software I encounter. It’s like an itch I want to scratch. Not that I work with either ”go” or ”scratch” or even web stuff. Do you know what the worst part is. Just writing about it makes me want to sit down and rewrite something…
The thing that pushed me to learn Go was the goroutines because I couldn't do parallel calls for a web scrapper I was working on at the time. Since then I felt that it's more Pythonic than Python itself.
I took a look at Go before getting into Rust and it is true, it is shockingly easy to learn. I really felt that in a couple of month you can code fast with it, perhaps you won’t be a Go expert but coding fast yes. Still, 10 days is a bit sus (I left Go for Rust because I need a low level lang in my toolbox)
I just wanted to point out that we wrote our whole product from scratch 3 times in the last 6 years. why? because we learned from our mistakes and wanted something better every time.
I've seen so many videos about how great go is that now when I hear "nobody hear loves go", I add in my head "we just love using it because it's so great". People never talk about how go failed them and has this stupid thing for why it doesn't work for some use case they'd want. They just say something like "I don't love go, but it's awesome and definitely weapon of choice".
I only discovered Go a year ago, and have been loving it since. Been looking for interesting open source Go projects to contribute to since at work I'm required to use C#. After watching this video I went to have a look at digger, read the code, saw an issue and fixed. Had my pull request accepted and merged 6 hours ago.
@@TheMr82k Well, I've been programming for a long time (professionally since 2003 but self taught before the world wide web in 1993 when I was a kid) so the only new thing to me was Go. I picked that up pretty quickly by building some none trivial things in my spare time.
Im almost done with my first python book and am excited to either learn go or js. I found a JavaScript book from 2023 in the library so this is exciting to me because im sort of sick of reading off a glowing screen and the book is so new and untouched its like calling for me to use it 🤪. But go seems so exciting to learn for me too. I only want to focus on one language next so i can keep learning more python but have another language to compare and contrast for learning purposes. Im not really trying to speed learn a language either so whatever route i choose, i would like to take my time and really understand how the language works Any suggestions will be seriously considered. Thank you
If you want to learn a language that has several job offers, both JS and Go are fine, but I'd would pick Golang. If you're learning just for pleasure, why not try something really different? In this case I'd pick either Ocaml or Clojure. Good luck.
Learn French, and German, and Hindi, and Spanish. And if you want something fun learn Greek. Or just finish your first book… Ultimately, what reason are you learning to program? Do you like anything with charts/data analysis, desktop apps/games, quick projects, algorithms, …, then you’re wasting your time starting a new language. you will have to learn a new vocabulary, sentence structure, and complicated unique weirdness, just to get to the level you’re at now. Chances are, learning how to write tests will make you a better developer rather than restarting and learning how to implement a for loop or declare a variable. Build a project that will impress an employer, or follow a tutorial for an area that you’re interested in. You should get experience with multiple languages long term, but don’t switch after one book… that’s literally when the fun begins in that lang
Can I please at some point get the point of go? I've been using it for 2m now and I still discover some crazy "simplicity" that's in my way or I should've known of.
ok so, you have terraform, whose main purpose is to have infraestructure as code, then these guys make a wrapper, to use terraform, with a UI? I dont get it.
@@blenderpanzipyenv let's you do that, you can for exemple just write "pyenv 3.8 shell" and your current shell would be using python 3.8, you just need to download it beforehand.
@@blenderpanzi I wrote a shellscript to do that for me. It's essentially a clone of Python Launcher for Windows, but with minimal features. Similar to the comment below yours, I only ever need to do `py -3.8` to interact with that version. However, every time I show it to someone, they ask "why do you have so many Pythons that you need a script to manage them?" It's obviously Linux only, requires that you download the Python version beforehand, and also that you install them all into a single location. As you can imagine, that got tiring to manage myself. So, now I just issue a `py --build` and it does it for me.
i had that thing like prime too . absolutly hated the curly brace on the new line. now I am doing a day job working on linux-kernel. now i am getting used to it.
1:53 in i hit like. LOVE IT. LOVE IT. " Ooooh that's WHY you do THAT." JEEZ LOVE IT. 10:15 "Go is dumbest language possible" HAHAHAHA LOVE It. True. PS I love Go stuff. Do more. just Epic.
Person said they wanted { on a new line because they're a C# dev. C# supports both - Simply have a basic code-formatting addon to convert it to the format you prefer, and everyone wins :p
Anaconda is like the worst. Just grab the official package and pip install what you need. It'll take all of 5 extra minutes and it'll save countless hours of frustration when your packages installed with pip don't conflict with other packages installed with conda.
I'd love to hear about why you don't like allman. I used to only use K&R, then I got forced to use allman for a year at my job, and now actually prefer it. Is that just all preference? Then why do you hate is so much? Just memeing?
The main issue I have with go is that it makes writing applications easy, but it makes writing libraries hard. So the library ecosystem will never be as good as in more expressive languages. It does not have good math libraries compared to python, c++, or even rust because those were excruciatingly painful to write without good support for generic programming. And when Go's largest and most widely used web framework (Gorilla) issued a call for maintainers, the community literally let their largest web framework just die with no maintainers. Similarly, when Prisma stopped maintaining Prisma-Go no one stepped up to maintain it until Prisma sighed and picked it up again, while in Python there are several unofficial clients to choose from, including a production quality one recommended by the Prisma team. Imagine if JS let Vue die or if Python let Django die and couldn't maintain sqlalchemy without corporate support. That is just not possible because those communities have a high ratio of library writers relative to number of users (Python a bit less but still acceptable). But most Go writers are ecosystem freeloaders, who will use a package without ever thinking of the ecosystem below it.
So the end result is that you have to assume that all go libraries will be unmaintained in five years, even if they have thousands of github stars. I would be very hesistant to use any go library in production. So unless the application is literally so simple that you can write it easily using only the standard library, I would avoid Go
