Hacker News Reader

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.

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.

C# is pretty close.

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

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

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.

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"}
    }

Nullability is unavoidable in Go because of zero values.

https://go.dev/ref/spec#The_zero_value

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.

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

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

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.

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.

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.

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

We’re not talking about go here. This is true for rust. The issue is building against C libraries and APIs for a different OS. Unless go has done some magic I’m unaware of its the same problem, just cgo isn’t super popular in the Go community

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

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.

Guess I am scared to program for real since I don't use a "real" language like Rust. What a wild statement to make.

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