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

Lies we tell ourselves to keep using Golang

fasterthanli.me

Post reply on HN
Print view View original

441–450 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#441

Post by Karrot_Kream »

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 gave up here. Do you really think a production conversation can start from this? ESR has flamed less haughtily.

Re: Lies we tell ourselves to keep using Golang

#442

Post by kaba0 »

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…

> Let's start with bytecode. It "requires" (except for AOT work) a warm-up / JIT phase that tends towards slower start times

This is true, but relatively easily solved by AOT compilation which has been tried 2 decades ago as well as now and many times in-between. With a closed-world assumption done by Graal it is not a hard thing to do.

Re: GC

What language decisions do you mean? Other than having value types and some form of pointers, I really don’t see that much of a win. Sure, in some basic networking case allocating on the stack manually almost everything may be possible, but my experience shows that general purpose programs simply live or die by heap allocations and you can’t generally avoid them. And here the complex, but state of the art GCs of Java demonstratedly win big times, and this is the reason why the performance advantages of Go are not so pronounced or even existing for more complex use-cases.

But I will give you that the Oracle acquisition is indeed a good point - though it fortunately turned out to be a good thing for the Java ecosystem in hindsight.

Do you mean complex reflection-heavy java code or even simple explicit one? Because while I agree the latter is not the most common one in some areas, I find it to be surprisingly readable and simple, while still being expressive enough when needed.

Re: Lies we tell ourselves to keep using Golang

#443

Post by kaba0 »

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…

While I think it is overstated how hard it is to choose a JDK (pretty much just get the first OpenJDK release you see, which is packaged everywhere), I do see the advantage of a default build tool. Though for beginner use cases both maven and gradle is just a copy-pastable few lines and you are ready to .. java (sorry for the joke).

I don’t really agree about the 28 competing library thing though. First of all, Java has a really good standard library. Sure, it shows its age at some places but it’s not like you have to grab a new dependency for everything, I pretty much only grab deps for very specialized tasks, and in case of Java I now there will always be a match. The only difference in go here is that a bit more network-related code is in the standard library than in java, but that’s hardly that big of an advantage.

Regarding concurrency: the most unique feature of go is unarguably go routines, but the language has an otherwise quite dumb concurrency model hindering its usefulness. Sure, locking should not be the primary mechanism here, but it is painfully bad with defer being function scoped, not block scoped — while java has synchronized blocks since forever. And with the already mentioned coming of Loom, the JVM platform will again rise to the top with regards to concurrency.

Re: Lies we tell ourselves to keep using Golang

#444

Post by beltsazar »

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…

> For example, an _incredibly_ common thing to do in production code is to make a web request. In Go, there is no need for debate, you use the stdlib.

And yet, Go's HTTP client doesn't have a good default [1] because of zero values, which are argued harmful in the article.

[1]: https://medium.com/@nate510/don-t-use-go-s-default-http-clie...

Re: Lies we tell ourselves to keep using Golang

#445

Post by azth »

pphysch wrote: post #252
busterarm wrote: post #117

Earlier quoted context omitted.

I use Go. I'm not a Rustacean. I've also used a whole bunch of things that are not Go. In reading this article, I'm finding myself agreeing with 100% of the author's criticisms. I've seen every specific problem mentioned be a thing that bogs companies I've worked for down and erode productivity. A lot of time the ops peoples' (aka: my) productivity specifically. I haven't worked at a single company where teams of dev…

> GRPC and protobufs are f'in messy and full of footguns. Distributed data modeling is inherently messy and IME gRPC is one of the least messy, most scalable solutions to it. Or do you have a better alternative?

protobuf has issues with optional fields, as was pointed out in the post. Couple that with a language with a weak type system like golang (no sum types), and it's very verbose and slow to develop in. Targeting better languages helps alleviate the latter.

Re: Lies we tell ourselves to keep using Golang

#446

Post by Fire-Dragon-DoL »

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…

I agree with you, however I think it's even simpler than that: the author is comparing Go to rust, but it's not comparing it to the places where it shines, that is, where Java, ruby, js, python are used.

Now suddenly we go from a poor type system (Java) to a decent one in Go (this is my personal opinion). Or from no type system to SOME type system. On top of this, we are getting all the benefits of a compiled language.

Essentially this is looking Go as a system language, while I think of it as an application language.

Aside from that, the author is right in some ways.

Re: Lies we tell ourselves to keep using Golang

#447

Post by beltsazar »

streblo wrote: post #56

I didn't care in the last post and I don't care about this one either. I care about my productivity, I care about my team's productivity, and I care about getting stuff shipped. Those are the things I care about, and go works great for that. If you care about those things too, and you're using go, you shouldn't stop using go. My whole career people have been telling me to stop using languages or tools I've been produ…

> I didn't care in the last post and I don't care about this one either. I care about my productivity, I care about my team's productivity, and I care about getting stuff shipped. Those are the things I care about, and go works great for that.

If your definition of "productivity" is the time spent in programming, I think you and the author are not in disagreement. The point that the author makes is that using a language with sophisticated type systems prevents some categories of bugs to happen in the first place. That means less time spent in debugging and fixing the code.

Re: Lies we tell ourselves to keep using Golang

#448

Post by VMtest »

crawshaw wrote: post #332

Tailscalar here. Go made prototyping our product easy. We have relatively rarely needed Go expertise on the team to make the product better, when we did it was for the exotic iOS environment (not normal iOS, the Network Extension). It’s far from perfect (and I really should write an experience report about all the times Go has let us down!), but it gives us less trouble than Node and Swift do, for our relatively mino…

Author's criticisms are valid, but

"There's two types of languages, languages people complain about and languages no one uses"

Is author being serious about all people who write Go for production would be waking up at 3am to fix issues? If this is happening, software engineers are being abused, enough said

And not recommending C/C++ because it is easy to shoot yourself in the foot, apparently the devs enter hospitals so many times when memory-related vulnerabilities happen in Windows/Linux/Android/MacOs/iOS and Chrome/Safari/Firefox

people should stop idolizing programming languages

Re: Lies we tell ourselves to keep using Golang

#449

Post by metaltyphoon »

conor- wrote: post #375
valcron1000 wrote: post #335

Earlier quoted context omitted.

If you want a big standard library why not use something like Java or C#? I mean, you even have UI toolkits available from the get go

With Go you can develop a web service with few to no external deps or frameworks, compile it into a single, static binary and then deploy it in a minimal distroless container. With Java and C# there's a lot of other fuss involved with figuring out deployment. The code, build, test cycle is also much slower in C#/.NET ime. That's starting to improve a bit with the newer dotnet, but still feels behind other everything…

Thats a lot of nonsense. The developer loop is way faster now in C# with the introduction of hot reload.

> fuss involved

The commands are almost the same from the go tooling, dotnet build , dotnet run, dotnet format, dotnet test…

Anything outside of hellow world for a web sevice in go, you will use a third party library while in .NET its given to you.

Re: Lies we tell ourselves to keep using Golang

#450

Post by VMtest »

rglullis wrote: post #286
Thaxll wrote: post #279

Earlier quoted context omitted.

I gave example of very successful tool used, Kubernetes works fine, did you ever heard about Kuberentes gone bad or full of bug or unusable? It's very stable and it's used by millions of people.

> Kubernetes works fine At what cost? How many man-hours did it take? How many bugs could have been avoided? How much faster could it be done with other languages? Most importantly: if Google stops backing its development, who else could replace it? Redis/SQLite are written in C, and it is also used by millions of people. They are also not known to be bad or full of bugs. You don't see that being used as an argument…

> At what cost? How many man-hours did it take? How many bugs could have been avoided? How much faster could it be done with other languages? Most importantly: if Google stops backing its development, who else could replace it?

Same question can be asked when Rust or C/C++ are being used to write k8s

> And if you did see anyone using that argument, we probably would say that this is just a lie they tell themselves to keep using C.

A bad programmer is a bad programmer. If all you have is a hammer, everything looks like a nail

People who did read this article should be aware of the shortcomings of Golang by now, and some of them will still be using it, and I am very sure of that

Post reply on HN