Hacker News Reader

Comment by api | Hacker News Reader

Reading this confirms that I was right to pick Go for a couple things.

My very strong opinion is that the language should impose as little cognitive load as possible. Rust seems like it makes you think a lot about Rust, which means you are not thinking about the problem you are trying to solve. Brain cycles are a finite resource.

I don't want to diss Rust too much though. I see it as a potential future replacement for C/C++ for bare metal stuff where you really do want to hand craft the code for maximal performance or directly interface with hardware. That is a different niche than building higher level stuff, and I don't think anyone has managed to make a language that is good for both (yet?).

View on HN

Can't agree. Rust's goal, if you can call it that, is to make you think about things you should be thinking about anyway.

Coming from C, you should be thinking about lifetimes and mutability and sharing. If you dont, your program may work but be buggy. Rust forces you to think about that.

Go does the same thing in different ways at different costs. It trades memory/performance so that you don't have to worry about allocations and simply doesnt use standard shared mutability patterns (not exactly, but channels take up most of the same space).

I don't understand why the parent post of yours is getting this much downvotes. What's wrong with using a GC'ed language when performance requirements are permissive?

That's not precisely their statement even if it is their intention. I don't think anyone could argue that statement (though some may deny your axiom of lax performance requirements).

I think people are taking issue with the claims that _Rust_ is imposing the cognitive burden. As I said, these burdens already exist, languages just weren't forcing people to deal with them.

You mention cognitive load, however this post[0] about Go made me think that the "simplicity" of Go might come with it's own issues that lead to more cognitive load in the long run

[0]: https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild...

> My very strong opinion is that the language should impose as little cognitive load as possible.

The key there is "as possible." What is possible depends on the constraints and the goals. Rust does "impose as little cognitive load as possible" generally, given its goals as a language. You can nitpick about some parts of this, but at least all of the examples in the post have good reasons why they need to be this way, thanks to the goals for the language.

Rust and Go have different goals, and so "as possible" is something that means different things for each language.

On the subjective side:

> Rust seems like it makes you think a lot about Rust, which means you are not thinking about the problem you are trying to solve. Brain cycles are a finite resource.

This is true at the start, but once you get over the hump, you don't really spend any time thinking about this. The strictness is what lets you not need to care as much: the compiler will check your work, so you don't have to think about things very hard. It takes a while to get there though.

Rust doesn't compete with golang. The latter is in the same space as python. Rust competes with C++.

Rust competes with both, though some golang programs are quite reliant on general GC and rust would not be appropriate for those as of yet.

Reply on news.ycombinator.com