Comment by asdkhadsj | Hacker News Reader

Comment by asdkhadsj | Hacker News Reader

Parent Full thread

Having been a professional Go programmer for ~5 years prior, now working in Rust full time, I actually take issue with Go for large code bases[1].

For me it's mainly due to the lack of generics and helper tools that naturally spawn from generics. Go's solution to having less LOC inside a function is _only_ to create helper methods/funcs. These helpers are bound to specific data structures and often are only applicable to that one use case in that one method that they came from. Your ability to make that helper function apply to more code depends heavily on what data structures are being used.

This form of non-generic bloat was far worse for me than the classic examples of `Fooi32()` and `FooString()`. The latter I don't mind at all.

Rust aids this process to me by, well, having generics. Converting one data structure into another becomes a breeze, and converting a Slice of those data structures is just as easy. I'll be really interested to see how Go feels once generics make it in - though I suspect I'll stick with more explicit memory management.

Speaking of memory management, it would be nice if Go had a way to intelligently indicate which structures are safe for concurrent use and which aren't. I've found in Rust that the explicit nature of the concurrent safety is not something I knew I wanted in Go. I know Go will not likely ever match Rust's safety, but if it at least indicated that something was an thread-unsafe implementation that would be golden.

[1] edit: Oh, and there is a disclaimer in this that the projects I'm involved in seem to heavily rely on managing several data structures in repeated ways. Aka, very generic friendly.. so not having generics made my projects extra painful. This is not likely the norm.

> actually take issue with Go for large code bases

This has been my experience as well. People just parrot what the golang authors say about it being a language suites for "large scale development", whatever that means, without providing anything to back it up. Just because they said it was must be it's true? In practical experience, it's a verbose, clunky, and awkward language to use for any non-trivial code bases.

Your disclaimer isn't really needed. Good generics support leads to good standard libraries, and using standard libraries is the norm.

Rust is still too young to take advantage of this, but in due time it will.

> Rust is still too young to take advantage of this, but in due time it will.

I actually find Rust's standard library great. I think my only complaint so far is the lack of time handling. Luckily community packages (like Chrono, Diesel, Tokio, Hyper, Itertools) have implemented great solutions to a few missing details.

Hell, Iterators alone make my life so much better.

Go is designed to do concurrency via message passing, not shared memory. Yes, this is slower, but it also means you don't need a fancy borrow checker slowing down your compile.

instead you pay for context switches in the scheduler and suffer an order of magnitude slowdown in production. and when you profile and find the performance issue, you rewrite the portion of code to use mutexed shared memory to hit your performance targets.

Let me rephrase. Go was designed with the old best practice to share data of languages before Rust came: “you do not communicate by sharing memory, instead you share memory by communicating”. It is slower but you have to do this because Go can’t guaranty memory safety and doesn’t have system to prove that at compile time.

Then the team behind Rust after many research found that you can actually guaranty memory safety if you can track how data are used by each thread. To do this you need to track how each value is used and borrowed by each thread to insure memory safety. And so the borrow checker was born. It gives you the best of both world: speed And safety while adding only a little bit of time to the program to compile.

If Rust is slow to compile it’s not because of the borrow checker it only adds a little bit to the bottom line, but it’s because of Generics and other things. Which is also something that Go is lacking and doesn’t have yet.

> Go is designed to do concurrency via message passing, not shared memory.

... and yet experienced gophers will criticize newcomer's code for using channels too much and they will tell you you need to use traditional stupid shared memory approach instead of channels in many cases.

Reply on news.ycombinator.com