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

111–120 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#111

Post by e3b0c »

cageface wrote: post #70
shmerl wrote: post #69

Earlier quoted context omitted.

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.

C is a language designed to enable more efficient communication between the computer and the programmer in mind.

C++ is a language designed to enable more communication between the compiler and the programmer.

Go is a language designed to enable more efficient communication between programmers.

Re: Rust 2019 and beyond: limits to some growth

#112

Post by mehrdadn »

munificent wrote: post #105
jacquesm wrote: post #82

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

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

Re: Rust 2019 and beyond: limits to some growth

#113

Post by burntsushi »

zanny wrote: post #108
epage wrote: post #102

Earlier quoted context omitted.

> Anything that would break failure in libraries written now would break all libraries because it would mean the fundamental Error trait has changed. Since failure is Error compatible you don't lose anything using it. Its only ~2500 lines of Rust. If you expose failure in your public API and failure makes a breaking change, it is a breaking change for your API because your clients need to be on a compatible version o…

Your clients don't though, you can have multiple versions of a crate in your build tree. Your failures aren't then compositable with newer failures as failures but they do impl Error and can be used as standard errors. The alternative is to just use... standard errors anyway? With the aforementioned sizable boilerplate? There's no downside to failure unless there's a less volatile error replacement you'd use instead.

That you can have multiple versions of your crate is exactly what enables the issues caused by public dependencies. It's not about multiple versions of your crate, but rather, multiple versions of the failure crate. If failure 0.2 is released (and doesn't use the semver trick), then you'll have two versions of the Fail trait, and thus, two versions of the failure::Error trait object. Madness then ensues for anyone using failure::Error (or dyn Fail in general).

failure is a victim of its own success. I think most everyone believes it's pretty close to what we want Rust's error handling story to look like. But it's a public dependdncy and everyone started using it. Now it's more difficult to evolve.

Re: Rust 2019 and beyond: limits to some growth

#114

Post by the_clarence »

sudeepj wrote: post #92

I have written non-trivial code in Go and Rust. My situation is C++ dev -> Go -> Rust -> Go (current day job). The shifts have been due to various circumstances on my day job. The thing is when I moved back from Rust to Go, I had forgotten how productive Go is and I felt something like this: https://youtu.be/1i_Eqj7wu88?t=50 (20-30 sec video) As someone who tried to "sell" rust in my org, I see the biggest issue is:…

Big fan of Rust as well, but this is why both Go and Rust are going to co-live. They are both amazing languages.

Re: Rust 2019 and beyond: limits to some growth

#115

Post by shaklee3 »

pantalaimon wrote: post #76
zanny wrote: post #52

Earlier quoted context omitted.

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

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…

I agree. I see comments like that time and time again. As someone who writes it professionally, it just doesn't occur as often as the internet would make you think.

Re: Rust 2019 and beyond: limits to some growth

#116

Post by klodolph »

cageface wrote: post #70
shmerl wrote: post #69

Earlier quoted context omitted.

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.

I don’t think Java and Go will ever, combined, reach the complexity of C++.

The reason why older languages are complex and inelegant is because our understanding of how to create simple yet useful languages has increased, not because older languages accumulate much complexity.

Re: Rust 2019 and beyond: limits to some growth

#117

Post by tzjmetron »

z3phyr wrote: post #109
the_duke wrote: post #29

Earlier quoted context omitted.

I was drawn to Rust because, behind the apparent complexity of the borrow checker, the language is/was actually very simple and easy to understand. I have been using Rust extensively for over 2 years. In those two years, the language complexity has increased substantially. It's already at a stage where I'm worried about losing track. Also, there is quite a large amount of changes in the pipeline that were already acc…

Try Zig too. Its on the stage when rust was 0.4 alpha, but it has some very great ideas and its really simple

I didn't see any USP for Zig. The syntax is also extremely crufty.

Re: Rust 2019 and beyond: limits to some growth

#118

Post by jniedrauer »

cageface wrote: post #54
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…

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

Go is still a very simple language. It's not just social engineering. Compare it to Python, which is another "simple" language that you can be dangerous in on day one.

As you gain experience in Go, you learn idiomatic ways to do things and memorize the core library, but the fundamental mechanics don't change.

As you gain experience in Python, you develop a preference for virtualenvwrapper and experiment with 300 different ways to build a distributable package, then start extending __getitem__ and __setitem__ and adding decorators to everything and before you realize what you've done, you've torn apart the laws of physics and your code has nightmarish side effects lurking around every corner.

Re: Rust 2019 and beyond: limits to some growth

#119

Post by tzjmetron »

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.

Nonsense. Take the favourite punching bag of many ubercool hipsters - Java. The language is dead simple, and extremely successful.

Re: Rust 2019 and beyond: limits to some growth

#120

Post by mroche »

InGodsName wrote: post #107
shmerl wrote: post #69

Earlier quoted context omitted.

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.

There is also a sunk cost fallacy which keeps people trapped.

Sunk cost or costly effort? There are a more than a handful of large of technologies, frameworks and libraries used in my industry which would have to be ported/rewritten and supported from C++ before anyone would think twice before using an alternate language. Particularly when speed is the name of the game (in terms of integration, not just compiled binaries). There are hundreds of C++ libraries employed daily that would be non-trivial to port.
Post reply on HN