Comment by endorphone | Hacker News Reader

Comment by endorphone | Hacker News Reader

Parent Full thread

This is the killer feature of Go, and it's what so many who clamor for various features-of-other-languages miss.

Go is designed for simplicity. It is easy to write, but more importantly is easy to understand, even far in the future. For a given problem, n programmers will generally coalesce on a small number of possible Go implementations, whereas other languages will often yield n divergent solutions.

I've had Go solutions that I built years ago that I can get into and maintain in seconds, even when I hadn't touched Go in months.

Go isn't my primary tooling (my life today is mostly Swift), but as a comparison where a language has gone awry I'd point to C# -- as Microsoft has tried to incorporate whatever cool thing every other language has added, C# projects have often turned into write-only projects where the original author barely can grok their code a month later, and everyone shrugs and says "rewrite it" when confronted with another programmer's C# code. Rust is much the same.

Can you give an example of Rust incorporating "whatever cool thing every other language has added"?

I have never had the experience of Rust code becoming write-only after a month, and I don't know anyone else who has either.

That statement was clearly in reference to C#, which evolved from a beautifully concise language to now being a mishmash of every other style of programming (including the abomination that is LINQ).

Rust, though, suffers from being too clever, making it a language in which you can make concise, powerful solutions, but it can making grokking the code difficult, inefficient and error prone.

This is where our egos step forward and we announce that it's No Problem For Me, but we've all experienced a situation where we've leveraged a powerful language to do some amazing things, and then a month later it is a gruelling, headache inducing experience trying to figure out what is doing what, where, so we announce that we'll just rewrite the whole thing.

> Rust, though, suffers from being too clever, making it a language in which you can make concise, powerful solutions, but it can making grokking the code difficult, inefficient and error prone.

Outside of the borrow checker and invocations relateeld thereto, Rust is fairly simple and transparent. The borrow checker forces you to think through things which are common sources of error before you can code things, which is mostly good, but a necessary cost of that is you also have to learn a whole vocabulary, symbology, and analytic approach around it.

While that does (at least until you've climbed the borrow checker learning curve, a place I haven't gotten past myself) make it harder to grok some code and, even moreso, makes it harder to write some code, I don't find that it promotes false understanding of code as much as very clear lack of understanding of what bits of unfamiliar code are doing.

OTOH, while there are simpler approaches to subsets of the same issues, I don't know that there's anything which really offers what Rust offers at lower cognitive cost.

> Rust, though, suffers from being too clever, making it a language in which you can make concise, powerful solutions, but it can making grokking the code difficult, inefficient and error prone.

Can you explain specifically how Rust is supposedly too clever?

With all due respect, I don't think you're in a position to have a unbiased perspective on this, and I am certain I'm never going to convince you.

But I'll leave it that there have been countless "Rust is too difficult" links for you to find on Google, many of which have been posted on here. And invariably when we discuss Rust the conversation goes like this-

"why is it so complex to do [some simple thing]?"

"Oh well Rust is a System Programming Language, and it's doing important things in important ways"

"Okay, but I'm not building an OS, I'm just..."

[chest puffing, ego's appear, etc]

"Well I certainly have no problem with it..."

I’ve found Rust users to be very helpful, especially on Hacker News.

For example, in this thread from two weeks ago someone asks why it’s so frustrating to concatenate strings of mixed types in Rust:

https://news.ycombinator.com/item?id=20124821

And Steve Klabnik offers a friendly and ego-free reply with a simple and helpful option to do just that.

I’m sure there are other examples of flame wars, but I wouldn’t associate Rust advocates with chest puffing and egos at all.

I still can't figure out exactly what design decisions you disagree with, but it sounds like you're objecting to the lack of GC or memory safety. There are some applications for which GC is not appropriate. Maybe you don't work on any of those applications. That's fine, but that's very different from saying Rust is overly complicated.

I think this is a great point that indirectly highlights how people are often talking past each other when a go vs rust debate comes up. People work in different problem domains with different constraints and therefore the a good language choice in one domain might be wrong for the other.

I don't think anyone in the go community would suggest you write a browser in go. Ignoring the GC performance issues, just the awkwardness of using cgo would make most go developers shudder.

Likewise there are many problem domains where a GC'ed language works just fine. In these cases it is appropriate to consider other factors when deciding which language to use. Perhaps your team is made up of a bunch of experienced scala developers, scala might be a good choice for you over go or rust. That doesn't mean your good choice is universally applicable to all teams.

Some teams might care more about getting the most value per cpu cycle possible. Other teams might care more about the time it takes to get a new engineer up to speed in the language. Both of these can be valid reasons to choose a specific language.

I guess what I'm trying to say is: "Try to choose the language (and other tools) that best matches your organizations constraints. Don't assume that other teams have the same constraints."

"too difficult" is not the same as "too clever" or piling on too many features and encouraging errors.

Do you agree with the sibling comment of "Outside of the borrow checker and invocations related thereto, Rust is fairly simple and transparent."? And the assertion that while it's difficult it doesn't make you misunderstand code?

It is kind of sad to see a simple question answered with a personal attack.

This kind of answers doesn't belong here imo.

There is no personal attack in the comment you replied to.

Trying to inject an invented narrative to quiet comments you don't like absolutely doesn't belong here.

> "why is it so complex to do [some simple thing]?"

To be fair to endorphone, this does happen quite often - mostly, because people often fail to immediately grok the sorts of idioms that will easily pass Rust's borrow checker. As a general rule, it's something that is solved by properly dealing with shared mutability and shared ownership. But failing to deal with these is a pretty bad code smell anyway, so IMHO there's nothing wrong with a language which prompts you to do that! Hopefully, we're not going to equate avoiding blatant code smells with "chest-puffing" and "ego"!

I almost never use the LINQ syntax, as the helper methods with lambda expressions make a LOT more sense to me.

I'm pretty new to Rust and can understand the critique... I think the biggest issue really comes down to a lot of code written, and an ever evolving canonical way of doing things. I think it'll get better with time, and does have some nice features for workflows that are difficult in Go.

Personally, I'm a huge fan of Node/JS as I just get stuff done. Most of my work doesn't need the ultimate in memory/performance as a lot of it is just gluing things together and it does very well as a scripting environment imho. Windows, Mac, Linux and very little friction. I like JS as a language and will leverage functional, some oop and procedural styles in different aspects of an application where they're a better fit for that aspect. Most languages aren't that flexible.

Reply on news.ycombinator.com