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

The struggle with Rust

ayende.com

Post reply on HN
Print view View original

271–280 of 301 posts

Re: The struggle with Rust

#271

Post by AstralStorm »

nercury wrote: post #13
creshal wrote: post #8

Earlier quoted context omitted.

So how do you avoid it?

Well, you either uniquely mutate, or keep the value immutable. Usually you construct the pipeline to switch between these as you need. If you need to share the result from one mutation to the other, you can do it by passing a simple immutable value that communicates the state change to other mutation, but don't try to do both at the same time. This is simply a good practice enforced at compile time. Of course, someti…

The problem is there is nothing like "atomic mutable", equivalent of C++ std::atomic with at least sequential consistency.

So you get to drop all safety often instead to have shared mutability.

Re: The struggle with Rust

#272

Post by AstralStorm »

eximius wrote: post #139

If you just want to allocate a chunk of memory for random use like you would in C, it can't be guaranteed to be safe. So I would hope you need to jump through hoops.

It is a rust weakness that it does not have "partial unsafe" that guarantees some things. Makes many kinds of code unnecessarily hard to reason about.

Re: The struggle with Rust

#273

Post by AstralStorm »

gravypod wrote: post #221
junke wrote: post #207

Earlier quoted context omitted.

This example works in SBCL, where types (possible disjoint sets of values) are treated as assertions. By default I always set "safety" and "debug" to 3 (the max), which helps. ;; Giving names to abstract things a little (deftype zero () `(eql 0)) (deftype non-zero () `(and number (not zero))) ;; Declaration (declaim (ftype (function (number non-zero) number) divide)) ;; Definition (defun divide (n d) (/ n d)) ;; Test…

Yes that is exactly what I'd like but I'd like something that's grown past just type checking. There are many more bugs that I know can be caught by a theorem prover. Edit: I want to clarify. I think just type checking should be written as "Just type checking".

Indeed, something like what is being tried in Pyret to make contracts (a kind of theorem lemma) the first class citizen.

Re: The struggle with Rust

#274

Post by AstralStorm »

dbaupp wrote: post #247
AstralStorm wrote: post #239

Earlier quoted context omitted.

However, typed and separate memory areas with various allowed kinds of concurrent access are needed. Even simple RAM has multiple modes, plain, atomic of multiple kinds, barriers... On top of that, you get devices that handle access only with delay inbetween, can never be accessed concurrently (volatile), have alignment requirements and more. Rust memory model is too weak to enforce safety in such cases while not sac…

Rust gets all your favourite kinds of atomics and barriers, exactly like C. Other things are indeed hard to get safe, which is why Rust has `unsafe`: it is possible to use them, marking out the dangerous regions precisely, rather than the whole program being `unsafe` just because a few places need niche features. In any case, Rust is definitely not written with "I have one CPU" in mind. A slogan that is sometimes use…

No, by one CPU i meant not a single core. I meant not having to manage different memory models and available access patterns. Or different ways of handling race conditions and alignments.

You get to use unsafe almost exclusively in the internals of such access where it shouldn't be necessary if there are ways to specify more properties than just binary "safe" and "unsafe".

It is extremely hard to prove such code correct in Rust.

Re: The struggle with Rust

#275

Post by gcp »

eternalban wrote: post #152
gcp wrote: post #101

Earlier quoted context omitted.

And imho the initial promise of addressing the out of control complexity of C++ was not met. I'm not sure. Type traits seem to be much more manageable than how the same thing is handled in C++ template code, no? Also, if we can bring in ecosystem effects such as cargo...

I guess I should have added that I last touched C++ in '96 and never (ever) have had an urge to look back. :)

I've you've never seen template programming, but just C with classes, then yes, I can see how you arrive at this conclusion. C++ in 2017 is very different from what it was in 1996.

Re: The struggle with Rust

#276

Post by gcp »

sidlls wrote: post #125
gcp wrote: post #41

Earlier quoted context omitted.

Rust's niche seems very clear: C++ programmers that need better tools. This is an audience that should be willing to make a time investment, and understands the trade-off, for the most part.

I disagree to some extent, for a couple of reasons. First, C++ programmers in aggregate have to consider more than the choice of language for their projects. Odds are they work for somebody else, on a team, an established project, whatever. In these cases "C++ programmers need better tools" doesn't mean "toss the bath out with the water." Rust isn't necessarily a good move in established products, in other words. Sec…

I don't disagree - my statement was also directed to people new to this field.

The overhead for existing C++ teams is learning the language, and (potentially AFAIK) interfacing with C++ code that has no good C style API. But Rust seems to tackle even the latter quite well. I don't think you'll get around the learning curve for a new language.

Re: The struggle with Rust

#277

Post by gcp »

braveo wrote: post #169
gcp wrote: post #97

Earlier quoted context omitted.

My point is that C++ has a learning curve that's as steep as Rust's. Rust is a C++ replacement. So this isn't a disadvantage for Rust. It may stop Rust from getting widespread adoption, but I see no problem with that. C++ isn't "widely used" either by most meanings. Rust may still largely replace C++ even without magically having a less steep learning curve. (Which it, IMHO, actually has anyway.)

> My point is that C++ has a learning curve that's as steep as Rust's. Rust is a C++ replacement. So this isn't a disadvantage for Rust. As someone who learned C++ first and later Rust, no it isn't. Rust's learning curve is a hell of a lot higher than C++'s. This reminds me of when Java was trying to compete with C++, you would have all these Java people making claims that HotSpot was going to take over the world and…

NO WAY is C++ harder to learn than Rust

I've been programming C++ for 16 years, it's the main language at my day job, and I won't even begin to think I understand templates. But you'll see codebases that use it regularly. Const correctness? rvalue vs lvalue? ODR? SFINAE? RVO? exception safe code? template argument deduction? Then you have C++11, C++14, C++17...

Despite this, I still regularly write code that has memory, string, concurrency and bounds bugs. So does everyone else in the industry, including smarter people with more experience.

It's possible that the parts of Rust I'm not familiar with (e.g. unsafe code, macro system) turn out to be similar sinkholes, but so far, that doesn't seem to be the case.

Re: The struggle with Rust

#278

Post by AstralStorm »

pcwalton wrote: post #168
rubber_duck wrote: post #64

Earlier quoted context omitted.

Yea that's what I see as an issue as well, I was hoping it wouldn't be but the deeper I go in to Rust the more it shows up. On one hand a really simple solution would be to make unsafe a first class citizen when it makes sense, this would let you avoid "pushing square pegs in to round holes" solutions when the borrow checker doesn't capture your problem nicely, and it would be trivial for C++ devs to get on board. On…

> On one hand a really simple solution would be to make unsafe a first class citizen when it makes sense I have pushed this several times in the past, but there's always been a lot of resistance to the idea. Though I've always phrased it as "let's allow the safety checks to be turned off", which isn't necessarily the best phrasing... I wonder if it'd be better to just push to make unsafe easier to use : add sugar for…

Or better extend the language to allow making code partially safe in many ways. This would make the wrappers much better.

Make it easy to reason about useful kinds of partial safety. Make it easier to define properties of external systems that Rust does not control.

Re: The struggle with Rust

#279

Post by AstralStorm »

yellowapple wrote: post #173
tonyedgecombe wrote: post #47

Earlier quoted context omitted.

I doubt moving from Java to C++ would be that trivial, Java is a comparatively safe language without many of the issues that will trip you up in C++.

In particular, the lack of pointers in Java would probably annoy the article author as much as Rust does.

Personally (not the author) I am more annoyed by the gutted single inheritance no traits type system.

You have numeric pointers into arrays, they're called indices.

Re: The struggle with Rust

#280

Post by pcwalton »

AstralStorm wrote: post #278
pcwalton wrote: post #168

Earlier quoted context omitted.

> On one hand a really simple solution would be to make unsafe a first class citizen when it makes sense I have pushed this several times in the past, but there's always been a lot of resistance to the idea. Though I've always phrased it as "let's allow the safety checks to be turned off", which isn't necessarily the best phrasing... I wonder if it'd be better to just push to make unsafe easier to use : add sugar for…

Or better extend the language to allow making code partially safe in many ways. This would make the wrappers much better. Make it easy to reason about useful kinds of partial safety. Make it easier to define properties of external systems that Rust does not control.

Can you elaborate this into a concrete proposal?
Post reply on HN