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

231–240 of 526 posts

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

#231

Post by heresie-dabord »

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

> Perhaps it's because I have experience, I love a simple language.

(fixed the statement to focus on your value, not age per se)

I love language ergonomics above all. Python wins. But for runtime bang-for-the-buck, Go wins.

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

#232

Post by Mawr »

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

> 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. I kind of see your point. In this very moment, it doesn't matter whether I agree. What I don't understand, though, is why (typically) people who abhor exceptions are among the fiercest defenders of garbage collection, which does add a “magic” and uncontrollable layer to object d…

Different kind of magic. Needing to account for every single line of code being able to throw an exception is very mentally taxing, whereas the existence of a GC removes mental load of needing to account for every single allocation.

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

#233

Post by lexicality »

coldtea wrote: post #201
surgical_fire wrote: post #88

Earlier quoted context omitted.

I sort of like Go. The explicit error handling is a little obnoxious sometimes, but it's just a way to get things done. Otherwise I see its simplicity as a strength. It is very ergonomic, easy to pick up, and generally performs pretty well. I perhaps wouldn't pick it for every scenario, but there are plenty of scenarios where it would be a good tool. Then again, I sort of like Java and Python too, two languages I am…

> I don't understand why people get so passionate about programming languages. They are tools. Because when you're a professional programmer, tools are a huge part of what you do and how you do it, same like a race driver would need to be passionate about cars. It's just that for an e.g. carpenter, tools are more or less standadized and simple enough to evaluate. If saws and hammers and routers had as much variety as…

I think if you tried to tell a professional carpenter that you'd replaced the contents of their toolbox with the equivalent pieces from a discount hardware store you'd be looking for your teeth on the floor.

I certainly wouldn't give up my electronic hardware repair tools without a struggle, it took me years to find ones that I like!

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

#234

Post by pas »

spirit-sparrow wrote: post #217

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…

> what makes someone go such a great length to bash ...

"""

Inherent complexity does not go away if you close your eyes.

When you choose not to care about complexity, you're merely pushing it onto other developers in your org, ops people, your customers, someone. Now they have to work around your assumptions to make sure everything keeps running smoothly.

And nowadays, I'm often that someone, and I'm tired of it.

"""

> [Go] works brilliantly for the projects I've encountered.

Of course, C, C++, PHP and JavaScript works too! Of course many many many things "work" in our world. Of course just adding one more lane works too, of course police states work too!

Yet something else would work even more brilliantly?

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

#235

Post by jchw »

coldtea wrote: post #203
jchw wrote: post #107

Earlier quoted context omitted.

There's no tool boring enough to prevent any chance of regret. At the end of the day, it's really, really difficult to anticipate where your pain points will actually wind up in the real world. In practice, I've had lots of really good production success with Go and not too much heartache about the choice. Since adopting it personally (in around 2014) almost every company I've gone to work since has used Go in some c…

> There's no tool boring enough to prevent any chance of regret. I'm not so sure. I know C programmers that swear by it, warts and all, with absolutely zero regrets for using it e.g. in the embedded space.

If anyone tells you C is "boring", that's just plain and simple bullshit. C gives you undefined behavior, buggy compilers (yes even for simple C code, MSVC is especially bad at plain C but there are other offenders) and the world's worst standard library for manipulating strings. Using C in embedded development is probably OK, even if you have to suffer with whatever crappy vendor compiler you are stuck with, but that's only considering the pretty severe limitations that very resource-constrained embedded development typically has (e.g. no dynamic allocation.) C is only as boring as you force it to be, and you really have to force it to be.

That said... the thing about the embedded space is that most of it is C, always will be, and may continue to be for the foreseeable future. It's really hard to really know what you have to regret if all you've ever known is C.

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

#236

Post by lexicality »

spirit-sparrow wrote: post #217

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…

Perhaps not everyone likes boring clinical reviews and some people like ones that have a bit of passion and humour in them?

Just because this blog post isn't written in a way you like doesn't mean it doesn't have value to others.

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

#237

Post by ivell »

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…

There is Crystal and Nim. With especially Nim, there is GC and generates c in the end.

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

#238

Post by pwdisswordfishz »

quotemstr wrote: post #105
pyrale wrote: post #66

Earlier quoted context omitted.

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.

Rust's error handling evolution is hilarious. In the beginning, the language designers threw out exceptions --- mostly, I think, because Go was fashionable at the time. Then, slowly, Rust evolved various forms of syntactic sugar that transformed its explicit error returns into something reminiscent of exceptions. Once every return is a Result, every call a ?, and every error a yeet, what's the difference between your…

In most languages with exceptions:

• they may propagate automatically from any point in code, potentially breaking atomicity invariants and preventing forward progress, and have to be caught to be transformed or wrapped – Result requires an explicit operator for propagation and enables restoring invariants and transforming the error before it is propagated.

• they are an implicit side-channel treated in the type system like an afterthought and at best opt-out (e.g. "noexcept") – Result is opt-in, visible in the return type, and a regular type like any other, so improvements to type system machinery apply to Result automatically.

• try…catch is a non-expression statement, which means errors often cannot be pinpointed to a particular sub-expression – Result is a value like any other, and can be manipulated by match expressions in the exact place you obtain it.

Sure, if you syntactically transform code in an exception-based language into Rust you won’t see a difference – but the point is to avoid structuring the code that way in the first place.

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

#239

Post by madeofpalk »

spirit-sparrow wrote: post #217

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…

It's just some person's blog and they're having a rant. It's okay, it doesn't have to be that deep.

I would guess the 'why' is because OP feels like they have an opinion that they don't feel is sufficiently represented 'out there'. Indeed, as a not-a-fan-of-go, in 2022 I was confused at go's popularity because it always felt to me to have some pretty glaring shortcomings that were seemingly ignored.

Note that people don't really write big blog posts about PHP being a bad language (anymore?) because that's been done to death.

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

#240

Post by raverbashing »

stavros wrote: post #51
pif wrote: post #44

Earlier quoted context omitted.

[flagged]

If it was created on purpose for poor programmers, it seems to have been created to enable poor programmers to write the poor code they wanted to write, instead of making it impossible for poor programmers to write any code. I guess that's the difference, if you want code, no matter the quality, you have one choice, if you want code that's correct, you have another.

Yeah

I feel Go is simple in the way people say "C is simple" (without the footgun part)

It was created for one purpose and it kinda works but it's clunky. Like there are no fancy front loaders or backhoes and there's a limit on how much out of that form you can get.

Post reply on HN