Hacker News Reader

Comment by onlyrealcuzzo | Hacker News Reader

That's less because of what it's implemented in - and more to do with all the tracking and libraries they want to reuse...

BigCo apps will take up lots of space and memory for BigCo reasons - obviously less if it's in Rust vs Go vs Python, but you could easily write Go apps that use far less memory than Rust apps written at BigCo due to BigCo reasons.

It's just not really that much of a priority for them to have their weather app use less than 1GB of memory. It's a far bigger priority for someone to insist that somebody else uses some bloated framework so they can get promoted.

View on HN

I've been having _a lot of fun_ writing Go apps that don't allocate anything and that use small, preallocated buffers to stream through requests/etc. Basically TigerStyle for Go. I don't use arenas, I just size everything for the worst case (or make the sizes configurable at startup) and still end up using much less memory.

This is really only possible because I told Fable to build the underlying allocation-free HTTP, JSON, etc libraries and consequently I'm not building anything serious yet (although the libraries are well-tested using pre-existing corpuses from reputable projects e.g. curl as well as fuzz tested).

Most "outputs" are passed as out parameters for the function to fill in, and results are Rust-like enums (a Go tagged union containing only small data). I could also have returned (T, error) but I would have to take care that the thing I pushed into the error argument doesn't allocate--not sure if I made the right decision or not, but for now it feels nice. The worst part is that I don't really have a good way to communicate detailed error information, but that hasn't bitten me yet.

This has also been a lot less effort than writing Rust, although Rust would have real checks for lifetimes and im/mutable and enum exhaustiveness and so on--so far I haven't been bitten, and I suspect things like enum exhaustiveness can be addressed via linter if necessary.

> This has also been a lot less effort than writing Rust

I have never written such Go, but as an experienced Rust programmer I can tell you Rust is not hard to write after learning it. Learning it can take more time than usual (although there is also contrary evidence, e.g. from Google) but after you're used to it, you're basically as proficient as in other languages, except some glitches (that can be expensive - rewriting your main structure, but are fortunately rare). Considering the effort involved in coding in such unnatural Go variant, I tend to believe it is far easier to code in Rust (including coding in Rust using this style, since it is more suited to it).

Of course, if you're just vibe coding everything, maybe it is easier because maybe the LLMs write such Go better that they write Rust. But if you're not, even if you're only reviewing the code, I believe it's easier to review Rust code than to review such Go code (and potentially than reviewing any Go code, but that is a different matter).

I was a little bit scared at first, but after 1k lines of code written by hand I started to forget that Rust was complicated. It's not the Go experience, but it's not that bad at all.

If I was writing no-alloc production code, I would stick with Rust, FWIW, at least until Go's library ecosystem improves.

I don't mind writing Rust (have been dabbling with it since ~2014), especially with some AI assistance. It's just more of a grind for me than working with Go.

> Considering the effort involved in coding in such unnatural Go variant,

I was also expecting writing Go in this style to be more friction, but it was surprisingly smooth. The friction was entirely from lack of libraries and a little uncertainty about how to communicate errors without allocating. Rust has better libraries by far, but I felt more friction from the language (e.g., if you have a buffer you have to initialize every element of it or you have to use something like `heapless::Vec`--not a big deal, just decisions to make to figure out what the happy path is).

Have you considered doing this in OCaml?

You'd get most of the benefits of Go and Rust.

I touched OCaml several years ago and ran into a bunch of problems with build tooling, standard library, syntax noise, ideological/unhelpful community, etc that turned me off. I'm also just not experienced enough to write OCaml without a GC; that would be biting off a lot of learning.

Reply on news.ycombinator.com