Or you can write rust with nostd, and no allocator (bring your own). But what would you do anyway if you `vec.push(x)` and somehow there isn't enough ram? How would you signal the error in a way that makes sense to the caller of `push`?
-
-
The push method could return `Ok(())` when it succeeds and `Err(x)` when it fails. Since `Result<T, U>` is marked #[must_use], it forces the caller to handle the error case. Rust as a language is well-suited to writing low-level, robust code. The non-core stdlib is the issue.
3 replies 1 retweet 3 likes -
That would make 99% of application-level code return `Result`, which is crazy for a general purpose language. If you want to write low level code, you'd allocate manually at the beginning and you wouldn't use resizable vectors/hashtables anyway, right?
1 reply 0 retweets 0 likes -
> If you want to write low level code, you'd allocate manually at the beginning and you wouldn't use resizable vectors/hashtables anyway, right? No, not at all. Dynamic allocation for dynamic requests is fine if you have a way to make only that specific request fail.
2 replies 0 retweets 1 like -
fair enough, but then it's reasonable to use custom structures, I suppose. (also, on linux, this whole discussion is funny because OOM for a process doesn't exist in practice, the OS kills you instead ^^)
1 reply 0 retweets 0 likes -
vm.overcommit_memory = 0 exists on Linux, and who said we're just talking about using Rust on Linux?
1 reply 0 retweets 0 likes -
No one, I'm just saying.
1 reply 0 retweets 0 likes -
Every third party library needs to disable the Rust standard library if they want to be robust and portable. Most don't do that, so they aren't usable where these things matter. Rust's standard libraries don't have any form of allocation, collections or IO not depending on this.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @das_kube and
Rust as a language is great for writing software like a kernel or a robust / portable library. However, you don't have 95% of the standard libraries and third party library ecosystem in those niches. That's a pretty serious problem for a language targeted at low-level usage.
2 replies 0 retweets 1 like -
Replying to @CopperheadOS @das_kube and
Since portable third party libraries can't use the standard library, that means the third party library ecosystem often needs to reinvent simple things that should be standard because they can't reuse that code. It's a mess.
3 replies 0 retweets 2 likes
That's roughly how the Mozilla folks treated C anyway (see: NSPR) so it's not surprising...
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.