291–300 of 341 posts
Earlier quoted context omitted.
Err, you can't use `?` with `Option` unless I've really missed a big feature somewhere. You'd have to map it to a `Result` then unwrap, but at that point you still need to define an error type.
You have missed a big feature! They added support for that like a year ago or something.
Earlier quoted context omitted.
Err, you can't use `?` with `Option` unless I've really missed a big feature somewhere. You'd have to map it to a `Result` then unwrap, but at that point you still need to define an error type.
https://doc.rust-lang.org/std/option/enum.Option.html#impl-T... I guess you've "really missed" this feature or more likely you are considering only the case where our function signature says we return Result and so early returning Option won't compile. Because the modern "try v2" operator is a trait, it is implemented for Option, Result, and ControlFlow plus Poll variations. Historically its ancestor the try! macro w…
Earlier quoted context omitted.
https://doc.rust-lang.org/std/option/enum.Option.html#impl-T... I guess you've "really missed" this feature or more likely you are considering only the case where our function signature says we return Result and so early returning Option won't compile. Because the modern "try v2" operator is a trait, it is implemented for Option, Result, and ControlFlow plus Poll variations. Historically its ancestor the try! macro w…
I guess? If it's still languishing in nightly I'm not sure I consider it usable; I'm aware some people are fine to run nightly but I keep to stable releases.
Let me give you another example you've probably used without realising it, when you write password.contains("foo") in Rust. Why can you write "foo" there? Rust doesn't have overloading, and yet you can pass strings, characters, and functions including lambdas - how can this work? They all implement core::str::pattern::Pattern, an unstable trait used to deliver this functionality for all string matching.
In fact mechanically what's happening here for Try is that ? always worked for Option and Result, the "try v2" feature isn't about the syntax at all, it's about the behind the scenes implementation of that syntax. But that's not important, the syntax is promised and the final implementation will almost certainly be tryv2 or something very similar.
Earlier quoted context omitted.
> Mutable shared state: make bad designs hard to write. Also makes good designs hard to write, designs that can be significantly more efficient. Passing messages is not a universal solution to shared mutable state. It is great for certain patterns but suboptimal for others.
Wrong, it makes good designs easy to write with clear safe APIs. If you know what you are doing just create a safe wrapper over unsafe functions and do what you need. For example you can just write a lockless triple buffer for efficient memory sharing and wrap the unsafe usage of pointers with a safe API. now you only need to pay attention to those specific unsafe calls.
It encourages good designs but it does not make them easy to write, but that's somewhat the point. Its not trivial to design a safe API that pushes performance limits.
> just write a lockless triple buffer for efficient memory sharing and wrap the unsafe usage of pointers with a safe API
This isn't practical or pragmatic.
And I say this as someone who likes rust and develops in it every day.
Earlier quoted context omitted.
I guess? If it's still languishing in nightly I'm not sure I consider it usable; I'm aware some people are fine to run nightly but I keep to stable releases.
So, all of Try is unstable. This means your stable Rust isn't allowed to implement Try for your own custom types, however the syntax is stable, so since Try is implemented for all of Option, Result and ControlFlow, those all work with the ? syntax even though that implementation is marked unstable. Let me give you another example you've probably used without realising it, when you write password.contains("foo") in Ru…
Earlier quoted context omitted.
What are those issues, if you don't mind me asking? Don't see much OCaml discussion here so I'll take interesting discussions where I can get them.
My biggest gripes: * Windows support is mediocre due to decades of not supporting it at all. * OPAM is a nightmare. Surprisingly buggy and extremely confusing. We're not talking Pip levels of badness but it's nowhere near as good as Rust, Zig or Go's equivalents. * A silly obsession with linked lists. Ok I understand why but it's still annoying. * Ocamlfmt thinks it is writing an essay, and generally makes things les…
Earlier quoted context omitted.
You have missed a big feature! They added support for that like a year ago or something.
I guess? If it's still languishing in nightly I'm not sure I consider it usable; I'm aware some people are fine to run nightly but I keep to stable releases.
Earlier quoted context omitted.
Nope. I would encourage you to actually read what unsafe does, because nowhere in the Rust docs does it say "scopes bugs to the unsafe block" See the below code. The unsafe code is doing exactly what it's supposed to. The safe code frees a value while it's being used. This compiles. There's nothing to change here in the unsafe code. ```rust use std::slice; // Unsafe block that creates a slice from raw parts fn make_s…
The unsafe code is not fulfilling the contract of "unsafe", which requires the coder to uphold the memory safety rules as seen from outside. make_slice is putting a very wrong lifetime on the slice it returns.
> The unsafe code is not fulfilling the contract of "unsafe", which requires the coder to uphold the memory safety rules as seen from outside
It's the exact opposite. From the Rust docs. [1]
> By calling an unsafe function within an unsafe block, we’re saying that we’ve read this function’s documentation and we take responsibility for upholding the function’s contracts
The caller here is what is violating the contract. It's not the unsafe code's job to do that. How could it? It's just making a slice, it doesn't know what from. It can't guarantee a slice it makes is ANY kind of lifetime. If it could, it wouldn't require unsafe.
We don't have to use a static lifetime to have this bug:
// still broken
// basically says it has SOME kind of lifetime
fn make_slice(ptr: *const i32, len: usize) -> &'a [i32] {
Yes, if you change the function signature and require it to receive the vec so you can see the lifetime, you could technically fix it from this function. That's the only way to get the right lifetime.
fn make_slice(ptr: *const i32, len: usize, _lifetime: &'a Vec) -> &'a [i32] {
But you can't do this in scenarios where you'd actually want unsafe, like FFI, custom data structures, etc. You don't have the same lifetime information available to you.
[1] https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html#call...
Earlier quoted context omitted.
Having run into memory issues in go but not (yet) in rust I would tend to disagree with this. It's really not hard or esoteric to run into it in go.
"running into memory issues" doesn't relate to memory safety as a property
> We actually had a recent Cloudflare outage caused by a crash on unwrap() function Oh boy, this is going to be the new thing for Rust haters isn't it? Yes, unwrapping an `Err` value causes a panic and that isn't surprising. Cloudflare had specific limits to prevent unbounded memory consumption, then a bad query returned a much larger dataset than expected which couldn't be allocated. There are two conclusions: 1) If…
>There are two conclusions: 1) If Cloudflare hadn't decided on a proper failure mode for this (i.e. a hardcoded fallback config), the end result would've been the same: a bunch of 500s, and 2) most programs wouldn't have behaved much differently in the case of a failed allocation. So why do they need Rust then? What advantages does it provide? That was the main point of the article — we all wanted a better language,…
The move to Rust was partly motivated because it prevented that entire class of errors. No more out-of-bound reads, or data races. The compiler audits these missed spots.
Now, you could say a managed memory language would suffice as well. Perhaps it could. But we needed performance, and no memory-managed language met those performance needs then or today.
I get you're making the case that Rust isn't perfect for all use cases, but Cloudflare's scenario is the exact corner case your argument falls apart in: we needed fast and safe in an environment where not being fast or safe had real business consequences, and nothing else except Rust gave both.