Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 2019 and beyond: limits to some growth

graydon2.dreamwidth.org

Post reply on HN
Print view View original

81–90 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#81

Post by kerkeslager »

pantalaimon wrote: post #72
CJefferson wrote: post #2

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 feel like C is having a renaissance because of that. C is very conservative in adding new features, which makes it easy to get an understanding of the language - nothing is hidden, when necessary you can derive everything you need to know about a piece of code from first principles. C compared to C++ feels like high school math compared to university math with all it's scary notations.

It's not just the notations, either. I'm not a particularly strong C programmer (I don't write it professionally, I write Python) but I've read documentation for the entire C standard library[1], for example.

[1] https://en.wikipedia.org/wiki/C_standard_library

Re: Rust 2019 and beyond: limits to some growth

#82

Post by jacquesm »

That is a super mature post whose content should be read by any language and/or eco-system component (libraries, frameworks and so on) creators and maintainers.

I love the intentionally limited scope and the amount of thought that went into writing this, and I wished I had the clarity required to be able to do this. Especially the bit about 'negative space' got my intention, that's one tool I'm going to put in my toolbox to re-use. And there already is one example from a company whose founder I knew that made serious bank on just knowing what they were not, so this advice has applicability far outside of computer programming language design.

Thanks for posting this.

Re: Rust 2019 and beyond: limits to some growth

#83

Post by pantalaimon »

lambda wrote: post #80
pantalaimon wrote: post #76

Earlier quoted context omitted.

I think the fear of unrefined behaviour is starkly exaggerated in everyday C programming. If you follow the established best practices (and the compiler will warn you if you don't) you will not experience undefined behaviour. > Those kinds of complexities aren't generally something for users to explicitly learn in rote memorization to use the language - if Rust introduced overloading and default arguments all those w…

> If you follow the established best practices (and the compiler will warn you if you don't) There are a lot of best practices that can be quite hard to follow without language support, and would generate too many false positives to warn about. For instance, use after free. There is no lifetime information available in the type system that the C compiler could use to tell you whether you are doing something that coul…

Common practice would be to set the pointer to NULL after free and if you have multiple pointers to the same object - well, try to avoid doing that. If you must, you can use reference counting.

Re: Rust 2019 and beyond: limits to some growth

#84

Post by nindalf »

steveklabnik wrote: post #28
gameswithgo wrote: post #27

Earlier quoted context omitted.

I have many times run into issues where a written down language spec would have been a big help. The are very useful features in the language that aren't mentioned anywhere in The Book, discovering them requires hoping someone on twitter mentions it, which is crazy. I would love to see a feature freeze and focus on writing down a spec and speeding up the compiler.

Absolutely! We’re working on it for a reason. The only thing not mentioned in the book should be HRTB. Did you run into something else?

Higher Rank Trait Bounds, for those not in the know. (like me)

Re: Rust 2019 and beyond: limits to some growth

#85

Post by wasted_intel »

pantalaimon wrote: post #83
lambda wrote: post #80

Earlier quoted context omitted.

> If you follow the established best practices (and the compiler will warn you if you don't) There are a lot of best practices that can be quite hard to follow without language support, and would generate too many false positives to warn about. For instance, use after free. There is no lifetime information available in the type system that the C compiler could use to tell you whether you are doing something that coul…

Common practice would be to set the pointer to NULL after free and if you have multiple pointers to the same object - well, try to avoid doing that. If you must, you can use reference counting.

> well, try to avoid doing that

I think that's pretty terrible advice for something that affects memory safety, and it invalidates your entire "the compiler will warn you" argument. There's a reason Rust has ownership and lifetime annotations: there are many things that a compiler simply cannot infer.

Re: Rust 2019 and beyond: limits to some growth

#86

Post by ajross »

qaq wrote: post #79
ajross wrote: post #48

Earlier quoted context omitted.

Or maybe it's just a fad. There have been far more failed IO paradigms than watersheds... I mean, I like it too, but the point upthread is that you can't just suck in every nice-looking idea or you'll end up like C++.

How is adding async await will make Rust into C++ ? Would people actually name the features that should not be in? Outside of ownership and borrowing have Rust added any features that are not mainstream and well proven in other languages?

How did adding exceptions to the language make C++ into C++? RTTI? Multiple virtual inheritance? Default member function generation?

They didn't, not individually. They were popular and uncontroversial (rather less controversial than promise apis, even). And yet...

The point is that Rust seems to be charging blindly down the same road, not that any one feature is going to blow it all up. Frankly IMHO Rust is already harder to learn for a median programmer than C++ is, even if it makes more aesthetic sense to an expert.

Re: Rust 2019 and beyond: limits to some growth

#87

Post by wasted_intel »

cryptonector wrote: post #39

> Reputation for overcomplexity, loss of users. Becoming the next C++ or Haskell. I think Rust is already there. It's a concern, but I'm not sure you can or should try too hard to avoid this. What you can do is look to make simplifications as you add complexity. And sometimes innovations can have simplifying effects. For example, the various "effects" libraries for Haskell simplify I/O code compared to not having the…

Rust 2018's non-lexical lifetimes are a good example of this.

Re: Rust 2019 and beyond: limits to some growth

#88

Post by dccoolgai »

chubot wrote: post #56
dccoolgai wrote: post #30

Earlier quoted context omitted.

As a longtime JS dev, I sometimes cringe for this reason when I see new features in ES. Even though I'm excited about them, when I think about experiencing them as a learner I feel intimidated. One good point the article makes that I wish more language designers accounted for is the fact that in a shared language you can't just pick and choose - to reach a level of expertise you basically have to know all of it.

Yes, I think you could know "all of" of JavaScript in 2009, in the ES5 era. Does anyone even remember that anymore? I'm shocked at how much the language has changed. I was experimenting with server-side JS in 2009, before node.js was released, and I hacked on Brendan Eich's Narcissus interpreter, which gave me a good sense of the language. Now when I look at example JavaScript code on the web, I invariably find somet…

Yeah, it definitely feels like ES6/7/Next is packed with features that theoretically make it a little faster to write code while making it monstrously slower and harder to read for at least 80% of practitioners... (destructuring comes to mind, with a syntax that is bafflingly similar to literal decs, that used to be the "good part") Seems like they made that choice every time.

I was reserving my thoughts about ES6 until I worked with it for a while, but now that I have, I have to say for those reasons you cited I don't like it as much as ES5.

Re: Rust 2019 and beyond: limits to some growth

#89

Post by dccoolgai »

Groxx wrote: post #41
dccoolgai wrote: post #30

Earlier quoted context omitted.

As a longtime JS dev, I sometimes cringe for this reason when I see new features in ES. Even though I'm excited about them, when I think about experiencing them as a learner I feel intimidated. One good point the article makes that I wish more language designers accounted for is the fact that in a shared language you can't just pick and choose - to reach a level of expertise you basically have to know all of it.

JS especially has been a rocket-ship of new language features lately. It used to be my go-to language for new people since it was so simple (when used with a few boundaries (like every language needs)) that it could be picked up and the basics understood fairly quickly, and you can set people free to look at other people's code, and gradually learn DOM APIs and whatnot as needed. Not any more. Not even close. The amo…

Case in point the "how to deal with asynchronous stuff" problem. Callback pyramids weren't great, but the pastiche of approaches that followed (promises, generators, async functions, etc.) Is starting to feel worse.

Re: Rust 2019 and beyond: limits to some growth

#90

Post by MBlume »

_0w8t wrote: post #66

Have other languages or libraries anything like the proposed anti-feature RFC that bans adding features in a particular direction? Go with its ban on generics that they hold for 10 years comes to mind. Anything else?

Not exactly the same thing, but PEP-404 made a negative commitment.

[https://www.python.org/dev/peps/pep-0404/]

Post reply on HN