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

341–350 of 526 posts

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

#341

Post by neonsunset »

zozbot234 wrote: post #317
devjab wrote: post #285

Earlier quoted context omitted.

I think it’s because Go is an alternative to Java and C# more so than an alternative to Rust. It is for me at least. As I said, Rust isn’t seeing any form of real world adoption in my region while Go is. Go isn’t replacing C/C++ or even Python though, it’s replacing Typescript, C# and Java. Now, there are a lot of good reasons as to why Go shouldn’t be doing that, a lot of them listed in the article, but that’s still…

> Now, there are a lot of good reasons as to why Go shouldn’t be doing that I disagree. Typescript, C# and Java are terrible languages (as are Python/Ruby/etc. in other ways). Golang is bad by OP's standards but there's nothing wrong with it gaining ground on those languages. Besides it's also easier to convert a codebase to Rust from Golang than Typescript or C#/Java.

Rust and C# have far more overlap than Go could ever hope for. Go is limited (and convoluted sometimes due to "solutions" devised to cope with it) so it is easily expressible in languages with better type systems and concurrency primitives.

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

#342

Post by chikere232 »

Mawr wrote: post #260
chikere232 wrote: post #40

Earlier quoted context omitted.

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

That's a big if. In practice you're not going to be able to escape needing to interface with Java code others have written. What then? You either waste time putting up shims in front of every single API or, more likely, give up and just go with it, at which point you've lost. It is much more practical to choose a language that does not have a terrible history of poor API design to begin with.

There are plenty of good libraries that don't suck you into a hellscape of frameworks or enterprise java

What language that's been around for long enough to have a large ecosystem doesn't have a terrible history of poor api design?

But sure, if you pick a really new language, you do get the chance to be that history for future generations

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

#343

Post by chikere232 »

josefx wrote: post #136
chikere232 wrote: post #56

Earlier quoted context omitted.

Python has the most opinionated brace style though

You can abuse list comprehensions to enclose your code in [ ] instead of having to deal with all that whitespace.

oh that's evil :)

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

#344

Post by packetlost »

pdimitar wrote: post #340
packetlost wrote: post #338

Earlier quoted context omitted.

Rust and Go's lack of stack traces are basically equivalent in that you need to call an additional function to add the stack context to the error result. For go you use fmt.Errorf, in Rust you use .context from anyhow (bad practice in many contexts IMO) or .inspect_err + log. It's rather unfortunate that neither has an easy way of capturing a line number + file easily and appending it to the context. Go could easily…

RE: Golang v2, they clearly said they will not do it and will double down on backwards compatibility with exceptions powered by env vars and/or CLI switches.

I'm fully aware of that.

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

#345

Post by mike_hearn »

bob1029 wrote: post #305
mike_hearn wrote: post #268

Earlier quoted context omitted.

Well, I've also programmed for over thirty years and I wouldn't use a language without exceptions and even wrote a whole essay defending that position: https://blog.plan99.net/what-s-wrong-with-exceptions-nothing... > Even junior engineers have a trivial time debugging most go errors Not my experience at all. I had to do this once. An HTTP request to a production server was yielding a 400 Bad Request with no useful i…

> Diagnosing errors given stack traces is very easy. This is the most important aspect of exceptions in my view. The line that threw the exception isn't even the part of a stack trace that I find most interesting. The part that is most valuable to me when working on complex production systems are all of the call sites leading up to that point. I remember in my junior years I wasn't a big fan of exceptions. A stack tr…

Exception usability is definitely an area that needs work. If you work support for a dev platform for a while, it's a really common experience that people will post questions with a copy/pasted stack trace where the message+stack actually answers their question. You can just copy/paste parts back to them and they're happy. There's too much information and not enough tools to digest/simplify them and people get overwhelmed.

Still, better to have too much data than too little.

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

#346

Post by the_gipsy »

9rx wrote: post #325
the_gipsy wrote: post #29

Earlier quoted context omitted.

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…

> The weird "return tuple" , which obviously just exists for errors because there is not a single other place where you can use tuples in the language Go functions also accept a tuple on input. While theoretically you could pass an error, or a pointer to an error for assignment, it is a stretch to claim it is for errors.

Yes exactly, that rather useless feature just makes the whole thing even weirder.

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

#347

Post by AnimalMuppet »

guappa wrote: post #164
matwood wrote: post #84

Earlier quoted context omitted.

> People tend to forget that Golang was created on purpose for poor programmers. Poor programmers by Google's standards. I would argue the vast majority of programmers, even those outside of Google, don't want to be language researches, have no desire to be a language wonk, but want to build software to solve their and their companies problems. I read that quote and think it means that Golang is the only language the…

I managed to make go segfault multiple times (a real actual segfault). It's not a general purpose language. If you want to do things that aren't json RPC is awful.

A general purpose language must be one that you cannot cause to segfault? That's a rather... unique perspective.

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

#348

Post by AnimalMuppet »

pif wrote: post #32
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…

> I choose a language that I feel works well for me Which is the wisest choice for everyone. Golang is only a problem when a manager imposes it on you.

Only a problem when a manager imposes it on you for a program where it doesn't fit well.

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

#349

Post by neonsunset »

jchw wrote: post #153
dataflow wrote: post #132

Earlier quoted context omitted.

Thoughts on C#?

Not that you asked me but since Go is my goto language, my thought on C# is that it looks pretty cool. C# with hill-climbing thread pool and async seems rather compelling. I really see only two (major, obvious) downsides with C#: - It has so much. language. design. This is both a strength and a weakness, of course, but C# really does take this to an extreme. I won't bother making a huge list of examples because I thi…

Is there a specific aspect of language design that you see as problematic? I agree that it can be perceived as "way too many things to keep track of". I think most of it are small, atomic changes designed to reduce boilerplate that can be intuitively understood (like collection literals, additions to pattern matching and null-coalescing operators). You don't have to spend mental effort on these and if there is a scenario where more idiomatic syntax is available - the analyzer has a good chance of catching it and providing an autofix suggestion.

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

#350

Post by ViewTrick1002 »

quotemstr wrote: post #311
pyrale wrote: post #208

Earlier quoted context omitted.

> A function that returns something other than Result has to either call only infallible code or panic on error ...Or solve the problem. A library function that can be a source of issues and can't fix these issues locally should simply not be returning something that is not a result in that paradigm. > since something can go wrong in most code That is not my experience. Separating e.g. business logic which can be des…

> Or solve the problem. A library function that can be a source of issues and can't fix these issues locally should simply not be returning something that is not a result in that paradigm. People "solve" this problem by swallowing errors (if you're lucky, logging them) or by just panicking. It's the same problem that checked exceptions in Java have: the error type being part of the signature constrains implementation…

In my experience an unwrap, expect or panicking function is a direct comment in code review and won’t be merged without a reason explaining why panicking is acceptable.
Post reply on HN