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

131–140 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#131

Post by Thiez »

zanny wrote: post #52
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 don't feel like C was ever meant to be the permanent foundation on which all other computing was built. It was a language for its time. It took assemblies of the 70s made them much more palatable with an imperative syntax. C++ was also not meant to be a permanent foundation. It took shortcomings in C for scale and hacked on top functionality Bjarne wanted. The complexity difference between a computer 46 years ago,…




> if Rust introduced overloading and default arguments all those who don't know it exists won't have the language made any harder to use, but those that want it can take advantage of it.

The following program might no longer compile if `f` could be overloaded, additional type annotations would be required.

    fn f(n: u8) -> u8 {
        n + 5
    }
    let o = Some(Default::default());
    println!("{:?}", o.map(f));
In general I would expect overloading to make type inference less reliable (not so much with the compiler getting it wrong, but needing more annotations), which users of Rust that do not want overloading would be right to object to.

Re: Rust 2019 and beyond: limits to some growth

#132

Post by dbaupp »

Animats wrote: post #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 improve…

All of those unsafe "hole fixes" are features, meaning your desires are for adding even more features.

Additionally, useful back pointer support (i.e. for anything more than a toy doubly linked list) is probably a bigger feature than anything else added since Rust 1.0, and probably harder to work with.

Re: Rust 2019 and beyond: limits to some growth

#133

Post by usrusr »

mehrdadn wrote: post #112
munificent wrote: post #105

Earlier quoted context omitted.

> Especially the bit about 'negative space' got my intention, that's one tool I'm going to put in my toolbox to re-use. One of the most profoundly useful things I've ever realized in my life is that the most important choices are often about deciding what not to do. Creativity is deeply wedded to the idea of constraints and pragmatically, there are only so many hours in the day. Deliberately deciding to not investing…

I see the value of deciding what not to do for version(s) X of something , but ruling something out for all eternity seems a little... short-sighted? Who's to say that what you're ruling out won't become the next big concern for everyone and your technology won't be the odd one out without it?

There are two possible ways to deal with that situation: create something new that is the old thing plus the feature that had been ruled out for it, or simply revoke that decision. Eternity can be surprisingly short when everybody agrees that it is time to move on.

Both ways are perfectly possible, and both would in many cases be much preferable to having an implicit "is it time yet for X?" on the agenda every time the version number is incremented. "Not in the foreseeable future" is effectively understood as a far out roadmap item, no matter how much you don't mean it that way.

I'd rather see a humble "we thought that we would never X, but we were wrong" repeated for many different X than a single misleading "we absolutely commit to not be adding GOTO before 2025".

Re: Rust 2019 and beyond: limits to some growth

#134

Post by augustk »

gpderetta wrote: post #60
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…

There are only two types of languages, those that are too complex and those that aren't yet.

There is at least one language that evolves in the opposite direction. The philosophy of Oberon is that "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

Re: Rust 2019 and beyond: limits to some growth

#135

Post by dullgiulio »

kentrado wrote: post #128
amelius wrote: post #67

Earlier quoted context omitted.

> 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.

Why?

LLVM and GCC are dominating the space and pretty much killed propretary compilers.

Re: Rust 2019 and beyond: limits to some growth

#136

Post by nabla9 »

jurip wrote: post #130
cageface wrote: post #54

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-…

This is what Guy Steele's Growing a Language talk was all about: "I should not design a small language, and I should not design a large one. I need to design a language that can grow. I need to plan ways in which it might grow—but I need, too, to leave some choices so that other persons can make those choices at a later time." https://www.youtube.com/watch?v=_ahvzDzKdB0 or as PDF: https://www.cs.virginia.edu/~evans/c…

Guy's point was that the language should be designed to be grown grown by users, not by language designers.

> We need to put tools for language growth in the hands of the users.

Guy's previos work with Common Lisp is epitome of this. There are three kind of macros in the language: reader macros, macros and compiler macros. They give the tools for the user to extend the language. There is just 25 or so core primitives in the 'core' language and the runtime. The rest 900+ functions and symbols are basically the standard library (the fact that they are slapped into the same package and they extend the core in a ways that other languages can't hides the simplicity of the language somewhat).

Re: Rust 2019 and beyond: limits to some growth

#137

Post by cageface »

jurip wrote: post #130
cageface wrote: post #54

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-…

This is what Guy Steele's Growing a Language talk was all about: "I should not design a small language, and I should not design a large one. I need to design a language that can grow. I need to plan ways in which it might grow—but I need, too, to leave some choices so that other persons can make those choices at a later time." https://www.youtube.com/watch?v=_ahvzDzKdB0 or as PDF: https://www.cs.virginia.edu/~evans/c…

I think this is a really appealing idea but so far nobody’s managed to build a successful language this way. I’d love to see a mainstream language designed on these principles myself but I think it’s not going to be an s-expression based language.

Re: Rust 2019 and beyond: limits to some growth

#138

Post by duncanawoods »

jurip wrote: post #130
cageface wrote: post #54

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-…

This is what Guy Steele's Growing a Language talk was all about: "I should not design a small language, and I should not design a large one. I need to design a language that can grow. I need to plan ways in which it might grow—but I need, too, to leave some choices so that other persons can make those choices at a later time." https://www.youtube.com/watch?v=_ahvzDzKdB0 or as PDF: https://www.cs.virginia.edu/~evans/c…

It's been a while since I watched this but my current thoughts on "Growing a language" is that I fear it is an unhelpful simplification of what makes language design hard. IMHO language design is a holistic design problem that needs global optimisation. You cannot incrementally hill-climb yourself anywhere useful when you can't backtrack over past decisions.

It is like designing a workshop. You only have so much space within arms reach. Here you place your most frequently used and valuable tools. You can "grow your language" by adding tools but they can't replace what you have in this limited and privileged position - instead, new tools have to go in cupboards or on another table. The new tools will have higher friction than the first priority tools you added.

Maybe you can have a workshop where you imagine a tool and it appears in your hand thereby removing the constraint of "tools within reach" but I think this then makes it too ephemeral and abstract. It is the constraints that makes a language tactile and ergonomic - remove the constraints and you have no structure at all.

In this case, the "tools within reach" are your core keywords and syntax. Growing features via libraries or syntactic extensions generally incur more ceremony and less elegance. Having totally flexible syntax extensions/keywords doesn't solve the problem, it just moves up a level abstraction/generality and means you have given your users the "design a language" problem instead of solving it for them.

Re: Rust 2019 and beyond: limits to some growth

#139

Post by dullgiulio »

_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?

Go never banned generics, it just set a very high bar of integration with the rest of the language.

The idea is that Go is one language with a very specific personality: if it changes that much it just becomes another language and can as well be called something else.

Re: Rust 2019 and beyond: limits to some growth

#140

Post by knowThySelfx »

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…

The Java crowd moving to JS could be one reason. Add in a bit of functional programming concepts too.
Post reply on HN