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.
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.
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.
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.
@@МаркЧолак 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.
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 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.
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 😂
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
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
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
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 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.
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.
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.
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.
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 most hilarious thing is that who generally sponsors a rewrite is not knowledgeable of what has being rewritten. Like "wait, let's not improve what we have because I do not know how it works... let's do it from scratch without any experience whatsoever"... my 2 cents.
@@shimadabr I have not experienced that, it has been a lot more like person X that wants to show how great they are and want to show complex work for a promotion.
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…
@@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.
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.
One thing these click bait articles will never talk about is how much they have learnt in the original implementation. When they did the rewrite, they already knew the problem domain and the solution domain so well, and probably knew all the quirks for testing. The most time consuming part is not the coding part but figuring out the requirements, crafting the design and verifying the solution. The rewrite is fast because they already knew almost everything
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 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 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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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
The worst thing about Go imo is that it enforces that you have to remove imports. If you're testing some code out and that code happens to be the only thing importing something, it gets old REALLY quick...
You can setup your editor to automatically run 'go fmt', 'goimports', etc. upon file save, to tidy the code. (Vscode does this by default I think.?) When I'm testing different approaches/algorithms I tend to just write different functions implementing those approaches and keep them all around. (Then I don't have problems with unused variables, imports...) Also, instead of commenting the code, you can temporarily "disable" it with 'if false {}'.
it also imports them automatically if you use them in the code. I generally don't worry about imports and just reference it in the code when I need it.
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.
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)
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.
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?
Go is for people who have no time and joy in life. They have exhausted their capacity to learn anything new, so they force a language that regresses to the bare minimum of human intelligence. It also appeals to corporate capitalism because you can swap "human resources" at will.
Go is great and all the complaints about it's rough edges are odd to me. Every language has them. You just kind of figure out the patterns, maybe get burned once or twice. I think the biggest issue people have with Go is that they look at the language itself instead of it's entire tooling. For example, there are a lot of stuff that can't be specifically expressed in it's type system directly. This is actually on purpose. It's type system can represent the vast majority of what you would want to write. The rest can be produced using code generators and some more advanced checks can be enforced using `go vet` extensions. They are really easy to write and allow you to enforce whatever policy you want.
Try Chi first. If you feel like you need a framework, there's Gin. that said if you're making a simple rest api with a moderate amount of endpoints anything go based gets way too boilerplaty, id use something like fastapi instead.
“Go is like eating vegetables”🥕
Not tasty but good for your health.
Love it. 😂
anyone who complains about veggies not being tasty just doesn't know how to season food
I love veggies 😋
It's certainly been good to my salary and job opportunities
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.
@@_bradleystridertrue true. Seasoning lets me eat veggies I despise to this day.
Im convinced these blog reviews are just prime practicing his reading skills. I like it though, keep em coming, it somehow works
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
@@ThePrimeTimeagen is also quality, enjoyable, but lower effort content. Win win
and then I rewote it in Rust
And then rewrite that in CrabLang 🦀
@@jacquesfaba55 And then rewrite that in OCaml.
@@thingsiplay And then rewrite it in zig
it's gonna be rewritten in js anyway so why bother
And it took us 5 years to finish the project
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.
th-cam.com/video/rDSOpr3kuWE/w-d-xo.html
Ok and what was the performance benefit?
@@ericb7937 The Go program used less CPU time and memory than the Perl program.
@@KevinInPhoenix Don't forget it can now be maintained in Go instead of Perl
I want a compilation of all the "The name is a ...agen"s. It just feels good hearing those 😂
Someone make it, damn feel good
th-cam.com/video/rDSOpr3kuWE/w-d-xo.html
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.
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.
Nothing is perfect though! Go strikes a great balance for most things
Yea I’ve noticed that too. Strikes a good balance between low and high level programming
Do you need a Google account to develop in Go?
@@quarteratom Not to use it, no
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.
@@МаркЧолак 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.
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.
👏🏿👏🏿 beautiful
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.
@@isodoubIet and C doesn''t solve complex problems? What the actual fuck?
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 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.
If it's such a good language, why can't it support the superior style of bracing? Checkmate.
@@quarteratomjokes aside, I was like "what?" when I tried an else right in the same line of the if. Well, at least that is always consistent
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. 😉
@@jamesnewman9547ain’t no way
@@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 😂
golang and rust are not even in the same category, I don't know why people still compare them.
It really depends on the project.
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
th-cam.com/video/rDSOpr3kuWE/w-d-xo.html
go has Contains function in `slices` package: slices.Contains([]uint64{1, 2, 3}, 3) == true
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
exactly, productivity and performance, the only two things a company should care about.
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
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 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.
It just gives the illusion of doing work because of how verbose it is.
@@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.
@@likwidsage golang didn't really simplify much. What constructs exactly did it bring to simplify that aren't available in Java or C#?
@@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.
@@zhamed9587Go didn't bring any construct and that's the whole point of go.
One go a day keeps nodejs away
It took a few to fall in love with Go and not willing to return to node anymore
@@JohnDoe-mr6mq Are u sure? I've heard from colleagues that go is too easy and because its too easy it's unbearable to do hard things.
@@RaZziaN1 I guess it's their experience. Since I don't know your colleagues, I'd rather believe Google's success with it
@@RaZziaN1I completely agree with your take.
th-cam.com/video/rDSOpr3kuWE/w-d-xo.html
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.
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.
Exceptions are the best part of programming! They tell you that you don't know what you're doing.
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.
pyinstaller bundles python and it is like 10~15 mb of extra size
@@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.
I love Go, it's great ❤
Your signoff at the end describes my exact feelings between Go and Rust.
th-cam.com/video/rDSOpr3kuWE/w-d-xo.html
Love how dude in the chat just got roasted for preferring allman syntax 😂
That syntax is just so verbose. I don't need that much white space.
Go is pretty much modern C, devs hate it but end users like myself love it. Most of the time everything is a single binary and compilation is fast af.
Why do you say devs hate it? Go was the #8 Most Loved programming language in the 2022 Stack Overflow survey.
@@davidowens9597 2023 survey is out so you might want to check it out.
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
Easy and clean syntax? Ahahahahahahahahahahahaha
@@АлекСневарCompared to other system programming languages? Most certainly.
10:26 "Go is like literally the dumbest language possible"
And that's what makes it so good
yes and no - using interface{} everywhere introduces bugs and the data races and unsafe access to nearly everything is bad
Go is the most bored I've ever been writing in a language.
It also "just works", so i cant be too mad about it.
that's me in C# as well, i find Go to be very nice and i enjoy using it (even though i used to hate it)
Go was designed with a bunch of python projects in mind, it’s like Hack and php in Facebook, your python just slides into go like hand into a glove.
The most hilarious thing is that who generally sponsors a rewrite is not knowledgeable of what has being rewritten. Like "wait, let's not improve what we have because I do not know how it works... let's do it from scratch without any experience whatsoever"... my 2 cents.
Usually managers who thinks a rewrite is a magic solution to solve all the application's main problems.
@@shimadabr I have not experienced that, it has been a lot more like person X that wants to show how great they are and want to show complex work for a promotion.
After starting to use go, I notice I spend less time debugging over simple problems like a typo, or an unhandled error.
Even if people do not like how Go handle errors. I personally find it really easy to debug, and that's why I love it
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…
th-cam.com/video/rDSOpr3kuWE/w-d-xo.html
The Go hate is crazy, why are they hating on my little goober
coz that goober is a vegetable
Go over TS any day of the week. I have to deal wtih TS BS every f'n day at work. Barf.
10 years ago, hipsters used ruby, today they use rust
6:11 For python development i prefer pyenv + poetry, together they are like nvm + npm ;D
Oh, like nvm? I was looking for something that can manage different Python version installations.
@@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.
Using a scripting language for backend is madness
@@fb-gu2erit's called scripting for a reason it's supposed to call efficient code but it usually doesn't
@@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.
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.
A single binary means a hundred binaries. High level languages were invented to solve cross-platform problems.
Go is like a fat and funny lady friend to whom you always come back to 🤣
One thing these click bait articles will never talk about is how much they have learnt in the original implementation. When they did the rewrite, they already knew the problem domain and the solution domain so well, and probably knew all the quirks for testing. The most time consuming part is not the coding part but figuring out the requirements, crafting the design and verifying the solution. The rewrite is fast because they already knew almost everything
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 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 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.
I want to learn Go really bad because I'm super tired of cooking for a living and want an fast way out lol.
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.
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.
th-cam.com/video/rDSOpr3kuWE/w-d-xo.html
I'm currently in a project where my team is moving from python to Go.
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.
That's what I'm doing, goodbye Spring Boot, welcome Go!
This is actually a rewrite I can approve of.
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.
Go 💙
The outro is exactly how I am feeling about Rust in this period
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.
Depends on how old the architecture is. A full rewrite might be a well needed option.
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
Then become a maintainer yourself it's opensource instead of blaming everyone you should take a step to make it better
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.
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.
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.
th-cam.com/video/rDSOpr3kuWE/w-d-xo.html
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.
1:25 I have never had someone so succintly describe the difficulties of my work
Rewrite it, baby! Sometimes you can only polish a turd so much.
hi primeagen, i saw your course on front end masters. can i take the course even i don’t have knowledge in javascript/typescript?
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 love golang. I find it fun to write.
Also that naming at the end XDXD
"ohhhhh thats why you do that" man the number of times I've done exactly that with my own code.. 🤣
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
0:10 Nice mistake! "Why would anyone write a backend in SCRATCH?" Haha! Imagine. Its called zero-code.
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
Lorem Ipsum ironically quoted in context . Abbreviated Latin for "Pain Itself" (Delorem Ipsum) - full text by Cicero 60BC
I love Go
He knows rust people will be triggred, i mean look at the smirk😅
This is the first time that I saw your content, dude you sound like bill burr kkkkkkkk this is so good!
Most of the time software need rewritten from scratch. It's usually that bad. But you probably can't do it better.
agreed
Im teaching myself go now. Most of my experience thus far has been in python and c++. So far i rly like it
The worst thing about Go imo is that it enforces that you have to remove imports. If you're testing some code out and that code happens to be the only thing importing something, it gets old REALLY quick...
You can setup your editor to automatically run 'go fmt', 'goimports', etc. upon file save, to tidy the code. (Vscode does this by default I think.?)
When I'm testing different approaches/algorithms I tend to just write different functions implementing those approaches and keep them all around. (Then I don't have problems with unused variables, imports...) Also, instead of commenting the code, you can temporarily "disable" it with 'if false {}'.
You can just make them comments.
it also imports them automatically if you use them in the code. I generally don't worry about imports and just reference it in the code when I need it.
Isn't this like just a formatter issue that can easily be tweaked out?
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.
Man you must be incredibly divert if your first thought while learning a language is to add a PR
@@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.
At this point, I'd accept not having Internet for a month, if it would mean that Browsers running on Go / HTML / CSS become a thing.
Hey @ThePrimeTime, I love your videos, would you care to share links to these articles in the future?
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)
10 days? I can barely configure a python project in that time.
I wish you also provide the links to the posts or reaction items.
Rewrite is my middle name. Rewrote a bunch of Java microservices into Kotlin. It was worth it every time.
"Look at the thigh-gap in this code"
is a comment I cannot wait to use
So if I learn go lang , what kind of position am I aiming for?
th-cam.com/video/rDSOpr3kuWE/w-d-xo.html
It seems like Deno needs more time, but for any TypeScript lovers, it ships standalone binaries as well.
2:16 "ohh that's why you do that.. " ahahh
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.
@@marcioandreyoliveira thank you
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
@@conorx3 thank you. I need to keep focus
There's a great go book simply called 'the go programming language' co written by one of the guys behind. It's excellent.
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.
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?
Why Netflix recommends me films I already rated? Why not use the rating to understand what I like and recommend me something I didn't rate?
Go is for people who have no time and joy in life. They have exhausted their capacity to learn anything new, so they force a language that regresses to the bare minimum of human intelligence. It also appeals to corporate capitalism because you can swap "human resources" at will.
0:45 netflix had a rewrite?
I have almost formulated a drinking game out of your verbal habits
Is there an alternative to gems when using packages in ruby?
fr writing a solid backend is so much effort
Go is great and all the complaints about it's rough edges are odd to me. Every language has them.
You just kind of figure out the patterns, maybe get burned once or twice.
I think the biggest issue people have with Go is that they look at the language itself instead of it's entire tooling.
For example, there are a lot of stuff that can't be specifically expressed in it's type system directly.
This is actually on purpose. It's type system can represent the vast majority of what you would want to write.
The rest can be produced using code generators and some more advanced checks can be enforced using `go vet` extensions.
They are really easy to write and allow you to enforce whatever policy you want.
What do go devs here recommend for go framework? Echo or Fiber?
No framework needed
Chi with net/http package
Most recommend nothing, there are like 10 r*ddit threads about that a day
no frame work then Gin
Try Chi first. If you feel like you need a framework, there's Gin.
that said if you're making a simple rest api with a moderate amount of endpoints anything go based gets way too boilerplaty, id use something like fastapi instead.
What can GO do thst RUST cannot do? And vice-versa?
Doesn't the "Legacy" means "it works", as in Cobol, Fortran, C, C++, etc.