6 ms·

Go isn't low level in the same way that Rust is. Both languages have their places, but Go seems to be more of a better Python/JS, whereas Rust is a better C++.

dilyevsky 5y ago
Python/Js are interpreted by default and not good system programming choices. Go is compiled. This comparison totally misses the mark. In fact Go was developed mostly as C++ but sometimes Python replacement at Google.
- omginternets 5y ago
  It hits the mark because it targets the niche that was once occupied by interpreted languages.
  - throwaway894345 5y ago
    But it wasn't just "interpreted languages". Really the only interpreted languages in "the niche" were Python and a little bit of Ruby, but there was also a whole bunch of Java, C#, and C++.
- KronisLV 5y ago
  That's just one of the ways to think about it. Java, .NET (I felt like adding these two to expand on the comparison), Python and JS are all languages with a relatively high level of abstraction and large and useful ecosystems surrounding them. They're pretty popular for all sorts of application development, but all suffer from certain problems: - Java has lots of brittle reflection in some libraries and JDK can be finicky, especially with GC tuning - .NET needs a runtime, historically there's Mono, now there was .NET Core and now there will be just .NET, though in some cases there's also IL2CPP and so on - Python not only generally runs slow, but also has problematic package management, especially with vent - JS (Node in particular) has similar package management woes as well as really fast package deprecation Go at least partially solves some of those problems, by being compiled, having decent performance, somewhat rich ecosystem and passable package management, all while the language remains usable. Lots of applications and some tools will get written in Go because of this, because it's pretty reasonable to use in most cases. In comparison, C, C++, Zig and Rust would all be better suited for systems level programming or embedded development - they typically let you write more performant and less memory hungry code, at the expense of foot guns and slower development.
  - erik_seaberg 5y ago
    GC tuning is painful, but it’s quicker and more reliable than rewriting code hoping for same result.
    - KronisLV 5y ago
      Partially agreed, many times it's just a patch over a codebase that's stuck only running on JDK 8 - people expect tuning to be sufficient when the code is slowly rotting. I'd argue that most systems that won't die out eventually will need a rewrite, or alternatively, in the modern day we'll see more and more polyglotic systems popping up. Therefore it always makes sense to explore the best options for a particular bit of development, regardless of whether it's Node, Python, Java, Go or something else.
  - kcartlidge 5y ago
    I do both C# and Go so have no axe to grind here. Just two small points though. > .NET needs a runtime It doesn't. With a single command .NET Core can produce stand-alone single-file cross-platform deployables needing no SDK, Framework, runtime, or other dependency on the server. > Go at least partially solves some of those problems, by being compiled, having decent performance, somewhat rich ecosystem and passable package management, all while the language remains usable. It does, and I've been a big fan of Go for a fair few years now. However every point made in that sentence applies equally to .NET too. The one area where Go beats C# (and most others) hands-down for me is the build time. It's a whole order of magnitude (possibly several) faster than most alternatives.
  - asadawadia 5y ago
    >systems level programming or embedded development Like building what?
- atombender 5y ago
  And yet Go seems to have not captured many C++ developers, but rather developers from languages like Python, Ruby, and JavaScript. The Go team originally wanted to replace C++, especially inside Google, but they didn't succeed. According to googlers on Hacker News, very few projects inside Google actually use Go. The reason Go attracted these kinds of developers is precisely that it isn't a systems programming language. Systems people want something like Rust instead.
  - dilyevsky 5y ago
    It def convinced me. I wrote c++ for almost 10 year before switching to Go. Even after c++11 have come out it was still night and day. Anecdotally the team i left at google rewrote some of my stuff from c++ in Go that I didn’t get to at the time
    - _wldu 5y ago
      Same experience here. 10 years ago, I wrote a lot of C++, today I write almost exclusively Go.
  - vp8989 5y ago
    "The Go team originally wanted to replace C++, especially inside Google" Im glad you said that and I was not just imagining that myself. I remember following the Go language closely in its earlier days and it was often spoken about as a "systems language" but it actually seems to have ended up settling as a language to write servers for people who are sick of OOP but still like their imperative C style code.
  - pjmlp 5y ago
    Lack of generics kept most of us away. You don't return to 1992 C++, thinking nah this is fine. Companies like F-Secure are using Go for real system programming just fine. https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory
    - dilyevsky 5y ago
37ef_ced3 5y ago
Go should be understood as a replacement for C and C++. If you're writing a compiler, or some other project where extreme high performance is not necessary (e.g., if you're willing to be, say, a factor of 2 slower than C) then Go is a good choice. Go's performance is excellent, and should be sufficient for all but the most demanding applications. It's not a crummy scripting language like Python/JS.
- munificent 5y ago
  > Go should be understood as a replacement for C and C++. I think Go is a good replacement for the things people used C and C++ for twenty years ago, but less of a replacement for the things people use C and C++ for today. Back then, C/C++ was your default "write big server program that needs to go relatively fast" language, and Go is targeting that. But in the meantime, Java got fast enough and hardware got cheap enough that Python, Ruby, and JavaScript have also eaten into that domain. Today, I see C and C++ used primarily for embedded work and games. I don't see Go as being a great fit for either of those.
- zarzavat 5y ago
  Go is a replacement for a certain subset of C/C++ projects that are I/O heavy, e.g. web servers. However the GC precludes it from many uses of C/C++, e.g. you couldn't write an AAA game in it, or a kernel, or a toaster.
  - vp8989 5y ago
    GC is quite problematic for web servers too. Lots of people "solve" that by giving AWS more money.
    - Xenograph 5y ago
      Why is GC problematic for web servers?
      - vp8989 5y ago
        Because GC will pause threads while requests are being served, this leads to latency spikes at the higher percentiles. It introduces a whole distinct type of complexity into operating the server. The latency of a request to your server is not just caused by the code that is ran to serve that request (which is how people intuitively would think about it), it can be caused by GC pauses that are happening because of the memory pressure caused by previous requests.
asadawadia 5y ago
That is not really a reason. What can I not build in Go that is easy to do in rust?

dilyevsky 5y ago

Python/Js are interpreted by default and not good system programming choices. Go is compiled. This comparison totally misses the mark. In fact Go was developed mostly as C++ but sometimes Python replacement at Google.

omginternets 5y ago
It hits the mark because it targets the niche that was once occupied by interpreted languages.
- throwaway894345 5y ago
  But it wasn't just "interpreted languages". Really the only interpreted languages in "the niche" were Python and a little bit of Ruby, but there was also a whole bunch of Java, C#, and C++.
KronisLV 5y ago
That's just one of the ways to think about it. Java, .NET (I felt like adding these two to expand on the comparison), Python and JS are all languages with a relatively high level of abstraction and large and useful ecosystems surrounding them. They're pretty popular for all sorts of application development, but all suffer from certain problems: - Java has lots of brittle reflection in some libraries and JDK can be finicky, especially with GC tuning - .NET needs a runtime, historically there's Mono, now there was .NET Core and now there will be just .NET, though in some cases there's also IL2CPP and so on - Python not only generally runs slow, but also has problematic package management, especially with vent - JS (Node in particular) has similar package management woes as well as really fast package deprecation Go at least partially solves some of those problems, by being compiled, having decent performance, somewhat rich ecosystem and passable package management, all while the language remains usable. Lots of applications and some tools will get written in Go because of this, because it's pretty reasonable to use in most cases. In comparison, C, C++, Zig and Rust would all be better suited for systems level programming or embedded development - they typically let you write more performant and less memory hungry code, at the expense of foot guns and slower development.
- erik_seaberg 5y ago
  GC tuning is painful, but it’s quicker and more reliable than rewriting code hoping for same result.
  - KronisLV 5y ago
    Partially agreed, many times it's just a patch over a codebase that's stuck only running on JDK 8 - people expect tuning to be sufficient when the code is slowly rotting. I'd argue that most systems that won't die out eventually will need a rewrite, or alternatively, in the modern day we'll see more and more polyglotic systems popping up. Therefore it always makes sense to explore the best options for a particular bit of development, regardless of whether it's Node, Python, Java, Go or something else.
- kcartlidge 5y ago
  I do both C# and Go so have no axe to grind here. Just two small points though. > .NET needs a runtime It doesn't. With a single command .NET Core can produce stand-alone single-file cross-platform deployables needing no SDK, Framework, runtime, or other dependency on the server. > Go at least partially solves some of those problems, by being compiled, having decent performance, somewhat rich ecosystem and passable package management, all while the language remains usable. It does, and I've been a big fan of Go for a fair few years now. However every point made in that sentence applies equally to .NET too. The one area where Go beats C# (and most others) hands-down for me is the build time. It's a whole order of magnitude (possibly several) faster than most alternatives.
- asadawadia 5y ago
  >systems level programming or embedded development Like building what?
atombender 5y ago
And yet Go seems to have not captured many C++ developers, but rather developers from languages like Python, Ruby, and JavaScript. The Go team originally wanted to replace C++, especially inside Google, but they didn't succeed. According to googlers on Hacker News, very few projects inside Google actually use Go. The reason Go attracted these kinds of developers is precisely that it isn't a systems programming language. Systems people want something like Rust instead.
- dilyevsky 5y ago
  It def convinced me. I wrote c++ for almost 10 year before switching to Go. Even after c++11 have come out it was still night and day. Anecdotally the team i left at google rewrote some of my stuff from c++ in Go that I didn’t get to at the time
  - _wldu 5y ago
    Same experience here. 10 years ago, I wrote a lot of C++, today I write almost exclusively Go.
- vp8989 5y ago
  "The Go team originally wanted to replace C++, especially inside Google" Im glad you said that and I was not just imagining that myself. I remember following the Go language closely in its earlier days and it was often spoken about as a "systems language" but it actually seems to have ended up settling as a language to write servers for people who are sick of OOP but still like their imperative C style code.
- pjmlp 5y ago
  Lack of generics kept most of us away. You don't return to 1992 C++, thinking nah this is fine. Companies like F-Secure are using Go for real system programming just fine. https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory
  - dilyevsky 5y ago

37ef_ced3 5y ago

Go should be understood as a replacement for C and C++. If you're writing a compiler, or some other project where extreme high performance is not necessary (e.g., if you're willing to be, say, a factor of 2 slower than C) then Go is a good choice. Go's performance is excellent, and should be sufficient for all but the most demanding applications. It's not a crummy scripting language like Python/JS.

munificent 5y ago
> Go should be understood as a replacement for C and C++. I think Go is a good replacement for the things people used C and C++ for twenty years ago, but less of a replacement for the things people use C and C++ for today. Back then, C/C++ was your default "write big server program that needs to go relatively fast" language, and Go is targeting that. But in the meantime, Java got fast enough and hardware got cheap enough that Python, Ruby, and JavaScript have also eaten into that domain. Today, I see C and C++ used primarily for embedded work and games. I don't see Go as being a great fit for either of those.
zarzavat 5y ago
Go is a replacement for a certain subset of C/C++ projects that are I/O heavy, e.g. web servers. However the GC precludes it from many uses of C/C++, e.g. you couldn't write an AAA game in it, or a kernel, or a toaster.
- vp8989 5y ago
  GC is quite problematic for web servers too. Lots of people "solve" that by giving AWS more money.
  - Xenograph 5y ago
    Why is GC problematic for web servers?
    - vp8989 5y ago
      Because GC will pause threads while requests are being served, this leads to latency spikes at the higher percentiles. It introduces a whole distinct type of complexity into operating the server. The latency of a request to your server is not just caused by the code that is ran to serve that request (which is how people intuitively would think about it), it can be caused by GC pauses that are happening because of the memory pressure caused by previous requests.

asadawadia 5y ago

That is not really a reason. What can I not build in Go that is easy to do in rust?