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

The Rust I wanted had no future

graydon2.dreamwidth.org

Post reply on HN
Print view View original

461–470 of 523 posts

Re: The Rust I wanted had no future

#461

Post by astrange »

intelVISA wrote: post #367
pjmlp wrote: post #217

Earlier quoted context omitted.

The fatal mistake is not enabling bounds checking, which most STL implementations support.

-Wabsolutely-everything I haven't written the Language of Kings in a while: does GCC -Wall truly enable all warnings yet?

It doesn't, and that would be a bad thing, because warnings aren't magic and bug-free themselves. Nor is there any reason to comply with every single warning every person in the world has come up with.

clang has a -Weverything and it isn't supported.

Re: The Rust I wanted had no future

#462

Post by astrange »

svieira wrote: post #429
svieira wrote: post #266

Earlier quoted context omitted.

_Unyielding_ describes the issues that arise when the author of the code doesn't have control of the transactionality / atomicity of their operations at the level they need to: https://glyph.twistedmatrix.com/2014/02/unyielding.html To my mind it's very much a balancing act between "low power to the developer, high power to the language" and "high power to the developer, low power to the language" all up and down the…

See also: https://www.tedinski.com/2018/11/06/concurrency-models.html which is the first article I've ever seen that says that `m:n`-style-green-threads are bad and good at the same time. TL;DR - he says that "doParallel" and "doConcurrently" are separate operations with distinct semantics that designers of programs must care about and that conflating the two (especially the common "doConcurrently-and-often-but-not-a…

A common thing about writing like this article is that it confidently declares futures/promises are good for parallelism, but this is wrong - they are flawed because they introduce priority inversions.

To schedule tasks properly, you need to know who is waiting on them as early as possible. With a promise, you only know when you get to the "wait()" call, which is too late.

The correct solution is called structured concurrency.

Re: The Rust I wanted had no future

#463

Post by krupan »

kzrdude wrote: post #404
krupan wrote: post #167

The key challenge of rust for me: "Complex grammar. I've become somewhat infamous about wanting to keep the language LL(1) but the fact is that today one can't parse Rust very easily, much less pretty-print (thus auto-format) it, and this is an actual (and fairly frequent) source of problems. It's easier to work with than C++, but that's fairly faint praise. I lost almost every argument about this, from the angle bra…

Is there a practical issue with this, or is this more philosophical?

I'm not parsing expert, but being hard to parse makes it harder to write tools that work with the language.

Personally I find rust to be not easy at all for humans to read, and so it's interesting that it's also hard for parsers to parse. Not sure what was optimized for in the design.

Re: The Rust I wanted had no future

#464

Post by steveklabnik »

FpUser wrote: post #448
Ygg2 wrote: post #439

Earlier quoted context omitted.

>Are you saying that Rust will refuse to compile code that does not explicitly Depends what you mean by explicit. Look at it like this: pub fn main() { let mut vec : Vec = vec![]; let x = vec.pop(); println!("{:?}",x); // prints: None } In this case you see the value is missing. vec.pop().expect("I want a value") will panic with "I want a value" because value is empty. And most rigorous way to deal with it is: if let…

for some reason I can not answer your subsequent reply so I do it here: I looked at your example and played a bit with it and yes I agree with you - compiler does help in this case. My old text: So instead of checking if vector is not empty you check that the return result is not empty. I do not see much difference. If Rust compiler would choke when "else" clause in your example is not present I would understand your…

> for some reason I can not answer your subsequent reply so I do it here

Hacker News will try and discourage really quick back and forth comments. To do so, the reply button is hidden. However, if you click on the timestamp, to go to the comment's own page, you can reply there.

Re: The Rust I wanted had no future

#465

Post by eru »

tinco wrote: post #120
eru wrote: post #97

Earlier quoted context omitted.

Haskell is designed by committee, and it's a fairly alright language.

It suffers from the same problem C++ does though, it's got a broken "prelude" and the committee just doesn't have the courage to ever fix it. Weirdly a long time ago the opinion was that since the language was academic they weren't hindered by the demands of stability that corporate users might so they could do epic things like the switch to monadic I/O. I feel if the Haskell committee could simply pick one of the al…

I agree with the broken "Prelude". Fortunately, you can mostly ignore the Prelude and replace it with your own fairly easily. (As you suggest.)

The bigger problem is that strings are broken: by default they are linked lists of Characters. You can use better strings (like Data.Text) and you even get to use them as literals in your source, but the language ecosystem of libraries mostly assumes that you are using the default strings. And converting back and forth is annoying.

Because of all the existing libraries, it's harder to route around [Char] by yourself.

Re: The Rust I wanted had no future

#466

Post by aldonius »

FpUser wrote: post #449
Ygg2 wrote: post #442

Earlier quoted context omitted.

Problem is, you call pop on empty vector in C++, you get nasal demons. Not a case in Rust. I'm not a C++ expert but here is my understanding. Vector is essentially a tuple of (dynamic_array_address: ptr, size: size_t, capacity: size_t). To pop a value from vector you just decrements size. So what happens when you have empty vec? Your size is 0, and you're substracing 1, which causes undefined behavior. Correct way is…

>"Correct way is to check BEFORE you pop_back()" Absolutely and this is exactly what I do. I always check the containers before removing elements. >"In Rust, any number of invocation of pop() will not result in undefined behavior. You can ignore the value, or you can check it, but it doesn't expose you to UB just for slightly misusing a vector." I do not understand "slightly misusing" part. I assume in Rust it would…

Vec::pop() and similar methods return an Option, so it's a compile-time type error to just add a number to it directly.

Re: The Rust I wanted had no future

#467

Post by davidatbu »

sheepscreek wrote: post #192

I’ll get straight to the point I want to make: Rust is suffering from an identity crisis. Much like Javascript. Realizing this, I thoroughly feel the need for a “Rust, the good parts” doctrine. A good portion of use-cases could be successfully implemented with a small subset of language. The small subset doesn’t need to be any more complicated than Go. And in doing so, we’d be reducing the entry barrier for masses an…

Can you expound upon why Rust is having an identity crisis? Rust's current mission is: "empowering everyone to build reliable and efficient software." It seems like it's hitting that goal to me (for .e.g., it empowered me, a person who's never written serious code in C/C++, to write wasm-based speech recognition reliably and efficiently).

Also, what is the identity crisis that JS is having?

Re: The Rust I wanted had no future

#468

Post by vanderZwan »

TremendousJudge wrote: post #369
vanderZwan wrote: post #305

Earlier quoted context omitted.

Am I the only one who works at a place where things don't make it into production unless at least one other person on the team fully understands the code during review?

Plenty of people don't, it's the most common thing. Maybe right now you are lucky enough to work in good contitions (that's great!), but are you sure it couldn't happen to you in 10 years? I think the standard tools we use in our profession should work in less than ideal conditions as well.

Oh I want my tools to help me, don't get me wrong. I just wonder if all the horror stories I hear are the norm, or just the stories we like to share the most.

Re: The Rust I wanted had no future

#469

Post by Too »

divan wrote: post #261
sph wrote: post #6

Very interesting insight from Graydon, in hindsight I too would have loved something more towards ML than C++. I never liked the kitchen sink approach that I see first C++, now Rust moving towards, but I respect what Rust has managed to solidify into. It's a good language. That said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring). And now that I kno…

It's crazy that the programming community even accepted the concept of async/await as a sane one. Being sync or async is essentially a property of the attention of the caller, not of the action itself. Is "eating a donut" a sync or async action? If I'm focusing all my attention on it, essentially putting all tasks aside (after) - then it's a synchronous action. If I'm reading a book/watching a video/walking/etc, whil…

You can see the async keyword on a function definition as a hint to the caller, that the action will be IO bound rather than CPU bound.

Caller can use this information to invoke 10000 IO bound tasks in parallel, whereas cpu bound tasks are limited to number of cores and may want to be throttled. In your analogy, I can eat a donut while simultaneously listening to music, but I can not eat a donut while simultaneously eating fish soup.

Now where it get complicated is when a function does both io wait and heavy cpu processing. Now neither color of the function match.

Forcing this upon the caller to invoke such functions in special ways is the strange part. Taken to the absurd you ought to have special syntax for every resource constraint in the computer, memory bound, disk bound, wifi bound, and so on. It would be better if the runtime could figure this out by itself and parallelize accordingly.

The single threaded aspect of async functions does have certain other benefits, like not having to care as much about muxes when synchronizing state.

Re: The Rust I wanted had no future

#470

Post by pjmlp »

tialaramex wrote: post #428
pjmlp wrote: post #227

Earlier quoted context omitted.

Talking about C? https://godbolt.org/z/vYcMhE9h7

You turned on a feature which helps diagnose this type of mistake at runtime, and it helped you by diagnosing the mistake at runtime. What does that prove? What I'm talking about is that Rust's Option is very cheap in all the cases where it can be very cheap, which makes this whole design feature more affordable. C++ eventually grew std::optional which is not powerful enough for this work and yet is also bigger and s…

It proves that there is a way to diagnose this type of mistake, that is what matters.

Unlike C, which the only way to be safe is not to touch it at all.

As for performance, ISO doesn't implement compilers, there are many ways to improve performance while keeping the semantics in line with the standard.

If the compiler vendors decide to focus elsewhere is another matter, a bit like there are languages as complex as Rust and compile faster, because that has been a concern, whereas rustc developers have their concerns elsewhere.

Post reply on HN