Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lies we tell ourselves to keep using Golang (2022)

fasterthanli.me

Post reply on HN
Print view View original

61–70 of 526 posts

Re: Lies we tell ourselves to keep using Golang (2022)

#61

Post by KingOfCoders »

the_gipsy wrote: post #29
devjab wrote: post #5

This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…

There are several shortcomings with go's error handling. The author heavily lies onto rust, so the alternative is not exceptions but a `Result ` sum type. No stacktraces and error wrapping forces you to not only invent unique error messages. You must also conceive a unique wrapping message at every call-site so that you can grep the error message and approximate a stacktrace. The weird "return tuple" , which obviousl…

Exceptions are sum types, they just have different syntactic sugar.

Re: Lies we tell ourselves to keep using Golang (2022)

#62

Post by DanielHB »

stouset wrote: post #45
devjab wrote: post #5

This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…

Without fail, every single person I’ve seen rave about go’s error handling compares it only to exceptions as if that’s the only alternative. On the flip side I have yet to find a person who’s familiar with sum types (e.g., Maybe, Option, Result) that finds the golang approach even remotely acceptable.

You hit the main gripe I have with Go, its types system is so basic. I get people raving type-correctness of Go when they come from Python but the type system in Go is simply pre-historic by modern day standards.

Re: Lies we tell ourselves to keep using Golang (2022)

#63

Post by euroderf »

stouset wrote: post #45
devjab wrote: post #5

This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…

Without fail, every single person I’ve seen rave about go’s error handling compares it only to exceptions as if that’s the only alternative. On the flip side I have yet to find a person who’s familiar with sum types (e.g., Maybe, Option, Result) that finds the golang approach even remotely acceptable.

FWIW... WebAssembly has Option and Result, and adapters for Go.

Re: Lies we tell ourselves to keep using Golang (2022)

#64

Post by radicalbyte »

chikere232 wrote: post #40
forrestthewoods wrote: post #18

Earlier quoted context omitted.

Because someone decides what language to write a new thing in is very likely to consider Go and Rust. They are very unlikely to consider Java. Are Rust and Go sufficiently different that they should each be chosen in different cases? Sure! But that’s literally why someone would consider both and pick one.

They should consider Java though. People have an irrational hate for it based on the enterprise cruft and horrible third party frameworks you can just completely ignore if you build a new thing It's not good for commandline stuff but for a long running small service it is pretty great

^ this! Java's far more capable than golang and a better choice for many projects.. just don't use the decades old "Enterprise" stuff.

..and I'm generally a Java-hater as the language itself is objectively inferior to my beloved C#.. but even then there are situations where Java is a better choice.

Re: Lies we tell ourselves to keep using Golang (2022)

#65

Post by KingOfCoders » 

  Go: "I'm a simple language!"
  User uses Go for some time.
  User: "I hate you, you're a simple language!"
Perhaps it's because I'm 50+, I love a simple language.

I feel the "critique" is not very balanced, and I view judgements that are not balanced as weak, as everything in technology is about tradeoffs.

I of course come to a different conclusion: https://www.inkmi.com/blog/why-we-chose-go-over-rust-for-our...

Re: Lies we tell ourselves to keep using Golang (2022)

#66

Post by pyrale »

abtinf wrote: post #25
devjab wrote: post #5

This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…

Having programmed for over 30 years, including nearly a decade of C#, I would say exceptions are one of the worst ideas in all of programming. They are just horrific gotos that any library can invoke against your code. They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about. Even junior enginee…

Exception and explicit on-the-spot handling are not the only two ways to handle failing processes. Optional/result types wrapping the are a clean way to let devs handle errors, for instance, and chaining operations on them without handling errors at every step is pretty ergonomic.

Re: Lies we tell ourselves to keep using Golang (2022)

#67

Post by Cthulhu_ »

pif wrote: post #39
vasco wrote: post #33

Earlier quoted context omitted.

"Manager imposes it on you" just means you work in a team rather than alone. You can pick whatever you like for side projects, of course you're going to use whatever your team uses otherwise.

[flagged]

> which casts a doubt about developers actually liking it

I'm self-aware enough that I'm not clever enough for the likes of C++ or Rust; I wish more people were as aware of their own limitations. Managers have a long-term responsibility about a codebase too.

"Clever" developers have no place in professional software development, imo.

Re: Lies we tell ourselves to keep using Golang (2022)

#68

Post by pmezard »

monksy wrote: post #57
jchw wrote: post #22

Every time I read a critique of Go, I feel the same way: I'm still going to continue to use it anyways. The reason why I am going to continue to use it anyways is because while I understand that it has plenty of easily documented issues in theory (and that people regularly do actually run into in practice), I still find that it is one of the better programming languages in practice anyways. Some of the things that pe…

> Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. A lot of people really don't like Go because they have experienced other language features. Go has taken an arrogant stance at trying to make the decision about what features you might need and has given you a very small amount of things to work with.

And a lot of people using Go have experienced other language features as well and either decided against them or that the whole tradeoff was not worth it.

I will keep very fast compilation times and decade long backward compatibility over a lot of your features. Because those are features too.

Re: Lies we tell ourselves to keep using Golang (2022)

#69

Post by instig007 »

zwnow wrote: post #53
pif wrote: post #44

Earlier quoted context omitted.

[flagged]

You can call us poor programmers if that boosts your ego. The industry is still built upon people who can build fast. Go allows that and so does Javascript. You might not like it but that's what is earning most people their bread nowadays.

> The industry is still built upon people who can build fast.

Correction: the commercial software is, not the industry. The industry and corporations are capitalising on quality open-source software, meticulously written off working hours with a straight head and passion, and a great attention to details. The fact that you can write glue fast enough to satisfy your SLT is predicated on the presence of those quality components you're gluing together for free.

Re: Lies we tell ourselves to keep using Golang (2022)

#70

Post by jonathanstrange »

This is a silly article, though I can only speak for myself. First of all, language design is pretty much the last reason anyone should consider when choosing a language. For me as a solo developer who needs to get results in time, the main criteria for choosing Go were compilation speed, development speed, general tooling, and third-party support. Especially the latter is extremely important; I cannot develop all kinds of libraries like e.g. an Excel or Word document parser in-house, I have to use whatever MIT-licensed libraries that are there.

I've developed in all kinds of languages in the past: Pearl, Java, C++, REALBasic, PowerMOPS (a Forth derivate in the 90s), Ada, Rust, Python, Java, Racket and various scheme dialects, CommonLisp, ObjectPascal/Lazarus, just to name a few. Out of these, REALBasic was by far the one in which I was most productive. Alas, it became unaffordable and the vendor lock-in really burned me. No more commercial languages or IDEs it is for me.

If Ada had a garbage collector, I would probably use it even though the development time is a bit longer. Likewise, I'd love to use CommonLisp and think it's the best dynamic language. But it simply doesn't have enough 3rd-party support, and I'd also be wary about how it runs on mobile platforms.

I've got to say I'm pretty happy with Go so far. Is it the ideal language for me? No, because full OOP with multiple inheritance would make my life much easier. But it works, is easy and fast to develop in, and the results speak for themselves. I have no problems with bugs. The explicit error handling may be a bit cumbersome but it forces you to think about and deal with every error, unlike people in languages with exception system who often ignore errors until so far up the call chain that they don't even know what actually happened any longer. I don't see the point of that. If you have an illegal state of an object it doesn't matter if you call the object nil or DefunctInstanceOfBla, you're going to have to deal explicitly with the illegal state.

Notably, C# was also in my final selection of languages. For my principal use case - distributed client/server applications with GUI - Go's GUI options were not so stellar and I was thinking about using C# instead. AFAIK, C# is very suitable and a great language, too. I decided against it because of the C#'s bizarrely complex runtime library situation and naming schemes (WTF?) and simply because I would have had to learn it first and already knew Go fairly well.

Beware the language aficionados and purists. I used to be one of them, too, advocating Scheme & CL. However, in the end purely practical considerations are always more important. Programming languages are tools for getting things done.

Post reply on HN