5 ms·

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

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

UnpossibleJim 6y ago
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.
- snazz 6y ago
  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.
- drewmate 6y ago
  > 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 https://dspace.mit.edu/handle/1721.1/122734
_wldu 6y ago
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.
- AtlasBarfed 6y ago
  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++.
  - cft 6y ago
    Single threaded concurrency: goroutines. It's better for writing servers
  - xedrac 6y ago
    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.
    - pjmlp 6y ago
      Java has had support for AOT compilation to native code since 2000, just not as free beer.
- pjmlp 6y ago
  F-Secure thinks otherwise, https://labs.f-secure.com/blog/tamago/ https://labs.f-secure.com/blog/tamago/
DangitBobby 6y ago
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.
- pbar 6y ago
  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.

UnpossibleJim 6y ago

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.

snazz 6y ago
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.
drewmate 6y ago
> 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 https://dspace.mit.edu/handle/1721.1/122734

_wldu 6y ago

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.

AtlasBarfed 6y ago
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++.
- cft 6y ago
  Single threaded concurrency: goroutines. It's better for writing servers
- xedrac 6y ago
  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.
  - pjmlp 6y ago
    Java has had support for AOT compilation to native code since 2000, just not as free beer.
pjmlp 6y ago
F-Secure thinks otherwise, https://labs.f-secure.com/blog/tamago/ https://labs.f-secure.com/blog/tamago/

DangitBobby 6y ago

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.

pbar 6y ago
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.