4 ms·

Go has almost everything going for it. I only wish it was a bit more C-like and you had the ability to run it without a garbage collector, and that it was more

Go has almost everything going for it. I only wish it was a bit more C-like and you had the ability to run it without a garbage collector, and that it was more suitable for systems and embedded programming. Perhaps one day someone will come up with an implementation of Go that doesn’t use a GC. It’s just such an incredible language, and it deserves the type of Rust fanaticism that Rust has, but I suspect Go users are just a different type of person and we really are fanatics, we just don’t publicize it.[1] [1]: https://survey.stackoverflow.co/2022/#most-popular-technologies-language-prof https://survey.stackoverflow.co/2022/#most-popular-technolog...

galangalalgol 4y ago
Just got told about tinygo on another thread where I was saying rust is the obvious only choice. But tinygo looks nice. I've written very little go professionally, and rust only for a few months more. Go does seem super easy. But rust doesn't really seem hard either. And the fearless concurrency is really attractivento not have to think much about data races too much. Either one is nicer than c++ which I have a quarter century of experience at.
- throwaway894345 4y ago
  TinyGo still has a GC, right?
  - galangalalgol 4y ago
    It does. https://aykevl.nl/2020/09/gc-tinygo https://aykevl.nl/2020/09/gc-tinygo Edit: but that said with sich constrained resources do people really use gc or even dynamic memory allocation often in embedded? I work embedded and it is usually standard practice to preallocate everything to avoid fragmentation. Unless it is a more performant device in which case I'll add the quotes to "embedded". But for those you could just use normal go, or python for that matter.
rahen 4y ago
> I only wish it was a bit more C-like and you had the ability to run it without a garbage collector "import C, import unsafe". You absolutely can, at least for performance critical sections where you cannot afford garbage collection. https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc https://dgraph.io/blog/post/manual-memory-management-golang-...
- throwaway894345 4y ago
  You don't even need CGo or unsafe to deal without a GC. Go's GC is written in Go and it obviously doesn't depend on a GC! You just need to know which features imply a GC/allocation and you need to take care to avoid those features. Conceivably, you could devise a linter that statically verifies your no-GC requirement.
  - rahen 4y ago
    > You just need to know which features imply a GC/allocation and you need to take care to avoid those features. This is very insightful. Would you mind sharing more resources regarding that? I'd be interested in a list of such features. The GC can also be used manually by setting GOGC=off, then be triggered manually at the most convenient time.
    - throwaway894345 4y ago
      I don't know of any resources, but basically you can intuit pretty easily about how to avoid allocations in Go (don't allocate or grow slices, don't use maps, avoid returning references to anything you allocate inside of your function call, etc), and there are flags you can pass to the compiler to log allocation points. If you don't allocate, then there's nothing to collect, and you can even turn off the GC altogether.
    - jrockway 4y ago
      Tinygo lets you build your program with the option -gc=none that results in a link error at every point in your program that would allocate memory on the heap. So that's a very easy way to find them. Tinygo is a completely separate implementation of Go, so not every program is going to be portable 1 to 1, and I suppose that where Tinygo might allocate memory is different than where normal Go would allocate memory, so you'll have to take the results with a grain of salt. It is of course possible to use Tinygo-compiled programs for your production use case as well. It has a focus on WebAssembly and microcontrollers, but produces perfectly-serviceable amd64 binaries as well.
herdcall 4y ago
Well, I've been a huge Go fanboy telling everyone who'd listen (or not!) why it's the best thing since sliced bread. I use Go for building servers at work and have been quite happy in general except for the verbosity. I had zero plans on using Rust and was actually getting annoyed with the non-stop Rust talk everywhere, especially on HN. Then we had to urgently add Web Assembly to our frontend, and to my shock Go was generating gigantic WASM files, so I ended up trying Rust, being forced really. But once I experienced Rust, I've become a convert singing a completely different tune. So those of you also annoyed by all these "fanatical" Rustaceans telling you how wonderful it is, please try Rust (for a real project) before passing judgment.
kaba0 4y ago
What exactly is fantastic about it, objectively? I really can’t come up with anything besides goroutines. It’s quite inexpressive and is pretty much like the litany of other managed languages (I am honestly baffled how it gets compared to Rust — wouldn’t you be surprised if someone was going on about C vs JS? That’s the same thing)
- doorman2 4y ago
  Personally, I hate writing Go. It's a very dull and boring language, but it's an amazing language (objectively speaking) for software development. 1) It's performant. The language itself is very fast, the GC is very fast and go routines make concurrency fast. 2) The tooling is great. Once you have the Go CLI installed, everything else "just works." Cross-compilation is super easy. Install dependencies is easy. Generating code is easy. Embedding files is easy. The ecosystem is really mature. Modules are easy to create, export, and import. Compilation time is fast. The list goes on... 3) The generics system is amazing. It beats any system that implements generics with type erasure. 4) The language itself is very easy to read and write. 5) The language is relatively new, which means less outdated cruft. The language also puts an emphasis on having only one way to do things. So comparing it to other languages: - Python: Terrible tooling. Not performant - C# Bad tooling (do I need .NET, .NET Core, Mono? How do I create a project? What is this crazy project xml file? How do I export my project to be consumed by others? How do I import a dependency?). Also, as an older language, it has a bit of cruft, e.g. it has optional types, but they also aren't required? Maybe if I knew more about C#, I would find it better. But using it with Unity didn't leave a great taste in my mouth. - JavaScript: not performant, especially in multi-core environments. - Rust: Rust is too hard to write. It's not worth the overhead if you can afford a GC. - C++: Same as rust, + more foot guns and unsafe memory management. - Zig: Don't have much experience with Zig, but I'd like to. - Ruby: Not performant, not typed. - Swift: Tooling is bad. Compilation is slow. Cross-platform is not a priority. Swift Package Manager is buggy. Using Xcode sucks. - JVM languages: bad tooling (maven, sbt, gradle are all a pain), generics have type erasure. Of course, there are reasons to use other languages. If you’re writing an iOS app, the tooling for Swift is best-in-class. Or if you’re doing ML, the ML-specific ecosystem in Python outweighs all other considerations.

galangalalgol 4y ago

Just got told about tinygo on another thread where I was saying rust is the obvious only choice. But tinygo looks nice. I've written very little go professionally, and rust only for a few months more. Go does seem super easy. But rust doesn't really seem hard either. And the fearless concurrency is really attractivento not have to think much about data races too much. Either one is nicer than c++ which I have a quarter century of experience at.

throwaway894345 4y ago
TinyGo still has a GC, right?
- galangalalgol 4y ago
  It does. https://aykevl.nl/2020/09/gc-tinygo https://aykevl.nl/2020/09/gc-tinygo Edit: but that said with sich constrained resources do people really use gc or even dynamic memory allocation often in embedded? I work embedded and it is usually standard practice to preallocate everything to avoid fragmentation. Unless it is a more performant device in which case I'll add the quotes to "embedded". But for those you could just use normal go, or python for that matter.

rahen 4y ago

> I only wish it was a bit more C-like and you had the ability to run it without a garbage collector "import C, import unsafe". You absolutely can, at least for performance critical sections where you cannot afford garbage collection. https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc https://dgraph.io/blog/post/manual-memory-management-golang-...

throwaway894345 4y ago
You don't even need CGo or unsafe to deal without a GC. Go's GC is written in Go and it obviously doesn't depend on a GC! You just need to know which features imply a GC/allocation and you need to take care to avoid those features. Conceivably, you could devise a linter that statically verifies your no-GC requirement.
- rahen 4y ago
  > You just need to know which features imply a GC/allocation and you need to take care to avoid those features. This is very insightful. Would you mind sharing more resources regarding that? I'd be interested in a list of such features. The GC can also be used manually by setting GOGC=off, then be triggered manually at the most convenient time.
  - throwaway894345 4y ago
    I don't know of any resources, but basically you can intuit pretty easily about how to avoid allocations in Go (don't allocate or grow slices, don't use maps, avoid returning references to anything you allocate inside of your function call, etc), and there are flags you can pass to the compiler to log allocation points. If you don't allocate, then there's nothing to collect, and you can even turn off the GC altogether.
  - jrockway 4y ago
    Tinygo lets you build your program with the option -gc=none that results in a link error at every point in your program that would allocate memory on the heap. So that's a very easy way to find them. Tinygo is a completely separate implementation of Go, so not every program is going to be portable 1 to 1, and I suppose that where Tinygo might allocate memory is different than where normal Go would allocate memory, so you'll have to take the results with a grain of salt. It is of course possible to use Tinygo-compiled programs for your production use case as well. It has a focus on WebAssembly and microcontrollers, but produces perfectly-serviceable amd64 binaries as well.

herdcall 4y ago

Well, I've been a huge Go fanboy telling everyone who'd listen (or not!) why it's the best thing since sliced bread. I use Go for building servers at work and have been quite happy in general except for the verbosity. I had zero plans on using Rust and was actually getting annoyed with the non-stop Rust talk everywhere, especially on HN. Then we had to urgently add Web Assembly to our frontend, and to my shock Go was generating gigantic WASM files, so I ended up trying Rust, being forced really. But once I experienced Rust, I've become a convert singing a completely different tune. So those of you also annoyed by all these "fanatical" Rustaceans telling you how wonderful it is, please try Rust (for a real project) before passing judgment.

kaba0 4y ago

What exactly is fantastic about it, objectively? I really can’t come up with anything besides goroutines. It’s quite inexpressive and is pretty much like the litany of other managed languages (I am honestly baffled how it gets compared to Rust — wouldn’t you be surprised if someone was going on about C vs JS? That’s the same thing)

doorman2 4y ago
Personally, I hate writing Go. It's a very dull and boring language, but it's an amazing language (objectively speaking) for software development. 1) It's performant. The language itself is very fast, the GC is very fast and go routines make concurrency fast. 2) The tooling is great. Once you have the Go CLI installed, everything else "just works." Cross-compilation is super easy. Install dependencies is easy. Generating code is easy. Embedding files is easy. The ecosystem is really mature. Modules are easy to create, export, and import. Compilation time is fast. The list goes on... 3) The generics system is amazing. It beats any system that implements generics with type erasure. 4) The language itself is very easy to read and write. 5) The language is relatively new, which means less outdated cruft. The language also puts an emphasis on having only one way to do things. So comparing it to other languages: - Python: Terrible tooling. Not performant - C# Bad tooling (do I need .NET, .NET Core, Mono? How do I create a project? What is this crazy project xml file? How do I export my project to be consumed by others? How do I import a dependency?). Also, as an older language, it has a bit of cruft, e.g. it has optional types, but they also aren't required? Maybe if I knew more about C#, I would find it better. But using it with Unity didn't leave a great taste in my mouth. - JavaScript: not performant, especially in multi-core environments. - Rust: Rust is too hard to write. It's not worth the overhead if you can afford a GC. - C++: Same as rust, + more foot guns and unsafe memory management. - Zig: Don't have much experience with Zig, but I'd like to. - Ruby: Not performant, not typed. - Swift: Tooling is bad. Compilation is slow. Cross-platform is not a priority. Swift Package Manager is buggy. Using Xcode sucks. - JVM languages: bad tooling (maven, sbt, gradle are all a pain), generics have type erasure. Of course, there are reasons to use other languages. If you’re writing an iOS app, the tooling for Swift is best-in-class. Or if you’re doing ML, the ML-specific ecosystem in Python outweighs all other considerations.