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

471–480 of 523 posts

Re: The Rust I wanted had no future

#471

Post by pjmlp »

Ygg2 wrote: post #435
pjmlp wrote: post #411

Earlier quoted context omitted.

Yes defaults matter, it doesn't change the fact that protective gear is available, and like seatbelts, helmets and motorrad full body armour, it is up for security conscious people to make do of what is made available to them. As for your dynamic arguments request, have fun, https://godbolt.org/z/YYKrnh4Y9

It's not just that defaults matter, the problem here is why have footgun as the default? In a runtime example I can run it with tests and it would behave fine if both values are same or first arg is bigger, in Rust's case it would behave valid for ANY combination of arguments.

Likewise with C++ if the safety belt is buckled.

Re: The Rust I wanted had no future

#472

Post by Patrickmi »

ZephyrBlu wrote: post #83
truculent wrote: post #74

Earlier quoted context omitted.

I'm not sure it would be less accessible. I think the trade-offs would lean towards simplicity, and perhaps less familiarity. But with the right mental models, I think this could enhance accessibility (less "magic", or strange edge-cases). For example, see the discussion on not minding if users have to write something in a more verbose way if it preserves the language's principles. This type of trade-off is something…

I'm using accessible in a very general sense. The sense of "how niche would this be". My impression is that Rust would have been a very niche language if Graydon was the BDFL.

That’s not a viable excuse to make

Re: The Rust I wanted had no future

#473

Post by kaba0 »

Too wrote: post #469
divan wrote: post #261

Earlier quoted context omitted.

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…

There are so many nuances to function execution’s resource usages that I don’t see a point in putting boxes on that. The important part and the more intuitive human model for execution is from the POV of a single, calling thread. Whether it semantically makes sense to wait for the result of this call, or it doesn’t. If you need the result there is no going around that, you have to wait on that — it’s this function’s caller that has to decide what to do now.

Other possible semantics would be to start multiple tasks and wait for them all — this is where structured concurrency comes in, giving a good analogue with gotos.

Async-await is fundamentally an optimization, not about semantics only. Languages without runtimes simply can’t reason about it without language support, but managed ones could do so as every IO call goes through it — scheduling multiple tasks to a single core is now possible.

Re: The Rust I wanted had no future

#474

Post by gautamcgoel »

noelwelsh wrote: post #207
dorian-graph wrote: post #103

Earlier quoted context omitted.

I was about to ask if there's any "Rust by ML" languages out there. Thank you.

O'Caml is heading in that direction. Jane Street are adding more control over memory layout and allocation, and multicore finally arrived recently.

Lol there's no apostrophe in OCaml - it's not an Irish name like, say, O'Brian.

Re: The Rust I wanted had no future

#475

Post by 59nadir »

netbioserror wrote: post #278
anonyfox wrote: post #143

I love Rust and built some production code with it in the past. But nowadays I want something more simple so that not-so-senior developers can pick it up quickly, and I want flawless tooling, and willing to sacrifice a bit of performance. So basically I often end up with Go. Go is exceptionally great in tooling, ecosystem, any objective metrics like build times or crosscompilation... but I still don't like the langua…

Nim gets real close. It doesn't have great UI tooling, but its command line tools are quite good.

Nim punts too many things to random GitHub libraries. Tagged unions with exhaustiveness checks for something like pattern matching on them is the responsibility of some random person in the Nim community, for example, which is a step too far, IMO.

I think what it comes down to is that the creator/BDFL of Nim has an eclectic set of things that he simply doesn't care about and will never add to the language even though they are basically table stakes nowadays.

Re: The Rust I wanted had no future

#476

Post by kaba0 »

bourneavent wrote: post #378
divan wrote: post #261

Earlier quoted context omitted.

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…

>How does "func EatADonut() async {}" aka "eating a donut is an inherently async action" even make sense to people? You have to think of it from a higher level. Nobody knows if eatdonut is strictly async but everyone knows all IO calls are async. So something like socket.send would be async, this is obvious. Then anything that calls socket.send would then in turn become async itself. The async sort of spreads around…

> but everyone knows all IO calls are async

Do you mean on a hardware level? Because otherwise, hell no.

If I’m writing a binary file parser that buffers some data and processes it, I sure as hell want to wait for IO, there is no other meaningful way forward in most cases. It is also not a small isolated part, but a tight loop bouncing between CPU and IO.

Async is a function of the caller.

Re: The Rust I wanted had no future

#477

Post by noelwelsh »

gautamcgoel wrote: post #474
noelwelsh wrote: post #207

Earlier quoted context omitted.

O'Caml is heading in that direction. Jane Street are adding more control over memory layout and allocation, and multicore finally arrived recently.

Lol there's no apostrophe in OCaml - it's not an Irish name like, say, O'Brian.

You're rude and you're ignorant of OCaml's history. There is no apostrophe in OCaml now, but there used to be. E.g. https://web.archive.org/web/20050207032955/http://www.ocaml....

OCaml is / was short for Objective Caml. Hence the name used to have an apostrophe. At some point that was dropped.

Re: The Rust I wanted had no future

#478

Post by kaba0 »

unscaled wrote: post #373
fzeindl wrote: post #205

Earlier quoted context omitted.

I hate async as well. Developers should have learned about communicating sequential processes and blocking queues and none of that would have been necessary. It creates a weird divide in every language. Just learn about threading and do it. A nice talk about this: https://www.reddit.com/r/programming/comments/da141r/ron_pre...

I'm pretty sure the designers of Rust knows about CSP. Rust has Channels in the standard library after all: https://doc.rust-lang.org/rust-by-example/std_misc/channels.... Rust Channel have the nice additional that they don't panic, and don't have all the weird Go Channel Axioms[1] that you have to wrap your head around to get things to work correctly[2]. For what it's worth, I don't think Java Virtual Threads (a.k.a…

> it can at least promise me that I won't get any data races.

But not any other kind of race condition.

Also, data races are “safe” in java. Plus you can rely on immutable data for those parts. Parallelism will always be hard, there is no model for shared mutability that would be easy.

Re: The Rust I wanted had no future

#479

Post by menaerus »

jarjoura wrote: post #364
moth-fuzz wrote: post #239

Earlier quoted context omitted.

You can't evaluate a future in normal rust as there's no default executor, you need to pull in some library to even make blocking calls to async functions. IMO, this is even worse than function coloring.

It's the same in C++. The compiler and language design came first and then the library (aka executor) part comes next. Rust has basically 2 executor libraries, tokio and async-std. It seems to me like tokio is solidifying as the executor of choice and it's only a matter of time before that design is baked into the std library.

In C++ there is a default executor that is part of the standard library and has been so since C++11, e.g. no external library is needed - std::async.

std::async is mostly "good enough" for ordinary cases where you only want to fire-and-forget and have no control over the underlying dispatching and scheduling algorithms. If you want something tweaked towards your use-case, and hence actual high-performance executor library, std::async is not gonna cut it. And that's where the "C++ executors" proposal come in.

Re: The Rust I wanted had no future

#480

Post by bourneavent »

kaba0 wrote: post #476
bourneavent wrote: post #378

Earlier quoted context omitted.

>How does "func EatADonut() async {}" aka "eating a donut is an inherently async action" even make sense to people? You have to think of it from a higher level. Nobody knows if eatdonut is strictly async but everyone knows all IO calls are async. So something like socket.send would be async, this is obvious. Then anything that calls socket.send would then in turn become async itself. The async sort of spreads around…

> but everyone knows all IO calls are async Do you mean on a hardware level? Because otherwise, hell no. If I’m writing a binary file parser that buffers some data and processes it, I sure as hell want to wait for IO, there is no other meaningful way forward in most cases. It is also not a small isolated part, but a tight loop bouncing between CPU and IO. Async is a function of the caller.

>Do you mean on a hardware level? Because otherwise, hell no.

I mean in the context of async await. The smallest primitive that is properly async is an IO function.

Post reply on HN