Earlier quoted context omitted.
> - bad error messages (even though that was a focus for the rust team!) I would love to hear more! (If you have the time.)
Not the fault of Rust compiler per se but in my case the errors that mismatching trait impls from async libraries yield can be downright suicide-inducing. I recognize this is not entirely on rustc though.
I love building a startup in Rust but wouldn't pick it again
221–230 of 496 posts
Re: I love building a startup in Rust but wouldn't pick it again
#222Earlier quoted context omitted.
I prefer having extra work done writing code (adding "?") than having to do extra work reading code. Exceptions are functionally invisible control flow; it isn't clear to the reader that a function may blow up if the exceptions are unhandled.
Assume all functions can throw and there is no extra work reading. A function that has no possibility of error is so uninteresting in the context of error handling. Furthermore, handling errors has little to do with where the error is actually caused. In general, you can only do two things with errors: log and kill the operation or retry the operation. Neither of these has anything to do with the leaf function 20 ite…
Re: I love building a startup in Rust but wouldn't pick it again
#223I've been writing Rust professionally for a few years now and if there's one thing I've learned it's that if you ever write a function that takes a parameter of `impl Fn(&Vec ) -> &'a str` you are going to be in for some pain. Just make it `impl Fn(&Vec ) -> String`. It is highly unlikely that the extra allocation is ever going to be noticed in the performance. Just because Rust pretty much forces you to be explicit…
Re: I love building a startup in Rust but wouldn't pick it again
#224I find it surprising that so many people are arguing about the benefits and drawbacks of `?`, when in my experience the handling of Result and Option haven't been an issue in practice on the consuming side (`?`, `.unwrap()`, `.map()`, `.ok()`, if let, match, let chains, let else, etc. help a lot), but where all the pain comes from is having to declare the appropriate error type itself. Libraries like `anyhow` takes s…
All these workarounds for easier Result handling truly make me wonder whether Rust will eventually evolve exceptions as a feature - of-course without explicitly terming them so.
Proposals to make the existing syntax and semantics even look more like exceptions were met with lots of hostility.
Re: I love building a startup in Rust but wouldn't pick it again
#225> Perf is easy when you have AWS credits. One reason that you might pick Rust is for overall performance. Interesting: Rust save money but that mean effort!
Unfortunately, the cloud isn't a very good environment for mixed-languages deployments (unless you stick to the most basic services), so you have to make a decision on the very beginning and stay with it.
Re: I love building a startup in Rust but wouldn't pick it again
#226Question for HN, all things being equal (you are not more familiar with one language/framework) what language would you choose to build a startup in?
Re: I love building a startup in Rust but wouldn't pick it again
#227I've been writing Rust professionally for a few years now and if there's one thing I've learned it's that if you ever write a function that takes a parameter of `impl Fn(&Vec ) -> &'a str` you are going to be in for some pain. Just make it `impl Fn(&Vec ) -> String`. It is highly unlikely that the extra allocation is ever going to be noticed in the performance. Just because Rust pretty much forces you to be explicit…
[flagged]
Re: I love building a startup in Rust but wouldn't pick it again
#228Earlier quoted context omitted.
> - bad error messages (even though that was a focus for the rust team!) I would love to hear more! (If you have the time.)
Not the fault of Rust compiler per se but in my case the errors that mismatching trait impls from async libraries yield can be downright suicide-inducing. I recognize this is not entirely on rustc though.
pub async fn foo() -> i32 {
unimplemented();
}
pub async fn bar() {
let f = await foo();
}
gives error: incorrect use of `await`
--> src/lib.rs:6:13
|
6 | let f = await foo();
| ^^^^^^^^^ help: `await` is a postfix operation: `foo().await`
It isn't on rustc to understand this either, but it helps a bunch of people, so the team does it anyway.Re: I love building a startup in Rust but wouldn't pick it again
#229Earlier quoted context omitted.
The problem with exceptions isn't the syntax, but the hidden control flow (they are essentially a goto in disguise). Error union return values make a lot more sense, the rest is just syntax sugar details (and that's where opinions differ I guess).
Exceptions are not a form of gotos, they are both less powerful as they are structured and more powerful (as they are nonlocal). They desugar to continuations, but so does rust option type handling and ?. In fact they are pretty much equivalent. I'm not terribly familiar with either language, but I don't see any particular difference between swift and rust error handling for example, swift will also mark fallible fun…
Re: I love building a startup in Rust but wouldn't pick it again
#230Earlier quoted context omitted.
> - Verbose. I've seen a just few lines of JS get replaced with hundreds and thousands of Rust. Please, more detail (=
I should've been clearer, sorry. The verbosity and complexity of `wasm_bindgen`/serialization between JS and Wasm (written in Rust) is primarily the thing I am frustrated at here when I see hundreds and thousands of Rust code. A concrete example: creating a Websocket client in Javascript/Typescript vs in Rust/Wasm. In general though (outside of Wasm), Rust is less readable. And with regards to Rust errors, I've found…
eg Browsers provide JS functions that are intended for JS, which are not directly exposed to Wasm. So when your Wasm wants to access DOM things, access DOM functions, (etc) it needs to go through a JS shim layer instead of being able to call them directly.
If the browser dev's (or some W3C type of body?) introduced those same functions, but had them be directly accessible from wasm, then the JS shims wouldn't be needed.
The JS dev's for each of the browsers though would probably try and stop it ("security risk!" excuses, etc) though, as that would potentially cut into "their territory" and allow other languages to compete. :(