6 ms·

One of the things I wish more people talked about isn't just the language or the syntax, but the ecosystem. Programming isn't just typing, it's dealing with dep

One of the things I wish more people talked about isn't just the language or the syntax, but the ecosystem. Programming isn't just typing, it's dealing with dependencies and trying to wire everything up so you can have tests, benchmarks, code-generation and build scripts all working together well. When I use modern languages like Go or Rust I don't have to deal with all the stuff added to other languages over the past 20 years like unicode, unit testing, linting, or concurrency. I use Go where the team knows Java, Ruby or TypeScript but needs performance with low memory overhead. All the normal stuff is right there in the stdlib like JSON parsing, ECC / RSA encryption, or Image generation. You can write a working REST API with zero dependencies. Not to mention so far all Go programs I've ever seen still compile fine unlike those Python or Ruby projects where everything is broken because it's been 8mo. However, I'd pick Rust when the team isn't scared of learning to program for real.

anttiharju 9mo ago
I like Rust. I don't like that for fairly basic things one has to quickly reach for crates. I suppose it allows the best implementation to emerge and not be concerned with a breaking change to the language itself. I also don't like how difficult it is to cross-compile from Linux to macOS. zig cc exists, but quickly runs into a situation where a linker flag is unsupported. The rust-lang/libc also (apparently?) insists on adding a flag related to iconv for macOS even though it's apparently not even used? But writing Rust is fun. You kind of don't need to worry so much about trivialities because the compiler is so strict and can focus on the interesting stuff.
- Xeoncross 9mo ago
  Yeah, I've never seen an all-in-one language like Go before. Not just a huge stdlib where you don't have to vet the authors on github to see if you'll be okay using their package, but also a huge amount of utility built in like benchmarking, testing, multiple platforms, profiling, formatting, and race-detection to name a few. I'm sad they still allow null, but they got a lot right when it comes to the tools. Everything is literally built-in. It's the perfect scripting language replacement with the fast compile time and tiny language spec (Java 900 pages vs Go 130 pages) making it easy to fully train C-family devs into it within a couple weeks.
  - christophilus 9mo ago
    C# is pretty close.
    - booi 9mo ago
      This was not the case for a long time. Actually it seems like it's fairly recently you get native AOT and trimming to actually reduce build sizes and build time. Otherwise all the binaries come with a giant library
      - neonsunset 9mo ago
        Even back in .NET Core 3.1 days C# had more than competitive performance profile with Go, and _much_ better multi-core scaling at allocation-heavy workloads. It is disingenuous to say that whatever it ships with is huge also. The common misconception by the industry that AOT is optimal and desired in server workloads is unfortunate. The deployment model (single slim binary vs many files vs host-dependent) is completely unrelated to whether the application utilizes JIT or AOT. Even with carefully gathered profile, Go produces much worse compiler output for something as trivial as hashmap lookup in comparison to .NET (or JVM for that matter).
  - anttiharju 9mo ago
    Oh Go with Rust's result/none setup and maybe better consts like in the article would be great. Too ba null/nil is to stay since no Go 2. Or maybe they would? Iirc 1.21 had technically a breaking change related to for loops. If it was just possible to have migration tooling. I guess too large of a change.
    - benrazdev 9mo ago
      Technically, with generics, you could get a Result that is almost as good as Rust, but it is unidiomatic and awkward to write: type Result[T, E any] struct { Val T Err E IsErr bool } type Payload string type ProgError struct { Prog string Code int Reason string } func DoStuff(x int) Result[Payload, ProgError] { if x > 8 { return Result[Payload, ProgError]{Err: ProgError{Prog: "ls", code: 1, "no directory"}} } return Result[Payload, ProgError]{Val: "hello"} }
- cmrdporcupine 9mo ago
  The crates.io ecosystem for Rust... is like the amazing girlfriend that you go head over heels for, make her your wife, and then you meet the in-laws ... but it's too late now. Unlimited access to a bunch of third party code is great as you're getting started. Until it isn't and you're swimming in a fishing net full of code you didn't write and dependencies you do not want. Everything you touch eventually brings all of tokio along with it. And 3 or 4 different versions of random number generators or base64 utilities, etc. etc.
- vlovich123 9mo ago
  There’s cross-rs which simplifies things. But the main problem is less linker flags being unsupported and more cross compiling C dependencies somewhere in the dependency chain and that’s always a nightmare, not really anything to do with Rust (Go should have similar difficulties with cross compilation).
  - anttiharju 9mo ago
    Fair take for nontrivial projects. Buuut with Go one in general tends to reach less for dependencies so less likely to run into this and cgo is not go ;) https://go-proverbs.github.io https://go-proverbs.github.io but for cross-compiling actually ended up filtering out the liconv flag with a bash wrapper and compiled a custom zig cc version with the support for exported_symbols_list patched in, things appear to work. Should look into cross-rs I suppose. Hope it's not one of those "download macos sdk from this unofficial source" setups that people seem to do. Apparently not allowed by Apple.
    - vlovich123 9mo ago
      Cross compiling to Apple products from non Apple products is going to run into the same hurdle around SDK setup as any other. There exists documentation but it’s probably not the easiest task. This limitation though applies equally to any library that depends on system C headers and/or system libraries.
      - anttiharju 9mo ago
        I feel like we're talking in loops. Go is generally fine for crosscompiling. edit: what gave me pain with Rust for a cli was clap (with derive, the default). Go just worked.
  - dent9 9mo ago
    > Go should have similar difficulties with cross compilation It doesn't. Go code can be cross compiled for any OS and any CPU arch from any supported system. And it comes out of the box that way. You don't have to go out of your way to install or configure anything extra to do it.
surgical_fire 9mo ago
> However, I'd pick Rust when the team isn't scared of learning to program for real. I've been learning Rust. It's elegant, and I am enjoying it. The Rust people however are absolutely annoying though. Never have I seen such a worse group of language zealots.
- benrazdev 9mo ago
  I can't speak for other Rust programmers but I can speak for myself. I obviously enjoy programming Rust and I like many of the choices it made, but I am well aware of the tradeoffs Rust has made and I understand why other languages chose not to make them. Nor do I think Rust functions equally as well in every single use case. I imagine most Rust users think like this, but unfortunately there seems to be a vocal minority who hold very dogmatic views of programming who have shaped how most people view the Rust community.
- RSHEPP 9mo ago
  Guess I am scared to program for real since I don't use a "real" language like Rust. What a wild statement to make.
dent9 9mo ago
This is such a big deal and I wish more people talked about it in these types of blog posts. I used to be a Python programmer and there were two things that destroyed every project; - managing Python dependencies - inability to reason about the input and output types for functions and inability to enforce it ; in Python any function can accept any input value of any type and can return any type of value of any type. These issues are not too bad if it's a small project and you're the sole developer. But as projects get larger and require multiple developers, it turns into a mess quickly. Go solved all these issues. Makes deployment so much easier. In all the projects I've done I estimate that more than half have zero dependencies outside of the standard library. And unlike Python, you don't have to "install" Go or it's libraries on the server you plan to run your program on. Fully static self contained executable binary with zero external files needed is amazing, and the fact that you can cross compile for any OS+ CPU arch out of the box on any supported system is a miracle. The issues described by the original post seem like small potatoes compared to the benefits I've gotten by shifting from Python over to Go

anttiharju 9mo ago

I like Rust. I don't like that for fairly basic things one has to quickly reach for crates. I suppose it allows the best implementation to emerge and not be concerned with a breaking change to the language itself. I also don't like how difficult it is to cross-compile from Linux to macOS. zig cc exists, but quickly runs into a situation where a linker flag is unsupported. The rust-lang/libc also (apparently?) insists on adding a flag related to iconv for macOS even though it's apparently not even used? But writing Rust is fun. You kind of don't need to worry so much about trivialities because the compiler is so strict and can focus on the interesting stuff.

Xeoncross 9mo ago
Yeah, I've never seen an all-in-one language like Go before. Not just a huge stdlib where you don't have to vet the authors on github to see if you'll be okay using their package, but also a huge amount of utility built in like benchmarking, testing, multiple platforms, profiling, formatting, and race-detection to name a few. I'm sad they still allow null, but they got a lot right when it comes to the tools. Everything is literally built-in. It's the perfect scripting language replacement with the fast compile time and tiny language spec (Java 900 pages vs Go 130 pages) making it easy to fully train C-family devs into it within a couple weeks.
- christophilus 9mo ago
  C# is pretty close.
  - booi 9mo ago
    This was not the case for a long time. Actually it seems like it's fairly recently you get native AOT and trimming to actually reduce build sizes and build time. Otherwise all the binaries come with a giant library
    - neonsunset 9mo ago
      Even back in .NET Core 3.1 days C# had more than competitive performance profile with Go, and _much_ better multi-core scaling at allocation-heavy workloads. It is disingenuous to say that whatever it ships with is huge also. The common misconception by the industry that AOT is optimal and desired in server workloads is unfortunate. The deployment model (single slim binary vs many files vs host-dependent) is completely unrelated to whether the application utilizes JIT or AOT. Even with carefully gathered profile, Go produces much worse compiler output for something as trivial as hashmap lookup in comparison to .NET (or JVM for that matter).
- anttiharju 9mo ago
  Oh Go with Rust's result/none setup and maybe better consts like in the article would be great. Too ba null/nil is to stay since no Go 2. Or maybe they would? Iirc 1.21 had technically a breaking change related to for loops. If it was just possible to have migration tooling. I guess too large of a change.
  - benrazdev 9mo ago
    Technically, with generics, you could get a Result that is almost as good as Rust, but it is unidiomatic and awkward to write: type Result[T, E any] struct { Val T Err E IsErr bool } type Payload string type ProgError struct { Prog string Code int Reason string } func DoStuff(x int) Result[Payload, ProgError] { if x > 8 { return Result[Payload, ProgError]{Err: ProgError{Prog: "ls", code: 1, "no directory"}} } return Result[Payload, ProgError]{Val: "hello"} }
cmrdporcupine 9mo ago
The crates.io ecosystem for Rust... is like the amazing girlfriend that you go head over heels for, make her your wife, and then you meet the in-laws ... but it's too late now. Unlimited access to a bunch of third party code is great as you're getting started. Until it isn't and you're swimming in a fishing net full of code you didn't write and dependencies you do not want. Everything you touch eventually brings all of tokio along with it. And 3 or 4 different versions of random number generators or base64 utilities, etc. etc.
vlovich123 9mo ago
There’s cross-rs which simplifies things. But the main problem is less linker flags being unsupported and more cross compiling C dependencies somewhere in the dependency chain and that’s always a nightmare, not really anything to do with Rust (Go should have similar difficulties with cross compilation).
- anttiharju 9mo ago
  Fair take for nontrivial projects. Buuut with Go one in general tends to reach less for dependencies so less likely to run into this and cgo is not go ;) https://go-proverbs.github.io https://go-proverbs.github.io but for cross-compiling actually ended up filtering out the liconv flag with a bash wrapper and compiled a custom zig cc version with the support for exported_symbols_list patched in, things appear to work. Should look into cross-rs I suppose. Hope it's not one of those "download macos sdk from this unofficial source" setups that people seem to do. Apparently not allowed by Apple.
  - vlovich123 9mo ago
    Cross compiling to Apple products from non Apple products is going to run into the same hurdle around SDK setup as any other. There exists documentation but it’s probably not the easiest task. This limitation though applies equally to any library that depends on system C headers and/or system libraries.
    - anttiharju 9mo ago
      I feel like we're talking in loops. Go is generally fine for crosscompiling. edit: what gave me pain with Rust for a cli was clap (with derive, the default). Go just worked.
- dent9 9mo ago
  > Go should have similar difficulties with cross compilation It doesn't. Go code can be cross compiled for any OS and any CPU arch from any supported system. And it comes out of the box that way. You don't have to go out of your way to install or configure anything extra to do it.

surgical_fire 9mo ago

> However, I'd pick Rust when the team isn't scared of learning to program for real. I've been learning Rust. It's elegant, and I am enjoying it. The Rust people however are absolutely annoying though. Never have I seen such a worse group of language zealots.

benrazdev 9mo ago
I can't speak for other Rust programmers but I can speak for myself. I obviously enjoy programming Rust and I like many of the choices it made, but I am well aware of the tradeoffs Rust has made and I understand why other languages chose not to make them. Nor do I think Rust functions equally as well in every single use case. I imagine most Rust users think like this, but unfortunately there seems to be a vocal minority who hold very dogmatic views of programming who have shaped how most people view the Rust community.
RSHEPP 9mo ago
Guess I am scared to program for real since I don't use a "real" language like Rust. What a wild statement to make.

dent9 9mo ago

This is such a big deal and I wish more people talked about it in these types of blog posts. I used to be a Python programmer and there were two things that destroyed every project; - managing Python dependencies - inability to reason about the input and output types for functions and inability to enforce it ; in Python any function can accept any input value of any type and can return any type of value of any type. These issues are not too bad if it's a small project and you're the sole developer. But as projects get larger and require multiple developers, it turns into a mess quickly. Go solved all these issues. Makes deployment so much easier. In all the projects I've done I estimate that more than half have zero dependencies outside of the standard library. And unlike Python, you don't have to "install" Go or it's libraries on the server you plan to run your program on. Fully static self contained executable binary with zero external files needed is amazing, and the fact that you can cross compile for any OS+ CPU arch out of the box on any supported system is a miracle. The issues described by the original post seem like small potatoes compared to the benefits I've gotten by shifting from Python over to Go