Hacker News Reader

Comment by gyre007 | Hacker News Reader

One of the things that hit me when I was picking up Rust was that I felt like it had every imaginable feature one could think of - I dont know if Rust team said no to anything (yes I know they obviously must’ve done) - and yet people wanted more and more (some justifiably, others less so) as the language “felt” incomplete or that the features thatd be used by 2% of devs are totally necessary in the language that is “understood” by 1% of developer populace. I’m not saying the author is wrong here, just pointing out how a complex language somehow needs to be even more complicated. Spoiler: it doesn’t. Zig is simpler, arguably faster, with much less drama in the community. I wish more funding went to Zig.

View on HN

You'll be surprised by the amount of features that are often proposed by random people and are then rejected by the Rust community. Rust is definitely not trying to add all possible features, though you might get that feeling when you look at some feature like GATs and TAITs without having a clear idea of what problems they solve.

Also, Zig might be a nice modern language, but it is not an option if you're aiming for memory safety.

I think any replacement for c/c++ will not be strictly safe from memory safety vulnerabilities, but I think both Rust and Zig go far enough to effectively nearly eliminate that entire class of vulns in production software. Rust achieves further memory safety than most with its borrow checker but in many cases that seems to be more about safety from crashing than vulns. For example, Go is not memory safe under concurrency, but there have been no memory safety vulns related to its concurrency ever.

One could also argue Rust's unsafe blocks will be harder to reason about bugs in than Zig code. And if you don't need any unsafe blocks it might not be an application best suited to Zig or Rust.

GAT solves typing problems (by making a subset of HKT possible)

Author here.

> I’m not saying the author is wrong here, just pointing out how a complex language somehow needs to be even more complicated. Spoiler: it doesn’t.

True. But I think a lot of rust's complexity budget is spent in the wrong places. For example, the way Pin & futures interact adds a crazy amount of complexity to the language. And I think at least some of that complexity is unnecessary. As an example, I'd like a rust-like language which doesn't have Pin at all.

I suspect there's also ways the borrow checker could be simplified, in both syntax and implementation. But I haven't thought enough about it to have anything concrete.

I don't think there's much we can do about any of that now short of forking the language. But I can certainly dream.

Rust won't be the last language invented which uses a borrow checker. I look forward to the next generation of these ideas. I think there's probably a lot of ways to improve things without making a bigger language.

> I wish more funding went to Zig.

Unfortunately that attracts the worst types. And their crapness and damage potential is sometimes not realised until it’s way too late.

I'm curious, what drama in the Rust community are you referring to?

I see some drama associated with Rust, but it's usually around people resisting its usage or adoption (the recent kerfuffle about Rust for Linux, for example), and not really that common within the community. But I could be missing something?

Zig is great, but it just isn't production ready.

>I'm curious, what drama in the Rust community are you referring to?

https://news.ycombinator.com/item?id=36122270 https://news.ycombinator.com/item?id=29343573 https://news.ycombinator.com/item?id=29351837

The Ashley "Kill All Men" Williams drama was pretty bad. She had a relationship with a core Rust board member at the time so they added her on just because. Any discussion about her addition to the board was censored immediately, reddit mods removed and banned any topics and users mentioning her, etc.

Yes, she was dating him at the time. It did not go well for Rust, https://news.ycombinator.com/item?id=28633113 https://news.ycombinator.com/item?id=28513656

Ashley is just one out of many, unfortunately. Other former and current top contributors share similar qualities. Those qualities tend to trigger unnecessary explosions like last year's https://www.reddit.com/r/rust/comments/13vbd9v/on_the_rustco....

On drama: https://users.rust-lang.org/t/why-is-there-so-much-mismanage...

Also, Zig is set to release 1.0 beta in November.

I think the replies in that thread actually do a good job of describing how it is a bit overblown.

As for Zig, I hope they make it. I think I kind of see why people are excited about it, but fundamentally the reason I'm not super hyped is that it doesn't seem to really enable anything new. It's far more expressive than C, but it doesn't make it easier to manage inherent complexity (to my understanding - haven't played with it a lot).

Zig is not even close to a 1.0 beta this year. Or even next year.

For example, the async problem still exists and still has absolutely no viable path forward, or even MVP approach.

Any source on the zig 1.0 thing? As far as I can tell it is not even on thr horizon.

The graveyard of features in nightly is actually pretty big. Important stuff like specialization is forever stuck there.

AFAIK many of those language features (specialization included) are blocked by the rewrite of the trait solver.

Afaik specialisation (in full generality) would cause soundness issues, so it's not even just blocked by the trait solver, it's also blocked by figuring out a 'slimmed down' proposal that fixes those.

And that's not even getting into the problem that it's a fairly controversial feature, since people are worried about terrible, hard to track specialisation trees. (See, inheritance.)

> Afaik specialisation (in full generality) would cause soundness issues, so it's not even just blocked by the trait solver, it's also blocked by figuring out a 'slimmed down' proposal that fixes those.

There is already a proposal for how to prevent unsound specializations [0], but it requires a lot of support from the trait solver, hence why I said it's blocked on it.

[0]: https://smallcultfollowing.com/babysteps/blog/2018/02/09/max...

I think there is a bigger issue with specialization, and it's that nobody seems to agree in what the semantics should be. The orphan rules are clearly artificially limiting, but there is no formal description of a new set of rules to replace them, only proposals.

Specialization would not replace orphan rules though.

While there are trucks of nightly only features, some are stuck there for a good reason.

Specializations allow unsound behavior in safe Rust, which is exactly what nightly was supposed to catch.

>with much less drama in the community

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Much of Rust's (and almost every other large programming language) drama are problems of scale, not implementation. The more funding you wish for will indubitably create more drama.

Zig is already far more complex than what was originally presented anyway, while Rust 1.0 and the current Rust are mostly identical. (Pre-1.0 versions of Rust were heavily changing and overwent at least two or three extreme changes that make them essentially different languages with the same name.) Zig should be funded more for other reasons, but I don't think Zig would be safe from this eventual complexity problem.

I wish Zig had a borrow checker... then we could see how much better it would fare.

(This is not a diss on Zig at all, I love its approach!)

> I felt like it had every imaginable feature one could think of - I dont know if Rust team said no to anything

Ah, like Scala you mean?

Reply on news.ycombinator.com