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

211–220 of 526 posts

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

#211

Post by fasterthanlime »

sureglymop wrote: post #133

Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently. A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating some…

(author here) in which ways does Gleam come short of that? Because I'm also looking for that middle ground and I was very curious to get a look at Gleam.

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

#212

Post by Cthulhu_ »

OtomotO wrote: post #118
abtinf wrote: post #25

Earlier quoted context omitted.

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…

But with Exceptions you can easily implement multiple return types in e.g. Java ;) I shocked my Professor at university with that statement. After I started laughing, he asked me more questions... still went away with a straight A ;D

As you should, it shows a deeper insight in the language beyond the base course material and out of the box (and cursed) thinking.

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

#213

Post by icar »

I just want to say that I started working with Go a few months ago at my new work, and I've been disappointed. The type system doesn't even have union types, and the implicit implementation of interfaces has caused a couple headaches that I would've never had with explicit languages such as Typescript (strict).

At this point, I prefer strict Typescript with very restrictive ESLint rules than Go. I don't understand how this language was pushed for web servers, it lacks common constructions to represent very frequent data types in API design.

Also, the whole go func(){} and channels is nice if you are coming from a language with worse ergonomics (C?), but when doing multiple web requests to other places and wanting them to happen in parallel, it gets messy fast. It lacks a pretty abstraction -- I very much miss an await-like construction which uses wait groups under the hood.

So, I very much agree with the post. I like errors as values, though.

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

#214

Post by p_l »

troupo wrote: post #9

Even async in Go isn't that good, ultimately. You can't monitor channels, you can't properly react to errors, you can't shutdown and restart them. A panic in a channel will kill your program. Etc. It's "we learned about green threads and didn't bother to learn anything else" approach (also prevalent in many other languages)

It's more that it's CSP from early to mid 1990s, over which Go just added syntax sugar

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

#215

Post by zozbot234 »

KingOfCoders wrote: post #65

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...

Scheme is a simple language, Go just hides complexity until it blows up in the worst possible way. (Of course, most reasonable alternatives to Go are even worse from that POV. See Python, Ruby, JS etc.)

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

#216

Post by serial_dev »

KingOfCoders wrote: post #65

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...

Very common misrepresentation of any critique of Go. "You just don't get simplicity, you got them Java brainwormz"...

There are many examples in the article that point out the annoying inconsistencies in the language, those are the opposite of simplicity.

I love Rob Pike's presentations on Go, some of them were eye-opening to me. However, I just wish that the Go I see in practice would be much closer to the Go language that Go-fans describe in abstract.

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

#217

Post by spirit-sparrow »

I wonder what makes someone go such a great length to bash a language, any language. I say bashing, because even the few valid points in the post are not written in a constructive style. After all is there a language that can't be criticised?

Is the post written to make one feel better having a failed a project the language? (It's not me, it's the language) Or is it the failure to understand that not everyone thinks / works the same and what one finds unacceptably bothersome, others barely notice? Languages that do not cater for a real need would likely vanish on their own, they rarely need help.

As for Go, despite the differences compared to "more sophisticated" languages it works brilliantly for the projects I've encountered. I hope the author is not forced to work with Go though. For the rest of the community, we keep churning out services, giving our feedback to the Go team and seeing the slow evolution of the language without breaking our stuff in production.

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

#218

Post by eru »

KingOfCoders wrote: post #186
eru wrote: post #140

Earlier quoted context omitted.

RiscV assembly is even easier to read by that metric.

My assembler days were 4 decades ago, but "Everyone can read Go code and understand what happens." There seems to be a difference between "easy to read" and "understand what happens" - or what happens on what level. The challenge is that there is a tradeoff between the two. Assembler is too low to understand what "really" happens, on the other hand Haskell for example with Monad stacks is again very easy to read + un…

Yes. And to be less snarky: Go doesn't really sit on the efficiency frontier here:

It requires you to write a lot of stuff by hand and is incredibly verbose, but it also does a lot of magic behind the scenes.

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

#219

Post by biorach »

quotemstr wrote: post #91
abtinf wrote: post #25

Earlier quoted context omitted.

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…

Hard disagree. Exceptions are actually good. They make code clear and errors hard to ignore. I've written a ton of code over decades in both exceptional and explicit-error languages and I'll take the former every day. There's no function color problem. No syntactic pollution of logic with repetitive error propagation tokens. Also, exception systems usually come with built in stack trace support, "this error caused by…

> Oh, and sum types? Have you read any real world Rust code? Junior developers just add unwrap() until things compile.

Junior developers will write suboptimal code in any language. So I'm not sure what your point is.

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

#220

Post by euroderf »

cnity wrote: post #169
euroderf wrote: post #63

Earlier quoted context omitted.

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

What do you mean by this? WebAssembly is a low level bytecode which only defines low level types. WebAssembly doesn't "have" types any more than x86 "has" types right? Or have I missed something?

Ah, sorry. Shoulda said: WebAssembly component model.
Post reply on HN