111–120 of 305 posts
I don't really do JS, where a lot of this seems to be happening, but the code I have seen with the huge ladders of callbacks doesn't seem so great to work with to me.
Also, although using promises seems better, it seems like it could quickly become spaghetti.
Maybe I'm stupid. But why is Rust so much harder than any other newish programs language. Dart is like all of my dreams come true at once, Rust still gives me nightmares. I seriously tried to learn it multiple times and failed repeatedly. I've created several Dart/ Flutter projects for myself and friends. Multiple C#/Unity projects. Python and JavaScript have paid my rent for the better part of a decade. But Rust, I…
Dart's type system is not sound.
Earlier quoted context omitted.
Frontend or backend js? Because in the frontend everything is just scheduled to a single thread, so you only deal with concurrency, not parallelism.
In node.js backends, you also deal with a single thread only; if you want multiple CPUs, you'd need node-cluster, giving you, conceptually speaking, multiple shared-nothing single-thread environments to load-balance requests into. Technically, libuv (the C lib exposing async I/O to node) uses threads but that is hidden away from you. Multithreading in JS can't work anyway since JS doesn't have synchronization primiti…
Earlier quoted context omitted.
I don't agree that people should avoid exceptions for expected errors. The idea that they should has twisted the error handling landscape into a pretzel and is responsible for some ugly bits of Rust design.
Exceptions are a mechanism for error handling that comes with control flow changes. But Rust already has perfectly nice control flow mechanisms (look at std::ops::ControlFlow for example) and perfectly nice error handling. So you can use either, or both, as necessary, you don't need this particular Frankenstein's Monster. Using Exceptions for things that aren't actually exceptional is perverse.
In python using exceptions for some control flow is actually accepted practice if you don't go overboard.
I think it's better that way because it turns them into something familiar instead of pushing them back to some extraordinary circumstances.
The thing that C++ does with exception means that programmers mind is encouraged to stay on happy path because when he'll walk off this path he'll have to deal with this exception handling monster.
So it's better to either not have exceptions and expose unhappy paths to programmer clearly like Rust or Go does, or familiarize exceptions and their handling so programmers can use them easily in all circumstances like in Python.
Just don't do what C++ and similar do. Offer them as a heavy and weird side mechanism reserved only for super exceptional cases.
Guess I'll just go back to erlang.....
There is also a actor pattern implementation for Rust: https://actix.rs/ But yeah, the way Erlang embededded the actor pattern in the VM (Beam) and the language itself is great. Tough personally I would have liked it if it was more statically typed. I still need to take a look at Gleam...
Honestly, people want to write high level code in low level languages too often. Both Rust and C++ ought to be relegated to high performance cores of larger, "squishier" programs written in higher level languages. The Emacs model is perfect for most programs running on conventional systems. The key insight here is that garbage collection gives you access to a variety of patterns that are otherwise fiendishly difficul…
1) the expressive type system, notably the use of optional type instead of null and the use of lifetimes to make reasoning about references tractable, and 2) the community, with a focus on correctness, documentation, and being welcoming.
It was heavily discussed previously. In particular, it triggered this response from Rust contributor withoutboats: https://news.ycombinator.com/item?id=26410487 And this blog post from someone who did spend a lot of time working with async rust: https://tomaka.medium.com/a-look-back-at-asynchronous-rust-d...
To be fair withoutboats didn't really address any of the points that people make about the flaws of async Rust (e.g. the cancellation problem). It may be the case that there's no good way to solve them, but that doesn't mean that they aren't problems and it doesn't really help to say that people who highlight them are totally wrong and don't know what they're talking about. That said I think your second link does a m…
Apart from requiring a safe zero-copy io-uring abstraction to use a buffer pool instead of "bare" references, Rust's polling+cancellation model is fantastic. It's incredibly convenient to be able to externally time out and abort any Future, without needing to pass contexts/tokens and/or needing every I/O operation to have an explicit timeout option.
It's annoying when conscious small trade-offs are framed as fatal flaws (like the title of TFA). In the case of the cancellation model the "doesn't work" is that a safe abstraction is not entirely zero-cost. But when you use async in JS, C#, or Golang, you already have unavoidable heap allocations and memcpys (and another set of difficulties with cancellation). Rust's worst-case flaw is comparable to a normal mode of operation in a few other async languages. The scale of the issue is overblown, and its benefits are overlooked.
I don't have any experience with async Rust (but I stuggled a lot with Rust's closures when I dabbled with Rust a while back so I can at least feel the pain the article tries to convey), but one important reason to not build async-await on top of fibers or threads but instead on code transformation (aka 'compiler magic') is 'weird architectures' like WASM, which doesn't have easy access to threading (locked behind CO…
Well, space _blocking runs blocking code in an async context. It takes a closure as it's argument and if you're in a mixed async/sync platform you will his this function a lot. To deal with it you end up needing to use move. And to use move you need to clone your pointers to the data and manage all that guff.
The alternatives are Arc, deep copies, or use C++ where you will invariably get it wrong and end up with corrupted data and a very bad week (or you don't notice and reply to this comment saying that you do this in C++ and never had a problem)
Can someone explain to me the attraction of async programming? I don't really do JS, where a lot of this seems to be happening, but the code I have seen with the huge ladders of callbacks doesn't seem so great to work with to me. Also, although using promises seems better, it seems like it could quickly become spaghetti.
Having never worked with threads heavily, they always seemed like WAY more hassle to me. I assume that‘s the alternative? I think go has something else?
Maybe I'm stupid. But why is Rust so much harder than any other newish programs language. Dart is like all of my dreams come true at once, Rust still gives me nightmares. I seriously tried to learn it multiple times and failed repeatedly. I've created several Dart/ Flutter projects for myself and friends. Multiple C#/Unity projects. Python and JavaScript have paid my rent for the better part of a decade. But Rust, I…