Live data from Hacker News

I love building a startup in Rust but wouldn't pick it again

propelauth.com

221–230 of 496 posts

Re: I love building a startup in Rust but wouldn't pick it again

#221

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.

Having examples of these is useful to see what we could get rustc to do. The general case might be impossible to deal with in a generic way, but we can target specific patterns libraries use and emit custom errors for them. The problem with these is we have to be reactive: if we don't see a problematic patter ourselves (or it isn't reported to us), we can't do anything about them.

Re: I love building a startup in Rust but wouldn't pick it again

#222

Earlier 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…

We have to be deliberate about where we retry, and how quickly. It’s all too easy for layers to create a death ray of n factorial requests.

Re: I love building a startup in Rust but wouldn't pick it again

#223
post #32

I'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

#224

I 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.

The community would revolt. Not going to happen.

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
post #84

> 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!

Even on the cloud, Rust will only save you money if you have enough users. But the effort is upfront.

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

#226

Question 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?

That's not a good question. There is no reason to pick one language over another if you don't even know what software you will write.

Re: I love building a startup in Rust but wouldn't pick it again

#227
post #32

I'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]

thanks for running this through chatgpt for me

Re: I love building a startup in Rust but wouldn't pick it again

#228

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.

esteban of course gave you an excellent response already, but just another bit of like, context here: while it may not be on rustc, the developers want to go beyond the norm here. rustc understands if you write async/await syntax like JavaScript, and then directly proposes that you switch to the Rust syntax:

    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

#229

Earlier 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…

If you consider the case where you call a function that throws an exception without you expecting it -- then the control flow will skip your code, and this is indeed not very structured, like a goto, and in fact less local than a goto.

Re: I love building a startup in Rust but wouldn't pick it again

#230
post #162

Earlier 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…

Isn't this due to wasm having to access browser things mostly through browser JS interfaces?

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. :(

Post reply on HN