16 ms·

The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his p

The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his position, which is "you shouldn't use Go for production services" (he explicitly says this in one of his Go posts, I forget which one and don't have time to look right now). The better alternative to Go is Rust. Okay, sure, I'm willing to admit that in the examples presented, Rust handles things better. But Rust isn't a panacea. Rust is complicated and hard, and often it's not worth taking on that burden just to theoretically handle cases that rarely occur and even more rarely cause any problem. Programming is a means to an end, and the cost of using Rust (hiring, increased development time) is often not worth it. The reason Go is successful is because it's easy for companies to use to solve production problems with teams of varying expertise. Its stdlib is well-featured, its ecosystem is good. There's generally one correct way of doing things. The same doesn't appear true in Rust. For example, an _incredibly_ common thing to do in production code is to make a web request. In Go, there is no need for debate, you use the stdlib. In Rust, you have to use a crate, which requires a decision to be made. Even worse is the async story, in Rust you have to decide whether to use Tokio or whatever. That burden is just not present with Go. Btw this article should not be flagged and it's pathetic that people have flagged it.

ParetoOptimal 4y ago
> increased development time In my experience it is only increased initial development time. I find that initial development time is frequently conflated with development time overall. So obviously worse is better languages will be preferred.
weatherlite 4y ago
> The reason Go is successful is because it's easy for companies to use to solve production problems with teams of varying expertise. It would've never got to where it's at if it wasn't for Google, that's the most important reason why its successful.
draxil 5y ago
Definitely. Go and Rust both have strengths and weaknesses. And I think they both have a love/hate dynamic because they make pretty strong choices in their own ways, and so people react strongly in response. Personally I'm a fan of both.
cytzol 5y ago
> Programming is a means to an end, and the cost of using Rust (hiring, increased development time) is often not worth it. I agree with this. I learnt Rust before Go, and using Go makes me feel like The Oatmeal piracy guy[1]: "I'm not sure if I should use Go to write this HTTP service. I'd lose immutability tracking, I'd lose compiler-enforced thread safety, I'd lose the powerful type system, I'd lose the comprehensive error handling, I'd suffer from a million little papercuts, I'd have to use the weird date formatting system, I'd have to check nil pointers, I'd... ...oh, it's seven days later and I've already accomplished more writing networking servers and clients in Go than I ever have in years with Rust." This isn't to say the points raised about Go aren't true. They are true, and if a better language were available, I wouldn't stand my ground and argue their benefits, I'd switch to it. The last comment I happened to post on this website is about how Go is insufficient without its army of linting tools [2]! Yes, I'm incredibly happy to have learnt both Go and Rust as their combination has expanded my skillset and the range of programs I'm willing to write tremendously. But if someone said to me "you should just use Rust instead of Go for your production services", I'd think the "just" was doing some incredibly heavy lifting. An article that I'd like to see is one comparing the two languages for this niche (networking servers and clients), contrasting not just the language pitfalls but the third-party libraries necessary, the iteration speed, and the choices you'll have to make up-front. My guess is that the languages would be judged more closely together. [1]: https://theoatmeal.com/comics/game_of_thrones https://theoatmeal.com/comics/game_of_thrones [2]: https://news.ycombinator.com/item?id=30749921 https://news.ycombinator.com/item?id=30749921
- Thaxll 5y ago
  The problem with: "I'm not sure if I should use Go to write this HTTP service. I'd lose immutability tracking, I'd lose compiler-enforced thread safety, I'd lose the powerful type system, I'd lose the comprehensive error handling, I'd suffer from a million little papercuts, I'd have to use the weird date formatting system, I'd have to check nil pointers, I'd... None of the modern language do it beside Rust so every language are then bad?
  - cytzol 5y ago
    Sorry, I don't get what you mean. Could you elaborate or re-phrase?
prirun 5y ago
I haven't used Go or Rust seriously, but have written some Go toy code. This part of your post struck a nerve with me. I modified it slightly, to relate to Go's error handling, for me at least: > often it's not worth taking on that burden just to theoretically handle cases that rarely occur and even more rarely cause any problem. Programming is a means to an end, and the cost of [Edit] adding if err != nil to every line of code [/Edit] (increased development time) is often not worth it. I basically like Go, I really want to like Go, but as a Python person who has used exceptions with good success for 13 years in HashBackup, I can't see myself adding an if test to practically every line of Python code, just to catch an exception that might occur once in a blue moon. A lot of software is not so mission critical that lives depend on it. If that is the case, sure - add error checking to every line of code. But for a lot of software, IMO, it's too much work for too little reward. If something blows up in production in an unexpected way, sometimes that's okay. You log the problem, fix it, and it's fine. I re-read the Go error handling page before posting, because maybe it's not as bad as I had initially thought. Nope, still looks pretty cryptic to me: https://go.dev/blog/error-handling-and-go https://go.dev/blog/error-handling-and-go
- layer8 5y ago
  > If something blows up in production The problem is if it doesn’t quickly blow up, but instead silently corrupts data or causes other problems down the line that are hard to backtrack to that specific missing check.
  - prirun 4y ago
    But because exceptions bubble up the stack frame, there can be no missing checks. I'm not suggesting things be coded as: try: do something except Exception, err: pass If a piece of code is has a try/except, then it's because there is the expectation that it might fail and certain kinds of failures can be handled. If a failure is not one of the expected failures, then do a raise and let the exception go higher up. It's either going to hit a handler in the main program or will exit to command level. In either case there's a stack trace to see where the problem occurred. Exceptions tell you exactly where things blew up, whereas the "if err return" paradigm only does that if the test at each level adds identifying information. I've seen some Go stack traces. Talk about hard to backtrack: the ones I've seen go on and on. I understand it's because there are multple Goroutines running and each one has a stack trace, but they look pretty daunting to me.
icholy 5y ago
The content is mostly ok, but the title suggests that there's some obvious alternative to Go that we should be using. If he's implying it's Rust, then he's totally disconnected from reality.
- bovermyer 5y ago
  It's buried in the article, but I think the suggestion is "use almost any language other than Go" rather than Rust specifically. The takeaway - if you gloss over the ranting and look for the good bits - seems to be that you should choose a language that handles a lot of the boilerplate for you (e.g., no verbose error handling) and has FFI. It's not a bad argument, and it's making me think about how and when I use Go. For that, at least, it's worth reading.
- wperron 5y ago
  It's really not, and it's even saying so explicitly in the article.
weinzierl 5y ago
> "Even worse is the async story, in Rust you have to decide whether to use Tokio or whatever." I think this is going to change. I couldn't find the relevant blog post now, but I believe to remember there was an initiative to provide a standard async runtime.
- afdbcreid 4y ago
  No. Rust may provide some small async runtime for tutorials etc., but it'll never provide a rich async runtime like tokio because different people have different requirements from their runtime and Rust wants to satisfy them all. What is planned is to standardize the API: that is, provide common traits for IO, tasks, etc. so libraries can be runtime-agnostic and you can change your runtime by only touching Cargo.toml (hopefully).
sdfgdfgbsdfg 5y ago
I agree with this overall. It seems that C is a language/compiler/toolchain combo that lets you shoot yourself in the foot, but gives you enough access to stuff to be maximially performant in a random (i.e. not specialized) use case. (C++ is in this camp too). Rust is a language/compiler/toolchain combo that tries its best to not let you shoot yourself in the foot by presenting those footguns for you to fix up front, without giving up much of the access to stuff (C++ tried some things in this camp like destructors and smart pointers. GC is also something that's in this camp) Golang is a language/compiler/toolchain combo that lets you shoot yourself in the foot in some circumstances, and does not give you enough access to be maximally performant in every random case, but rather it seems to posit to give you opinions that will get you really, good performance in most random cases (if you need to tune the GC, for instance, you're probably worse off, like here: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...). Meaning it's making the tradeoffs of upfront complexity vs runtime issues, and Tim Toady vs The One True Way for you, because in the general case those are the most optimized tradeoffs. I don't disagree, especially when the closed-world ecosystem is good enough to not need to reach out to external tools whether those are via cgo or in the build toolchain. In general, I think that if you reach the point where Golangs admittedly major warts are hindering your progress you're doing better than most companies, so its succeeded in not getting in the way of progress at least until that point. In particular since the article keeps comparing Golang to Rust, for personal projects I do like the correctness of Rust, but some things are frustrating, like async being basically unusable without Async Drop, an uncertain future for completion apis, and apis that really want HKT but can't use them (yet?). I having to make up a lot of opinions that Go makes for you adds risk and uncertainty to a project where the most likely failure modes are not, in fact, those opinions. I'm excited for the future of Java, with Loom and Valhalla coming to address as what I see as two core problems of Java in particular and other languages in general. I'm also excited for the present of js/node.js/maybe Deno. typescript has become good enough that I also think it's a really good competitor to Golang in the "just write code" arena, especially since there's significant synergy between the front end and the back end to help with build tooling, validation logic, and programmer expertise.
closeparen 5y ago
>you use the stdlib * First you construct a request, and check the error on that * Then you "Do" the request and check the error on that * Then you check the status code (you did check it, right?) * Then you deserialize the response and check the error on that * Then you close the response body (you did remember to close it, right?) and check the error on that Actually making an HTTP request with Go stdlib is a many-stage process and it is very easy to screw up or forget one of the steps. I see it all the time. Actually I have seen outages related to people being too zealous and reporting errors related to closing the response body on otherwise successful requests.
- Cthulhu_ 4y ago
  > Actually I have seen outages related to people being too zealous and reporting errors related to closing the response body on otherwise successful requests. I kinda get it though, because the compiler or linters will show that as a warning or error going "bruh you forgot to handle this error", and as a perfectionist one wants to get rid of all of those. I mean IMO those should be logged anyway, if only so you get some data on how often it happens, if there's anything that can be done about it, and if it's harmless, to ignore the error - but make it explicit.
azth 4y ago
> The better alternative to Go is Rust Nope, a better alternative is Java/C#/Kotlin/etc. Those offer sum types, async programming, while being more productive than golang, and provide superior tooling and a superior developer experience.
- weatherlite 4y ago
  Why not Node? Or Typescript if you really have to have types? Or even plain old PHP/Ruby (for people that just use Go to build web backends) - doesn't Kubernetes kinda solve scaling?
beltsazar 4y ago
> For example, an _incredibly_ common thing to do in production code is to make a web request. In Go, there is no need for debate, you use the stdlib. And yet, Go's HTTP client doesn't have a good default [1] because of zero values, which are argued harmful in the article. [1]: https://medium.com/@nate510/don-t-use-go-s-default-http-client-4804cb19f779 https://medium.com/@nate510/don-t-use-go-s-default-http-clie...
Fire-Dragon-DoL 4y ago
I agree with you, however I think it's even simpler than that: the author is comparing Go to rust, but it's not comparing it to the places where it shines, that is, where Java, ruby, js, python are used. Now suddenly we go from a poor type system (Java) to a decent one in Go (this is my personal opinion). Or from no type system to SOME type system. On top of this, we are getting all the benefits of a compiled language. Essentially this is looking Go as a system language, while I think of it as an application language. Aside from that, the author is right in some ways.
goodpoint 4y ago
> The better alternative to Go is Rust No, the better alternative is thousands of different languages. HN is just hype-driven as usual and can see only Go and Rust.

ParetoOptimal 4y ago

> increased development time In my experience it is only increased initial development time. I find that initial development time is frequently conflated with development time overall. So obviously worse is better languages will be preferred.

weatherlite 4y ago

> The reason Go is successful is because it's easy for companies to use to solve production problems with teams of varying expertise. It would've never got to where it's at if it wasn't for Google, that's the most important reason why its successful.

draxil 5y ago

Definitely. Go and Rust both have strengths and weaknesses. And I think they both have a love/hate dynamic because they make pretty strong choices in their own ways, and so people react strongly in response. Personally I'm a fan of both.

cytzol 5y ago

> Programming is a means to an end, and the cost of using Rust (hiring, increased development time) is often not worth it. I agree with this. I learnt Rust before Go, and using Go makes me feel like The Oatmeal piracy guy[1]: "I'm not sure if I should use Go to write this HTTP service. I'd lose immutability tracking, I'd lose compiler-enforced thread safety, I'd lose the powerful type system, I'd lose the comprehensive error handling, I'd suffer from a million little papercuts, I'd have to use the weird date formatting system, I'd have to check nil pointers, I'd... ...oh, it's seven days later and I've already accomplished more writing networking servers and clients in Go than I ever have in years with Rust." This isn't to say the points raised about Go aren't true. They are true, and if a better language were available, I wouldn't stand my ground and argue their benefits, I'd switch to it. The last comment I happened to post on this website is about how Go is insufficient without its army of linting tools [2]! Yes, I'm incredibly happy to have learnt both Go and Rust as their combination has expanded my skillset and the range of programs I'm willing to write tremendously. But if someone said to me "you should just use Rust instead of Go for your production services", I'd think the "just" was doing some incredibly heavy lifting. An article that I'd like to see is one comparing the two languages for this niche (networking servers and clients), contrasting not just the language pitfalls but the third-party libraries necessary, the iteration speed, and the choices you'll have to make up-front. My guess is that the languages would be judged more closely together. [1]: https://theoatmeal.com/comics/game_of_thrones https://theoatmeal.com/comics/game_of_thrones [2]: https://news.ycombinator.com/item?id=30749921 https://news.ycombinator.com/item?id=30749921

Thaxll 5y ago
The problem with: "I'm not sure if I should use Go to write this HTTP service. I'd lose immutability tracking, I'd lose compiler-enforced thread safety, I'd lose the powerful type system, I'd lose the comprehensive error handling, I'd suffer from a million little papercuts, I'd have to use the weird date formatting system, I'd have to check nil pointers, I'd... None of the modern language do it beside Rust so every language are then bad?
- cytzol 5y ago
  Sorry, I don't get what you mean. Could you elaborate or re-phrase?

prirun 5y ago

I haven't used Go or Rust seriously, but have written some Go toy code. This part of your post struck a nerve with me. I modified it slightly, to relate to Go's error handling, for me at least: > often it's not worth taking on that burden just to theoretically handle cases that rarely occur and even more rarely cause any problem. Programming is a means to an end, and the cost of [Edit] adding if err != nil to every line of code [/Edit] (increased development time) is often not worth it. I basically like Go, I really want to like Go, but as a Python person who has used exceptions with good success for 13 years in HashBackup, I can't see myself adding an if test to practically every line of Python code, just to catch an exception that might occur once in a blue moon. A lot of software is not so mission critical that lives depend on it. If that is the case, sure - add error checking to every line of code. But for a lot of software, IMO, it's too much work for too little reward. If something blows up in production in an unexpected way, sometimes that's okay. You log the problem, fix it, and it's fine. I re-read the Go error handling page before posting, because maybe it's not as bad as I had initially thought. Nope, still looks pretty cryptic to me: https://go.dev/blog/error-handling-and-go https://go.dev/blog/error-handling-and-go

layer8 5y ago
> If something blows up in production The problem is if it doesn’t quickly blow up, but instead silently corrupts data or causes other problems down the line that are hard to backtrack to that specific missing check.
- prirun 4y ago
  But because exceptions bubble up the stack frame, there can be no missing checks. I'm not suggesting things be coded as: try: do something except Exception, err: pass If a piece of code is has a try/except, then it's because there is the expectation that it might fail and certain kinds of failures can be handled. If a failure is not one of the expected failures, then do a raise and let the exception go higher up. It's either going to hit a handler in the main program or will exit to command level. In either case there's a stack trace to see where the problem occurred. Exceptions tell you exactly where things blew up, whereas the "if err return" paradigm only does that if the test at each level adds identifying information. I've seen some Go stack traces. Talk about hard to backtrack: the ones I've seen go on and on. I understand it's because there are multple Goroutines running and each one has a stack trace, but they look pretty daunting to me.

icholy 5y ago

The content is mostly ok, but the title suggests that there's some obvious alternative to Go that we should be using. If he's implying it's Rust, then he's totally disconnected from reality.

bovermyer 5y ago
It's buried in the article, but I think the suggestion is "use almost any language other than Go" rather than Rust specifically. The takeaway - if you gloss over the ranting and look for the good bits - seems to be that you should choose a language that handles a lot of the boilerplate for you (e.g., no verbose error handling) and has FFI. It's not a bad argument, and it's making me think about how and when I use Go. For that, at least, it's worth reading.
wperron 5y ago
It's really not, and it's even saying so explicitly in the article.

weinzierl 5y ago

> "Even worse is the async story, in Rust you have to decide whether to use Tokio or whatever." I think this is going to change. I couldn't find the relevant blog post now, but I believe to remember there was an initiative to provide a standard async runtime.

afdbcreid 4y ago
No. Rust may provide some small async runtime for tutorials etc., but it'll never provide a rich async runtime like tokio because different people have different requirements from their runtime and Rust wants to satisfy them all. What is planned is to standardize the API: that is, provide common traits for IO, tasks, etc. so libraries can be runtime-agnostic and you can change your runtime by only touching Cargo.toml (hopefully).

sdfgdfgbsdfg 5y ago

I agree with this overall. It seems that C is a language/compiler/toolchain combo that lets you shoot yourself in the foot, but gives you enough access to stuff to be maximially performant in a random (i.e. not specialized) use case. (C++ is in this camp too). Rust is a language/compiler/toolchain combo that tries its best to not let you shoot yourself in the foot by presenting those footguns for you to fix up front, without giving up much of the access to stuff (C++ tried some things in this camp like destructors and smart pointers. GC is also something that's in this camp) Golang is a language/compiler/toolchain combo that lets you shoot yourself in the foot in some circumstances, and does not give you enough access to be maximally performant in every random case, but rather it seems to posit to give you opinions that will get you really, good performance in most random cases (if you need to tune the GC, for instance, you're probably worse off, like here: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...). Meaning it's making the tradeoffs of upfront complexity vs runtime issues, and Tim Toady vs The One True Way for you, because in the general case those are the most optimized tradeoffs. I don't disagree, especially when the closed-world ecosystem is good enough to not need to reach out to external tools whether those are via cgo or in the build toolchain. In general, I think that if you reach the point where Golangs admittedly major warts are hindering your progress you're doing better than most companies, so its succeeded in not getting in the way of progress at least until that point. In particular since the article keeps comparing Golang to Rust, for personal projects I do like the correctness of Rust, but some things are frustrating, like async being basically unusable without Async Drop, an uncertain future for completion apis, and apis that really want HKT but can't use them (yet?). I having to make up a lot of opinions that Go makes for you adds risk and uncertainty to a project where the most likely failure modes are not, in fact, those opinions. I'm excited for the future of Java, with Loom and Valhalla coming to address as what I see as two core problems of Java in particular and other languages in general. I'm also excited for the present of js/node.js/maybe Deno. typescript has become good enough that I also think it's a really good competitor to Golang in the "just write code" arena, especially since there's significant synergy between the front end and the back end to help with build tooling, validation logic, and programmer expertise.

closeparen 5y ago

>you use the stdlib * First you construct a request, and check the error on that * Then you "Do" the request and check the error on that * Then you check the status code (you did check it, right?) * Then you deserialize the response and check the error on that * Then you close the response body (you did remember to close it, right?) and check the error on that Actually making an HTTP request with Go stdlib is a many-stage process and it is very easy to screw up or forget one of the steps. I see it all the time. Actually I have seen outages related to people being too zealous and reporting errors related to closing the response body on otherwise successful requests.

Cthulhu_ 4y ago
> Actually I have seen outages related to people being too zealous and reporting errors related to closing the response body on otherwise successful requests. I kinda get it though, because the compiler or linters will show that as a warning or error going "bruh you forgot to handle this error", and as a perfectionist one wants to get rid of all of those. I mean IMO those should be logged anyway, if only so you get some data on how often it happens, if there's anything that can be done about it, and if it's harmless, to ignore the error - but make it explicit.

azth 4y ago

> The better alternative to Go is Rust Nope, a better alternative is Java/C#/Kotlin/etc. Those offer sum types, async programming, while being more productive than golang, and provide superior tooling and a superior developer experience.

weatherlite 4y ago
Why not Node? Or Typescript if you really have to have types? Or even plain old PHP/Ruby (for people that just use Go to build web backends) - doesn't Kubernetes kinda solve scaling?

beltsazar 4y ago

> For example, an _incredibly_ common thing to do in production code is to make a web request. In Go, there is no need for debate, you use the stdlib. And yet, Go's HTTP client doesn't have a good default [1] because of zero values, which are argued harmful in the article. [1]: https://medium.com/@nate510/don-t-use-go-s-default-http-client-4804cb19f779 https://medium.com/@nate510/don-t-use-go-s-default-http-clie...

Fire-Dragon-DoL 4y ago

I agree with you, however I think it's even simpler than that: the author is comparing Go to rust, but it's not comparing it to the places where it shines, that is, where Java, ruby, js, python are used. Now suddenly we go from a poor type system (Java) to a decent one in Go (this is my personal opinion). Or from no type system to SOME type system. On top of this, we are getting all the benefits of a compiled language. Essentially this is looking Go as a system language, while I think of it as an application language. Aside from that, the author is right in some ways.

goodpoint 4y ago

> The better alternative to Go is Rust No, the better alternative is thousands of different languages. HN is just hype-driven as usual and can see only Go and Rust.