10 ms·

I hate to be "that guy", but you should try Rust. It also has amazing tooling, and is probably more comparable to C/C++, considering you don't have to use a gar

I hate to be "that guy", but you should try Rust. It also has amazing tooling, and is probably more comparable to C/C++, considering you don't have to use a garbage collector in Rust.

asadawadia 5y ago
why though? some perf gains?
- rowanG077 5y ago
  No. More because Rust offers modern language features and it's much easier to get code working then in Go.
- DenseComet 5y ago
  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.
    - 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?
ithkuil 5y ago
I hate to be "that guy" too, but coming from somebody who really likes Rust and is using it more and more (also at $dayjob now) we must admit that Go tooling is one step ahead. CPU profiler, allocation and heap profiler, lock contention profiler. It all comes out of the box. Yes you have cargo flamegraph for profiling locally and you now have pprof-rs to mimick Go's embedded pprof support. But allocation heap profiling is still something I struggle with. I saw there was a pprof-rs PR with a heap profiler but there was some doubt as to whether it worked correctly; to get a feeling of how that approach would work but without having to fork pprof-rs I implemented the https://github.com/mkmik/heappy https://github.com/mkmik/heappy crate which I can use to produce memory allocation flamegraphs (using the same "go tool pprof" tooling!) in real code I run and figure out if it works in practice before pushing it upstream. But stuff you give for granted like figuring out which structure accounts for most used memory, is very hard to achieve. The servo project uses an internal macro that help you trace the object sizes but it's hard to use outside the servo project. The GC makes some things very easy, and it's not just about programmers not having to care about memory; it's also that the same reference tracing mechanism used to implement GC can be used to cheaply get profiling information.
- the8472 5y ago
  > But allocation heap profiling is still something I struggle with. Switch to a dumb allocator and then profile mmap calls or page faults? That should get you large allocations at least. It's a pretty crude proxy. The other allocation profilers I'm aware of cause significant slowdowns.
  - ithkuil 5y ago
    Sorry I don't understand what you're suggesting. I currently intercept calls to malloc/calloc/realloc/... and capture stack traces. This way I know how much memory gets allocated for each allocation site. Since allocations usually go through constructor calls, the presence of a constructor in the stack trace can let you infer how many structures of a given type are been allocated. Knowing how big they are is more tricky since allocation for the whole struct and its parts doesn't have to happen entirely in the constructor (some structures like vectors and hashmaps can grow, some structures can collect data from other sources and then hold onto them, etc) Furthermore to know how the live memory is broken down between object type and allocation sites, you also need to track freed memory. This is significantly more tricky to do efficiently. I currently take an allocation sample every N bytes being allocated and use a poisson process estimator to scale the total allocated bytes. The only ways I know to account for in use memory is to track every single allocation or to add some extra space for every allocation where we record whether a block had been sampled and of yes, what was its corresponding allocation event. Can you please elaborate more on your suggestion?
throwaway894345 5y ago
I really like Rust, but in my mind it's still relegated to the periphery of tasks that must be super fast (like C/C++, to your point) and/or low-level. Rust has made impressive strides at reducing the toil involved in compile-time memory management, but there is still a big productivity gap between the borrow checker and GC. Frankly, people are making boatloads of money off of software written in Python and JS--languages which are both far less safe than Go and far slower and yet Go is on par with those languages with respect to productivity (I argue it's more productive due to its static typing features, but others argue it's less productive presumably because of the learning curve). Most software doesn't need to be so fast or correct. Also, I work in distributed systems and SaaS (software as a service). In this world, most errors are silly type errors ("undefined is not a function", forgetting to `await` some async function, etc) that would be caught with a flat-footed type system like Go's. Beyond that, the next largest bucket are issues that even a sophisticated type system like Rust's wouldn't help with, such as infrastructure issues (missing/misconfiguration of some cloud permission, networking rule, etc), misconfiguration of the service, race condition with many processes accessing the same networked resource, deployment error, etc. This means that Rust's stated advantages aren't really as nice as they initially sound. As a programmer, I can appreciate a super fast language with a strict type system; however, as an engineer or a technologist, Rust is rarely a good fit for me. Go seems to be a lot closer to the sweet spot, which makes sense because it was developed expressly with distributed systems in mind.
- josephg 5y ago
  > In this world, most errors are silly type errors I can’t speak to python, but typescript has basically fixed this problem overnight in the javascript ecosystem. The typescript compiler finds almost all small bugs like this while I’m coding. And as an added bonus, type hints allow the IDE to be much more helpful - adding to jump to function support, autocomplete, method parameter suggestions (or documentation on hover). And typescript is easier to read than javascript because you don’t have to guess what data type some variable is. I love javascript’s quick and dirty nature, but I still use typescript instead of javascript now for any code I write that I expect to survive the week. (And as a bonus: you still get IDE type hints when calling typescript functions from raw javascript!) Typescript’s type system is also more powerful than Go’s. It supports enums, genetics and type unions (eg x: string | number). Go sits in the awkward place of having a worse type system and no significant advantages over typescript for me. It’s awkward to use go on the web. Go is faster than javascript on the server but that usually doesn’t matter. And when it does I can reach for C or Rust. Both of which work really well with native code, or with JS through wasm. Rust is much harder to learn than Go - but personally I’ve climbed that hill already. Once you’re over that hill, Rust is much more expressive. On purpose both ways - go isn’t trying to be expressive, and rust is. I love rust’s parametric enums and output types in traits. Which I now sorely miss in other languages. I can imagine Go shining a lot more brightly when working with a team which has mixed skill levels. Most of my work lately has been solo, so I don’t need gofmt to enforce a consistent code style, or anything like that. I do miss Go’s green threads. Rust’s afterthought scattergun approach with threads and futures feels like a mess. But I can’t see myself ever really using Go. It’s weak in areas I want it to be strong (eg the type system). And strong in areas I just don’t care much about. (Eg consistency).
_008_jb_ 5y ago
Ah, the desperate Rust promoter crew enters the Go thread ... Rust is great for language enthusiats doing hobby projects or for learning. The Rust book is great. Rust has great language features. Having that said, Rust is the right tool for the job for a very small niche. Basically, if you would have used C++ before and don't need much developer reach or mature libraries. And only for the rare cases you really cannot affort a GC (even though Go's GC is highly optimized). Go on the other hand, is an industrial strength proven and mature general purpose language. It is the best fit for various kind of networking application. Especially APIs, but also infrastructure where you can live with an GC. CLIs are great with Go as well. If you're working on a professional grade project (where the GC is acceptable), Go is much superior than Rust in all regards. Rust is advertised for years and years and didn't have it's breakthrough yet. This empirical fact cannot be ignored. There're reasons for this, of course. Some are: - Writing Rust consumes so much more mental power with so little gain. That mental energy should be directed to solving the problem. - Go makes everything besides your problem at hand easy. You can focus on solving your problem, not fighting the Borrow Checker - Rust's ecosystem is not reliable. Many essential libs are one-man-shows. Version 0.1 everywhere. - Rust is for and by language enthusiats. If you need to rely on libs for longer than a couple of years it is a hight risk for your project - In terms of real world performance: Go is so close to Rust that there're very very very few use cases that really need that marginal gain
dang 5y ago
We detached this subthread from https://news.ycombinator.com/item?id=28203422 https://news.ycombinator.com/item?id=28203422.

I hate to be "that guy", but you should try Rust. It also has amazing tooling, and is probably more comparable to C/C++, considering you don't have to use a garbage collector in Rust.

asadawadia 5y ago

why though? some perf gains?

rowanG077 5y ago
No. More because Rust offers modern language features and it's much easier to get code working then in Go.
DenseComet 5y ago
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.
  - 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?

ithkuil 5y ago

I hate to be "that guy" too, but coming from somebody who really likes Rust and is using it more and more (also at $dayjob now) we must admit that Go tooling is one step ahead. CPU profiler, allocation and heap profiler, lock contention profiler. It all comes out of the box. Yes you have cargo flamegraph for profiling locally and you now have pprof-rs to mimick Go's embedded pprof support. But allocation heap profiling is still something I struggle with. I saw there was a pprof-rs PR with a heap profiler but there was some doubt as to whether it worked correctly; to get a feeling of how that approach would work but without having to fork pprof-rs I implemented the https://github.com/mkmik/heappy https://github.com/mkmik/heappy crate which I can use to produce memory allocation flamegraphs (using the same "go tool pprof" tooling!) in real code I run and figure out if it works in practice before pushing it upstream. But stuff you give for granted like figuring out which structure accounts for most used memory, is very hard to achieve. The servo project uses an internal macro that help you trace the object sizes but it's hard to use outside the servo project. The GC makes some things very easy, and it's not just about programmers not having to care about memory; it's also that the same reference tracing mechanism used to implement GC can be used to cheaply get profiling information.

the8472 5y ago
> But allocation heap profiling is still something I struggle with. Switch to a dumb allocator and then profile mmap calls or page faults? That should get you large allocations at least. It's a pretty crude proxy. The other allocation profilers I'm aware of cause significant slowdowns.
- ithkuil 5y ago
  Sorry I don't understand what you're suggesting. I currently intercept calls to malloc/calloc/realloc/... and capture stack traces. This way I know how much memory gets allocated for each allocation site. Since allocations usually go through constructor calls, the presence of a constructor in the stack trace can let you infer how many structures of a given type are been allocated. Knowing how big they are is more tricky since allocation for the whole struct and its parts doesn't have to happen entirely in the constructor (some structures like vectors and hashmaps can grow, some structures can collect data from other sources and then hold onto them, etc) Furthermore to know how the live memory is broken down between object type and allocation sites, you also need to track freed memory. This is significantly more tricky to do efficiently. I currently take an allocation sample every N bytes being allocated and use a poisson process estimator to scale the total allocated bytes. The only ways I know to account for in use memory is to track every single allocation or to add some extra space for every allocation where we record whether a block had been sampled and of yes, what was its corresponding allocation event. Can you please elaborate more on your suggestion?

throwaway894345 5y ago

I really like Rust, but in my mind it's still relegated to the periphery of tasks that must be super fast (like C/C++, to your point) and/or low-level. Rust has made impressive strides at reducing the toil involved in compile-time memory management, but there is still a big productivity gap between the borrow checker and GC. Frankly, people are making boatloads of money off of software written in Python and JS--languages which are both far less safe than Go and far slower and yet Go is on par with those languages with respect to productivity (I argue it's more productive due to its static typing features, but others argue it's less productive presumably because of the learning curve). Most software doesn't need to be so fast or correct. Also, I work in distributed systems and SaaS (software as a service). In this world, most errors are silly type errors ("undefined is not a function", forgetting to `await` some async function, etc) that would be caught with a flat-footed type system like Go's. Beyond that, the next largest bucket are issues that even a sophisticated type system like Rust's wouldn't help with, such as infrastructure issues (missing/misconfiguration of some cloud permission, networking rule, etc), misconfiguration of the service, race condition with many processes accessing the same networked resource, deployment error, etc. This means that Rust's stated advantages aren't really as nice as they initially sound. As a programmer, I can appreciate a super fast language with a strict type system; however, as an engineer or a technologist, Rust is rarely a good fit for me. Go seems to be a lot closer to the sweet spot, which makes sense because it was developed expressly with distributed systems in mind.

josephg 5y ago
> In this world, most errors are silly type errors I can’t speak to python, but typescript has basically fixed this problem overnight in the javascript ecosystem. The typescript compiler finds almost all small bugs like this while I’m coding. And as an added bonus, type hints allow the IDE to be much more helpful - adding to jump to function support, autocomplete, method parameter suggestions (or documentation on hover). And typescript is easier to read than javascript because you don’t have to guess what data type some variable is. I love javascript’s quick and dirty nature, but I still use typescript instead of javascript now for any code I write that I expect to survive the week. (And as a bonus: you still get IDE type hints when calling typescript functions from raw javascript!) Typescript’s type system is also more powerful than Go’s. It supports enums, genetics and type unions (eg x: string | number). Go sits in the awkward place of having a worse type system and no significant advantages over typescript for me. It’s awkward to use go on the web. Go is faster than javascript on the server but that usually doesn’t matter. And when it does I can reach for C or Rust. Both of which work really well with native code, or with JS through wasm. Rust is much harder to learn than Go - but personally I’ve climbed that hill already. Once you’re over that hill, Rust is much more expressive. On purpose both ways - go isn’t trying to be expressive, and rust is. I love rust’s parametric enums and output types in traits. Which I now sorely miss in other languages. I can imagine Go shining a lot more brightly when working with a team which has mixed skill levels. Most of my work lately has been solo, so I don’t need gofmt to enforce a consistent code style, or anything like that. I do miss Go’s green threads. Rust’s afterthought scattergun approach with threads and futures feels like a mess. But I can’t see myself ever really using Go. It’s weak in areas I want it to be strong (eg the type system). And strong in areas I just don’t care much about. (Eg consistency).

_008_jb_ 5y ago

Ah, the desperate Rust promoter crew enters the Go thread ... Rust is great for language enthusiats doing hobby projects or for learning. The Rust book is great. Rust has great language features. Having that said, Rust is the right tool for the job for a very small niche. Basically, if you would have used C++ before and don't need much developer reach or mature libraries. And only for the rare cases you really cannot affort a GC (even though Go's GC is highly optimized). Go on the other hand, is an industrial strength proven and mature general purpose language. It is the best fit for various kind of networking application. Especially APIs, but also infrastructure where you can live with an GC. CLIs are great with Go as well. If you're working on a professional grade project (where the GC is acceptable), Go is much superior than Rust in all regards. Rust is advertised for years and years and didn't have it's breakthrough yet. This empirical fact cannot be ignored. There're reasons for this, of course. Some are: - Writing Rust consumes so much more mental power with so little gain. That mental energy should be directed to solving the problem. - Go makes everything besides your problem at hand easy. You can focus on solving your problem, not fighting the Borrow Checker - Rust's ecosystem is not reliable. Many essential libs are one-man-shows. Version 0.1 everywhere. - Rust is for and by language enthusiats. If you need to rely on libs for longer than a couple of years it is a hight risk for your project - In terms of real world performance: Go is so close to Rust that there're very very very few use cases that really need that marginal gain

dang 5y ago

We detached this subthread from https://news.ycombinator.com/item?id=28203422 https://news.ycombinator.com/item?id=28203422.