Live data from Hacker News

Rust 2019 and beyond: limits to some growth

graydon2.dreamwidth.org

61–70 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#61

The comparison between C++ and Haskell is laughable, and shows that Graydon is missing the most important facet of this: GHC Haskell and Rust with have an intermediate language (Core and MIR + Chalk, respectively), which keep the rest of the language in tight check. No other mainstream language has this (Java bytecode doesn't really speak to high level safety properties). This ensures the vast majority of the languag…

I agree with you, but complexity is perceived by newcomers through the surface syntax of the language, not through an internal, mostly invisible IR. It's great that as advanced users, most of the perceived complexity can simply be thought of as sugar, but to a newcomer without an understanding of the core of the language yet, the complexity is often intimidating.

It's easy for a language designer to say things are just "forgettable sugar" whereas in the eyes of the users, they are anything but forgettable.

Re: Rust 2019 and beyond: limits to some growth

#62

I ran into the Failure crate today. It was hard for me to figure out if it was something official that was going to make its way into the core language or just a third party crate. If the former, should I avoid learning failure patterns that are not using this crate? It sometimes feel like the language is moving too fast for me to learn it.

The thing is that the description method in the Error trait in the stdlib is broken. I can't find the post on the internals.rust-lang.org atm, but the author of Failure has a plan for backwards compatibly fixing it and eventually moving (parts of) failure into the stdlib. The other thing about Rust error handling is the amount of boilerplate to convert between errors. Error-chain and failure are two iterations on how…

https://github.com/rust-lang/rust/issues/53487

Re: Rust 2019 and beyond: limits to some growth

#63
post #53

I can't agree more with this. I am a long time c++ dev, been to c++ committee meetings. The language is too complicated and inconsistent, and that is now I believe unfixable. I believe no one understands it. New features keep arriving, but you still have to learn everything that came before, for older codebases. For example, {} style initalisers were added to simplify and "unify" things. Except to make a vector of le…

No offense, but that's been the tune we've been constantly hearing for years now. Always the "next big thing" killing off C++ or Java or something with its superiority. And yet, somehow, when choosing a very efficient language that has 1st party support, we always end up with pretty much one widely supported answer: the horror that is C++. Why do you think that Rust will be a different story this time?

Most of us aren't concerned with whether anything would kill off C++. That certainly won't happen any time soon, given the inertia. But some of us would like to be able to use a language that lets you do low level, high performing goodness, without having to use C++. So it is nice that there are some more viable options now.

Re: Rust 2019 and beyond: limits to some growth

#64

As a newcomer to Rust and perhaps having been spoiled by Go's very readable specification, I was surprised that Rust doesn't have a definitive language spec. How do the people working on Rust ensure everyone has a common understanding of the language without one?

Some stuff is quite nailed down, some stuff is not. In the end, not breaking existing code is the most important thing. These things are always on a spectrum. Just because a spec exists doesn’t mean that it has holes; Go’s spec isn’t formally proven, for example, so you could make a similar claim: how can people know that it all works without a proof? The answer is that it’s all a spectrum. Many languages don’t have…

> Go’s spec isn’t formally proven, for example, so you could make a similar claim: how can people know that it all works without a proof?

that's moving the goalposts. let's see Rust's language spec finalized first, then we can talk about it being proven. without the two you shouldn't throw stones.

Re: Rust 2019 and beyond: limits to some growth

#65
Since when did you need to read, comprehend, and digest every language feature in Rust to ever use the language?

The absence of HKT / GATs / overloading / default arguments from the language doesn't make it easier for a newbie to learn. These aren't topics someone new, or even intermediate, should ever be touching until they need them. And in the absence of having this functionality (example - we JUST got const fn this month in stable) you have to work around the weaknesses of the language in often obtuse and cumbersome ways... such as hacking the macro system with lazy_static.

I think a lot of this sentiment comes back to what makes a language hard. I recently started learning CSS properly for once, now that Grid is in and I can just do all my styling by hand again in the same way I can use ES6 instead of JS frameworks. I needed Bootstrap and JQuery back in the day because despite the simplicity of the fundamental languages there were things I wanted to do that I could not do in an intuitive way. So other people wrote thousands of lines of code to make what should have been simple and accessible but the languages weren't expressive enough.

On the inverse, you need some degree of intuitiveness to your design. If I didn't read about the syntax of [] col [] col in CSS Grid I would have never intuitively thought you could name Grid regions. The syntax is completely arcane and arbitrary, isn't based on anything else common to CSS, and just happens to be. That is the source of real complexity in a programming language, not how long the book is or how many pages long the standard library is. Nothing worth learning or doing is so simple as to be digested in a weekend and trying to make a programming language like that, especially a systems one - one that has to expose all the jank complexities of how computers actually work - would have you make a really pretty paper weight nobody could use to get real work done.

The complexity in C++ is not in how big the template library is, or how many glyphs the syntax uses, but in how much mental stress it is to see void* = 0 or new Foo and have to juggle all the edge cases and eccentricities of the grammar and model on every single line. Its a massive weight on ones shoulders and that is what will drive a newbie away, at least a newbie with the mindset to take advantage of what they learn. Not the length of your book, so long as all those chapters are about things people want, need, and that are beneficial to the user, rather than warning them about all the ways they can break everything with a single character or how arbitrary decisions were made incongruent with the rest of the language because thats just the way it is.

C++ and C are not complex for their expressiveness, they are complex for their arbitrariness and lack of consistency. Same way Javascript and CSS are complex. Same way an actual, legitimate newbie to Rust is going to have much more difficulty processing why :: is the namespace delimiter or why you need curly braces to deliniate scope than how having the option to declare your function const would. Until they need const functions they don't need to touch them and can write all the non-const Rust they want. But now they have const when they need it and can often never touch something crazy like lazy_static again.

Re: Rust 2019 and beyond: limits to some growth

#67

I can't agree more with this. I am a long time c++ dev, been to c++ committee meetings. The language is too complicated and inconsistent, and that is now I believe unfixable. I believe no one understands it. New features keep arriving, but you still have to learn everything that came before, for older codebases. For example, {} style initalisers were added to simplify and "unify" things. Except to make a vector of le…

I've been dabbling in some Rust lately and as a long time mostly-C++-and-Python-and-some-Java dev I've found it relatively easy to get started with it. Sure, a lot of things are different (e.g. struct+impl vs. classes), many clearly better, some that may/may not be better just different, but overall it seems to me like Rust is relatively easy to pick up coming from C++. And C++ is usually way uglier and far more comp…

> The age of multi-vendored languages like C or C++ for systems programming might be coming to an end. I'd wager this is actually a good thing.

That's because you can't make money writing compilers anymore.

Re: Rust 2019 and beyond: limits to some growth

#68
It's interesting to see this critique of the Rust language's development process. There's a lot of process. Most of it aimed at adding new features. That may be part of the problem. The Go crowd seemed to know when to stop.

I've criticized Rust's growth here before. The big breakthrough in Rust was the borrow checker. Finally, one could have memory safety without garbage collection or reference counting. Huge improvement.

"Unsafe" opened too big a hole. I was looking forward to seeing more work on eliminating almost all need for "unsafe". Backpointer support. A way to talk about partially initialized objects. More static analysis. But that didn't happen. Instead, feature after feature was piled on, like C++. Individually, the features aren't bad, but cumulatively, Rust is now a very big language.

Meanwhile, C++ has been trying to retrofit Rust ownership semantics using templates. There's too much "be very careful" associated with that.

Re: Rust 2019 and beyond: limits to some growth

#69

I can't agree more with this. I am a long time c++ dev, been to c++ committee meetings. The language is too complicated and inconsistent, and that is now I believe unfixable. I believe no one understands it. New features keep arriving, but you still have to learn everything that came before, for older codebases. For example, {} style initalisers were added to simplify and "unify" things. Except to make a vector of le…

Maybe it makes sense to read the success of Golang as a smart piece of social engineering. Start with a simple and accessible language and gradually ratchet up the complexity to deal with more real-world problems. You may eventually wind up with a worse language but at least you'll have users. Rust tried to solve a lot of hard problems out of the gate and that has slowed its growth IMO. It's sort of another worse-is-…

That social engineering strategy only helps in the short term (short on the language scale, which can still be many years). If you get a convoluted language in result, in the long term it will increasingly irritate programmers, who will anyway start looking for objectively better alternatives. So Rust took the right approach IMHO.

Re: Rust 2019 and beyond: limits to some growth

#70
post #69

Earlier quoted context omitted.

Maybe it makes sense to read the success of Golang as a smart piece of social engineering. Start with a simple and accessible language and gradually ratchet up the complexity to deal with more real-world problems. You may eventually wind up with a worse language but at least you'll have users. Rust tried to solve a lot of hard problems out of the gate and that has slowed its growth IMO. It's sort of another worse-is-…

That social engineering strategy only helps in the short term (short on the language scale, which can still be many years). If you get a convoluted language in result, in the long term it will increasingly irritate programmers, who will anyway start looking for objectively better alternatives. So Rust took the right approach IMHO.

What tends to happen is that you bring out a simplified, cleaned-up version of the popular language of the day. People then flock to that new language and start making feature requests. Over time that language becomes as complex and inelegant as the language it replaced and you can start the whole cycle all over again.

The move from C++ -> Java -> Go is a perfect example of this cycle.

Post reply on HN