Lies we tell ourselves to keep using Golang • Hacker News Board

Re: Lies we tell ourselves to keep using Golang

#431

Post by kretaceous » Sat, Apr 30, 2022, 4:18 AM UTC

Karrot_Kream wrote: post #413

kretaceous wrote: post #304

Earlier quoted context omitted.

As a beginner learning Go for the past 3 weeks, thanks for the last paragraph. I was looking into a new language to learn outside of JS and Python. I wanted to learn a hot language. I did some digging between Rust and Go and found out that Go is more suitable for web backends, CLI apps, etc. while Rust was more of a contender to C/C++, as it was primarily was made to be used as a memory-safe, correct, strict language…

Rust is indeed a general purpose programming language, but unlike the sibling poster I'm not going to sell it for low-level systems programming _and_ other things just because it can and has some (hit-or-miss depending on the domain) crates for them. Rust is a complex language and its APIs tend to reflect the underlying domain complexity nearly 1:1. It also does not have a GC. Rust interops with native code well. Whe…

Thank you for the detailed explanation! That actually clarifies a lot of things.

Indeed, there's no straight-forward answer to the question "Should I learn Rust as a web backend developer?". It depends on all of the above things you mentioned here.

Go: Trades off correctness with opinions and abstractions. Has a GC. Has a simple, dare I say old or not-modern, type system. Easy to pick up. Hard to have full control over the program.

Rust: Reflects and embraces the actual system with its complexity. Correctness is first and foremost as it deals with all the edge cases. Not easy to pick up. But worth it for critical projects.

In a realisation, why do people even compare these two? :)

Re: Lies we tell ourselves to keep using Golang

#432

Post by kretaceous » Sat, Apr 30, 2022, 4:21 AM UTC

NIckGeek wrote: post #406

kretaceous wrote: post #304

Earlier quoted context omitted.

As a beginner learning Go for the past 3 weeks, thanks for the last paragraph. I was looking into a new language to learn outside of JS and Python. I wanted to learn a hot language. I did some digging between Rust and Go and found out that Go is more suitable for web backends, CLI apps, etc. while Rust was more of a contender to C/C++, as it was primarily was made to be used as a memory-safe, correct, strict language…

Rust is a general purpose programming language. It can do low level systems programming but it's also highly capable of doing web backends, web frontends (wasm), game design, small utility scripts, etc. A big thing people learning Rust do my mistake is to try and use all of the low level features straight away. Rust has tools like Rc, RefCell, Arc, and RwLock that let you have a garbage collected language (well, refe…

With your and the sibling commenters comment, I've made up my mind:

I'll definitely learn Rust one day and make stuff with it when I have proper time and I'm not learning anything else.

Thanks for the insights!

Re: Lies we tell ourselves to keep using Golang

#433

Post by benreesman » Sat, Apr 30, 2022, 4:57 AM UTC

dang wrote: post #255

benreesman wrote: post #128

You guys flagged this? That is not the move of a vibrant, growing, confident community. I’m no fan of the Rust jihad myself, but this isn’t spam or hate speech or whatever. That is a super weak move.

It's normal for users to flag meta follow-ups to recent big threads, especially when they contain a lot of flamebait. If users didn't flag these, HN's front page would largely consist of meta flamebait follow-ups. Here's the principle: curiosity withers under repetition and fries under indignation; also, meta is the crack of internet forums. Repeat+indignant+meta is definitely worth flagging.

@dang you moderate this forum very well, arguably better than any forum out there.

You and I know perfectly well that some kind of tribal loyalty around loyalty on a programming language (they all suck) is an IQ test.

I’ll look the other way on Siebel committing outright fraud, and you let these idiots argue about go vs Rust without displaying any bias.

Everyone knows that Thompson invented UTF-8. And I’m smarter than Pike, who was always a pity hire.

Re: Lies we tell ourselves to keep using Golang

#434

Post by azth » Sat, Apr 30, 2022, 5:45 AM UTC

HL33tibCe7 wrote: post #98

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 examp…

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

Re: Lies we tell ourselves to keep using Golang

#435

Post by azth » Sat, Apr 30, 2022, 5:51 AM UTC

boulos wrote: post #148

As people have remarked, Amos's style can be grating and hyperbolic. That doesn't make a lot of his complaints about Go as a language incorrect. I do think he's misunderstanding that the design intent is "networked C" and that Go + Protobuf is much better than he thinks. A lot of his complaints with the language and runtime boil down to: - It's got a primitive type system (yep, nobody disagrees) - It leaves a lot of…

> If you start from "we want a language and runtime for writing distributed systems that would otherwise be written in C or Java" then Go is pretty good!

C and Java are far from the same. I'd argue that Java addresses or solves many of the criticisms he listed for golang (sum types, pattern matching, immutability with records, superior error handling with exceptions, nullability tracking with annotations, resource handling with try-with-resources, etc.).

Re: Lies we tell ourselves to keep using Golang

#436

Post by azth » Sat, Apr 30, 2022, 6:01 AM UTC

mumblemumble wrote: post #430

boulos wrote: post #400

Earlier quoted context omitted.

There are a few things, mostly due to the runtimes but also because the JVM bytecode assumption has real implications for system behavior. Let's start with bytecode. It "requires" (except for AOT work) a warm-up / JIT phase that tends towards slower start times. This isn't hard and fast, but in practice it's true. (And when you search for "jvm startup", you end up at lots of pages about how to tune things to try to m…

I have barely touched Go, but, from what I've seen, I think I might be able to add a couple more to that: Java is more intimidating to get in to. It starts with "Oh dear, which JDK do I use?", proceeds to, "Oh dear, now I have to pick a build tool and every single one has a near-vertical learning curve by modern standards." Then you're on to, "I want to do X. Why are there 28 competing libraries for X, and why are th…

> but I just wanted to emphasize that I doubt that Java's concurrency story can ever be a match for Go's

Project Loom is already targeted for preview for JDK19. Not only does it match golang's concurrency story, it is superior to it.

Re: Lies we tell ourselves to keep using Golang

#437

Post by azth » Sat, Apr 30, 2022, 6:05 AM UTC

boulos wrote: post #400

kaba0 wrote: post #385

Earlier quoted context omitted.

What I don’t generally get is why Go when there is Java already? Like other than the somewhat smaller memory footprint that is not inherent to the language, but the runtime — in what way is Go better that could not have been a Java library? Hell, with Google’s resources one other GC/mode could be added to OpenJDK that prioritizes memory footprint (at the expensive of throughput - there is no free lunch). Sure, Java h…

There are a few things, mostly due to the runtimes but also because the JVM bytecode assumption has real implications for system behavior. Let's start with bytecode. It "requires" (except for AOT work) a warm-up / JIT phase that tends towards slower start times. This isn't hard and fast, but in practice it's true. (And when you search for "jvm startup", you end up at lots of pages about how to tune things to try to m…

> Yes there exist special, tuned GCs (e.g., Azul's C4, Shenandoah) but Java GCs have to really be super clever compared to the fairly simple strategies that work in Go;

It doesn't matter at the end, when those GCs work. There's also ZGC by the way, which has been consistently improving release over release, with sub ms pauses in the latest release for TB sized heaps, something that golang's gc cannot match.

> I applaud the ingenuity in Java GC work, but if what you care about is "reasonably good at collecting memory, never pauses for long", the Go language decisions made the GC problem easier.

Now if you want to have high throughput and willing to sacrifice some latency, Java's GC selection allows you to do that. Where as in golang you're stuck with the single gc implementation and have to resort to finicky code changes.

Re: Lies we tell ourselves to keep using Golang

#438

Post by Karrot_Kream » Sat, Apr 30, 2022, 6:06 AM UTC

kretaceous wrote: post #431

Karrot_Kream wrote: post #413

Earlier quoted context omitted.

Rust is indeed a general purpose programming language, but unlike the sibling poster I'm not going to sell it for low-level systems programming _and_ other things just because it can and has some (hit-or-miss depending on the domain) crates for them. Rust is a complex language and its APIs tend to reflect the underlying domain complexity nearly 1:1. It also does not have a GC. Rust interops with native code well. Whe…

Thank you for the detailed explanation! That actually clarifies a lot of things. Indeed, there's no straight-forward answer to the question "Should I learn Rust as a web backend developer?". It depends on all of the above things you mentioned here. Go: Trades off correctness with opinions and abstractions. Has a GC. Has a simple, dare I say old or not-modern, type system. Easy to pick up. Hard to have full control ov…

> In a realisation, why do people even compare these two? :)

That's the puzzling thing. While the author doesn't explicitly call out Rust as the better alternative, if you look at his Twitter, it's fairly obvious his community is thinking of Rust. But I don't understand why. They're different languages with different strengths and weaknesses. If I'm writing a net service I'd rather write it in Go. If I'm writing something in OpenGL, I'd rather write it in Rust. There's no need to insult one another.

Re: Lies we tell ourselves to keep using Golang

#439

Post by kaba0 » Sat, Apr 30, 2022, 6:09 AM UTC

mumblemumble wrote: post #410

kaba0 wrote: post #379

Earlier quoted context omitted.

It’s a big assumption that you can even handle the error at the callsite, or that you will actually handle it correctly there, or just write some low-effort attempt because the overall picture is more important for now, but later on you won’t notice how it is not correct and it will just silently fail. Exceptions are in my honest opinion better on every single front. Checked exceptions would be the panacea but Java’s…

For reliability, the absolute best discipline I've ever experienced, is "Either handle the error at (or very close to) the callsite, or crash the process." But only if you make sure that everyone on the team understands that (A) this is the only way to do it, and (B) there is no other way to do it, and (C) you will do it no other way. I think because it sets up the right psychological incentives. Because almost any o…

I just gave you an example from the top of my head. Here is another more realistic one, which occurred to me during the time I wrote a toy JVM: a Java class file contains a constant pool with different kinds of types. During the loading process this pool can be references by other entities as well, but they require the necessary type. Assuming verified byte code, this will be the case, but if we care about verification as well then you will quickly get into the situation where you simply can’t handle “during the loading of this class’s nth method, one of the constant pool references were of incorrect type”. It can’t be handled at method loading (or even more nested), and panicking is not the correct behavior (you only don’t want to load the given class). So you have to manually bubble it up for no benefit.

Re: Lies we tell ourselves to keep using Golang

#440

Post by Karrot_Kream » Sat, Apr 30, 2022, 6:18 AM UTC

biorach wrote: post #119

rob74 wrote: post #94

Earlier quoted context omitted.

But he doesn't dive deeper! If anything, he's more shallow. This just doesn't read like an honest appraisal of Go's pros and cons to me, he already has his mind set from the beginning (ok, we knew that two years ago already) and is just heaping on invectives: "one really good bit does not a platform make", "Evidently, the Go team didn't want to design a language", "Go is not adequate for production services unless yo…

> What makes me angry about all this Go-bashing It's just a language! Take it easy. The guy is not "heaping on invectives" - he's not criticizing you or someone you care about. He's pointing out some flaws in a language in a sarcastic way.

Oh just some sarcasm:

"Mom smokes, so it's probably okay"

"I remember fondly the time an audience member asked the Go team "why did you choose to ignore any research about type systems since the 1970s"? (Emphasis his, not mine)

"It doesn't matter who points out that "maybe we shouldn't hit ourselves in the head with a rake repeatedly""

"Or you can be horrified, as you realize that those complex problems only exist because Go is being used."

"you adopted a language that happened by accident" (a direct criticism at Go users)

"Evidently, the Go team didn't want to design a language."

"Because it needed to be familiar to "Googlers, fresh out of school, who probably learned some Java/C/C++/Python" (Rob Pike, Lang NEXT 2014), it borrowed from all of these."

I just have up here. Do you really think a production conversation can start from this? ESR has flamed less haughtily.