Hacker News Reader

Comment by afiodorov | Hacker News Reader

Not sure why Go is compared to Rust all the time, whilst most appropriate comparison is Java.

I think this is exactly the right way to understand Go - it's targetted at building servers in environments where having strong consistency of code and a short ramp up time for junior engineers is valuable - i.e. it's perfect for all the big corp scenarios that Java was used for.

I think maybe the more common, but less helpful comparison of go vs rust comes from the fact that they are both part of a new wave of languages and that they both default to producing staticly linked binaries.

> consistency of code

There are many stylecheck tools that should be apart of a good stack. Accepting the creator's style is putting a lot of weight on their opinion. Most organizations have their own preferences for good reason.

> short ramp up for junior engineers

Junior engineers aren't a place you're concerned on being productive. Most of the time at that stage in someone's career they should be learning more, getting up to speed with professional practices, tools, and trying to learn code bases+patterns. Ramp up time for a language is a very minor consideration.

Both of those things have very little to do with server environments.

Bigger corporations struggle with Go's module system and forced reliance on seperate repos for separate modules. (Can you bundle multiple modules in the same repo.. yes but you're going to have a bad time)

> Both of those things have very little to do with server environments

My experience of bigcorp is that they need lots of servers (http is the modern bailer twine) and want developers to act as far as possible as indistinguishable resource. They will have rotating, high churn, globally distributed teams of vendors, contractors, consultants, internal staff and the teams will encompass a vast range of skill levels and abilities.

Some languages amplify skill level disparity, some attenuate it.

This is where I would argue that it's a terrible language choice for the environment. (The need for rest frameworks) There aren't a lot of established or mature options for this, and a lot of them don't give you very much to work off of. It's going to be a bumpy road for exploits in this area.

> act as a indistinguishable resource rotating high churn, globally distributed teams of vendors, contactors, consultants, internal staff...

So this is a huge organizational problem that isn't helped by Go. This is more of a higher level problem and the lack of technical leadership in the company. Any language you go with .. you're not going to do well by trying to utilize everyone there. Picking a language that gives you the impression that you can blend the skill levels will end up with a disastrous mistake with a lot of slippage on the development side. Will you generate a ton of code? Yes, the language encourages it.

What I do agree with you: It does encourage the mass hiring of developers with low to no expectations of performance. (Seems like that's google's focus these days) But that's a bad thing for the developer who wants to achieve a lot of results (not just write lines), and to develop our teams.

Go is an iteration of C, not of Java.

It's a really bad choice for situations where Java is a good choice as not only is the language limited, the ecosystem around it is also very limited when compared to say Java.

I'm maintaining Go, C# and TypeScript as my main languages as that gives me excellent coverage. I'll add Rust to the mix when I have 6 months where I can accept the productivity drop or have a project where the quality requirements are lower (it only takes a week or two to pick up a language, it's learning how to engineer within the ecosystem which takes the time).

How is Go an iteration of C? You can't use Go to write a kernel, or program a microcontroller, or for high-frequency trading or a web browser or a tensor library or a language run-time. It's either a bad idea or simply impossible, depending.

Someone please explain to me what's C-like about Go other than vaguely the syntax and that it compiles to machine code.

To be pedantic for a moment...

> You can't use Go to write a kernel ...

Not a production kernel, but MIT did use Go to "study the performance trade-offs of using a high-level language with garbage collection to implement a kernel" [1]

There is also gVisor [2] which implements, as best as I can describe, a kernel in user space. It's intent is to intercept syscalls made in containers and to redirect its execution in a sandbox.

> ... program a microcontroller ...

I'm not sure if one would classify this as a microcontroller, but USB Armory did write a, iirc, Go compliant runtime for bare metal ARM and RISC-V [3].

There is also TinyGo [4] with the following listed microcontroller support [5]

[1] https://github.com/mit-pdos/biscuit

[2] https://gvisor.dev/

[3] https://github.com/usbarmory/tamago

[4] https://tinygo.org/

[5] https://tinygo.org/docs/reference/microcontrollers/

The refusal to use anything language designers have learnt since 1970 is what makes it C. No sum types, poor error handling, no map/filter funcs, all the other stuff written in the post. Java has all of that, any language after the 90s has most of that, Go doesn't. Actually even C has sum types lol.

The fact that it can't fill many of the usecases that C can and yet has ergonomics as bad as C makes it even worse.

C -> Alef -> Limbo -> Go ?

With influences from other languages along the way.

The Go language was actually created while waiting for C++ to compile. Their goal was to create something that was better than C++ for network services and they succeeded- but that's a pretty low bar! Most companies that don't have major performance concerns don't use C++ for networked services. If Rust was already mature it would have been a good option- except for the compile times which was one of their main original issues could well be worse in a Rust code base! I have seen this myself- Go being used instead of Rust with the biggest reason being it compiles so much more quickly.

Because someone decides what language to write a new thing in is very likely to consider Go and Rust. They are very unlikely to consider Java.

Are Rust and Go sufficiently different that they should each be chosen in different cases? Sure! But that’s literally why someone would consider both and pick one.

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

^ this! Java's far more capable than golang and a better choice for many projects.. just don't use the decades old "Enterprise" stuff.

..and I'm generally a Java-hater as the language itself is objectively inferior to my beloved C#.. but even then there are situations where Java is a better choice.

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

> They are very unlikely to consider Java.

Except they are not unlikely to consider Java.

It's a language with a very robust ecosystem, it is relatively easy to hire Java developers, and a decent job for large, complex projects.

Not considering Java is just as dumb as not considering Go or Rust.

Reply on news.ycombinator.com