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

101–110 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#101

Post by qaq »

ajross wrote: post #96
qaq wrote: post #93

Earlier quoted context omitted.

I think there is fairly large difference between learning and being able to write production ready code. It's hard to imagine a person for whom Rust is hard to learn and who can write safe threaded code in C++ for example.

Hundreds of thousands of engineers are writing "production ready" C++ code every day. Your point seems trivially falsifiable, unless you want to turn it into a no-true-scotsman situation and explain how what they're "really" writing isn't "C++" or whatever. I'm not saying Rust is bad. I'm saying it's... becoming senselessly complicated. And that in 20 years when 60% of its amazing new features turn out to be just fas…

1) You omitted threaded

2) I seriously doubt you or I have good stats on how many people who are writing production ready C++ would consider Rust hard.

Re: Rust 2019 and beyond: limits to some growth

#102

Post by epage »

zanny wrote: post #58
epage wrote: post #6

Earlier quoted context omitted.

`failure` captures common error patterns in Rust and provided a test bed for experimenting on them while working to improve `trait Error`. There is an RFC for pulling some of the trait improvements into the language. After that, I believe they plan to continue to iterate on the design of the failure crate. The general recommendation I make and see from others is that `failure` is far from stable. Feel free to use it…

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. Coinciding with the 2018 edition release I ported one of my libraries to it that was using vanilla std::Error impls for two years and dropped about ~400 LOCs out of 600 lines…

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

Re: Rust 2019 and beyond: limits to some growth

#103

Post by lambda »

pantalaimon wrote: post #91
wasted_intel wrote: post #85

Earlier quoted context omitted.

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

I haven't looked into Rust very much yet, but doesn't the borrow checker effectively prohibit you from having multiple references to the same object? I wouldn't say it's terrible advice though. If I see that something I do is potentially dangerous and would require special care to get it right, I'd first look if there is another way to do it.

The borrow checker allows for one mutable reference, or multiple immutable references. There are also primitives for allowing interior mutability through shared references, which enforce single access at a time by other means (mutexes, copying data in and out, etc).

References are always guaranteed to point to something that lives longer than them. What they refer to could either be on the stack, or it can be allocated and deallocated on the heap via smart pointers. Box is similar to C++'s unique_ptr; there is a single owner, and when that owner is dropped, the referenced value is dropped. Arc is similar to C++'s shared_ptr; it's an atomically reference counted pointer, so the value will be deallocated when the last clone is deleted.

These combine in ways that allow you to use most of those "best practice" patterns from C and C++, but with actual language guarantees that you will follow them and the compiler will catch it if you don't. In the internals of data structure implementation, you may need to go beyond what this allows with use of unsafe, but you can limit that just to a few small critical pieces of code that can be more thoroughly audited and tested.

In a large project "try to avoid doing that" doesn't really fly; in a large codebase, with dozens of developers, developed over multiple years, people are going to make mistakes. They will need to do some kind of refactoring, and one of the guarantees will get missed.

If you've done a decent amount of work in a large C or C++ codebase, you might appreciate this description of the process of storing a reference to a slice of a Vec in Rust, without having to manually reason about all of the places in which that slice could be invalidated: https://manishearth.github.io/blog/2015/05/03/where-rust-rea....

This article, written as a way to help introduce Rust 1.0, provides a few more examples, though they are artificial rather than from a real-world project: https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h...

Re: Rust 2019 and beyond: limits to some growth

#104

Post by ajross »

qaq wrote: post #101
ajross wrote: post #96

Earlier quoted context omitted.

Hundreds of thousands of engineers are writing "production ready" C++ code every day. Your point seems trivially falsifiable, unless you want to turn it into a no-true-scotsman situation and explain how what they're "really" writing isn't "C++" or whatever. I'm not saying Rust is bad. I'm saying it's... becoming senselessly complicated. And that in 20 years when 60% of its amazing new features turn out to be just fas…

1) You omitted threaded 2) I seriously doubt you or I have good stats on how many people who are writing production ready C++ would consider Rust hard.

> 1) You omitted threaded

To Edinburgh we go, then.

Re: Rust 2019 and beyond: limits to some growth

#105

Post by munificent »

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 in one thing is the clearest way I know to free up mental capacity for the things I do want to put care into.

Re: Rust 2019 and beyond: limits to some growth

#106

Post by oscargrouch »

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

I dont think that by looking only to features we can understand this very well. Go was very lucky to be launched when cloud computing fever was catching up, and people were being burned for using techs like Java for this end.

C++ were very performant, and unlike Java not a memory hog, but for this sort of tasks it was deemed to complex. Besides the ammount of people that were able to program in it was limited (and you can even see this reasoning being used as a reason why they created Go).

Then Go showed up with simplicity and a good story in performance and memory, deploying simple binaries in a world of complex server infrastructure paved out by Java was a very handy and right on time approach.

The problem with Rust now, is that it is target the system programming, in a era of system programming renaissance given the whole mobile app scenery.

The problem is; there is already a lot of C++, C, Java, Objective C and Swift code there, so it will be hard to have a good reason to rewrite complex stuff with a lot of man hours in it in Rust.

Every language needs a platform. C is here because of Unix, C++ because of Unix, games and early 2000 and 90's era startups. Java and C# because of bussiness software, Go because of the cloud, Ruby and PHP; because of webservers, Rails an blogs, Python for educational purposes, Data Science, ML and now AI.

Now what about Rust? Its trying to eat some lunch from C and C++. But a lot of code and value is already there in C and C++, where rewriting it in Rust just for some ocasional added value here and there is not reasonable.

Its really tough, and if Rust dont find a platform to grow it will be very hard to advance any further. But, there's always new tech waves and tools that will marry perfectly with them.

Lets see which languages are able to be a perfect fit for them in years to come. But right now Rust will depend a lot of the community it already formed to keep sharp and maybe be lucky to surf one of those waves.

Re: Rust 2019 and beyond: limits to some growth

#107

Post by InGodsName »

shmerl wrote: post #69
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-…

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.

Re: Rust 2019 and beyond: limits to some growth

#108

Post by zanny »

epage wrote: post #102
zanny wrote: post #58

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. Coinciding with the 2018 edition release I ported one of my libraries to it that was using vanilla std::Error impls for two years and dropped about ~400 LOCs out of 600 lines…

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

Re: Rust 2019 and beyond: limits to some growth

#109

Post by z3phyr »

the_duke wrote: post #29
blattimwind wrote: post #9

Earlier quoted context omitted.

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…

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

Re: Rust 2019 and beyond: limits to some growth

#110

Post by burntsushi »

f2f wrote: post #64
steveklabnik wrote: post #19

Earlier quoted context omitted.

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.

There are no stones being thrown and no goalposts moving. Go's specification is clearly in a much more advanced and useful state than Rust's. The point is to respond to "how can people know." That is, it is a measure of degree, not binary.
Post reply on HN