Hacker News Reader

> The most frustrating thing about Go isn't even the language, it is the community for me. It is very business/corporate focused. Everything is all about Kubernetes/cloud. I apply for conferences/meetups non-stop, but never have any luck. It is always the same company reps. I am envious of the Rust community here, but maybe grass is always greener on the other side?

As someone who's been writing Go full-time for over eight years, and has also done some Rust as well, I'll say that the business/corporate focus that you're noticing is a fairly recent development. My impression is that it's mostly a function of the size and the market demand for the language - ie, as the language has grown and is being used for more mission-critical stuff, a wider range of businesses have a vested interest in it.

Rust is a bit younger than Go. If we're judging by the first stable release, it's about half the age (5 years vs. 8). It's not as far along the adoption curve in many ways yet, although it's growing fast. Rust is being used for more things today than it was, say, three years ago, but it's still a narrower range (and number) of companies that are interested in Rust. Given Rust's trajectory, I think that's just a matter of time, so what you see today in Go will probably be more visible in Rust in a year or two. It's already drawing a wider range of corporate interest than it was even one year ago, and if it continues to be successful, that's inevitable.

I don't think that's a bad thing, though. The communities get wider, but that doesn't mean that the stuff you're looking for isn't there; you just have to look a little harder for it. That's definitely true for Go, and I would bet it will be true for Rust as well.

I also think that Rust and Go are not really comparable, and it's a shame that they often come up together so often in discussions, because they're compared more often than is really warranted IMO. But that's a separate matter.

I think you hit on something that so many miss and it's the tooling for the job, as it were. Go and Rust are fundamentally different tools designed for fundamentally different tasks. While it's possible to use them for the same tasks, it's much more difficult. I would HATE writing a full and secure operating system in Go, while writing back end systems in Rust is doable, but at an unnecessarily slower pace than Go.

Agreed. Comparing them does a disservice to both languages—they're tools with separate niches. It's fair to compare their package management strategies or communities, but the languages themselves are too different.

> I would HATE writing a full and secure operating system in Go

For the record, it _can_ be done.[0]

[0] https://dspace.mit.edu/handle/1721.1/122734

I very much agree with this. Rust is to C++ what Go is to Java. I think the fact that Go compiles to native binaries and can be linked statically are the primary reasons it is often compared to system languages like Rust or C++. But really, it's not the same type of language.

Rust fundamentally improves C++ with memory safety and allegedly provably correct concurrency. It is a vastly different set of assumptions, design, and opinions than C++.

What does Go do to fundamentally deviate from Java? IMO it is basically the same space with a few different opinions. It has GC, is C-style, a more modern stdlib than C/C++.

Single threaded concurrency: goroutines. It's better for writing servers

Go improves on Java in several ways, perhaps most importantly, it is much nicer to deploy - no JVM. It's also a lot less verbose, compiles way faster and uses composition instead of inheritance. Having said that, I really hate Java, and only mildly dislike Go.

Java has had support for AOT compilation to native code since 2000, just not as free beer.

F-Secure thinks otherwise, https://labs.f-secure.com/blog/tamago/

At the risk of being controversial, my guess is that this is because Go makes it very difficult to build abstractions at a level that are appealing or satisfying to most developers. This is the main reason I choose Rust or Python or literally anything else over Go for personal projects. Because I may or may not be more productive in Go if I keep working at it, and go has so many benefits over many other choices, but I mainly write software because I enjoy it. I typically do not enjoy writing Go (and I have seen this sentiment echoed widely). And I think that because enjoyment is much less important in a corporate environment, corporate representatives make up the lion's share of the enthusiasm.

To each his own. There is an equally wide group of developers who choose Go for personal projects as it’s in line with their taste. The joy of programming is in the eye of the beholder.

WASM is their weaker part. On the flip-side the WASM takeup is also rather modest so the net loss is not that big.

Eventually they might come up with a solution to get their huge WASM files down to bearable size. Sure its because they have to ship the bigger part of their VM with it.

I'm developing an entire desktop app in WASM(with electron). Once you build the right abstraction it's just Go...simple and fun! To me the main issue I have with Go is the incomplete reflect package(i.e StructOf )

Soemthing to show the world, github / -lab repo, the like?

There's no VM in Go—you're probably thinking of the runtime.

A "Hello World!" using 1.15.4 on linux/amd64 takes up 1.2MiB of space (731KiB after UPX).

Using https://github.com/tinygo-org/tinygo, it drops to 21KiB (unable to be compressed further using UPX), making WASM size a non-issue.

Forgot to mention I was using TinyGo v0.15.0.

I ran into Pion when looking for a good example implemention of a TURN server. Your code is a great read, especially for something with so little documentation relative to its use.