Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Rust Web Yet?

arewewebyet.org

Post reply on HN
Print view View original

121–130 of 183 posts

Re: Is Rust Web Yet?

#121

Post by kccqzy »

ob wrote: post #115
muglug wrote: post #112

Earlier quoted context omitted.

Rust has smart type checking. The really smart stuff is (IMO) the beauty of the borrow checker. In PHP, modern typecheckers can verify that the first element always exists on an array after an emptiness check: if ($some_arr) { echo reset($arr); } Whereas in Rust you have to explicitly unwrap: if !some_vec.empty() { print!("{}", some_vec.first().unwrap()); // .. more code } The Rust version requires you to use your in…

Rust noob here but couldn't you write if let Some(element) = some_vec.first() { println!("{}", element); // .. more code } and avoid the unwrap and the empty check? Edit: Added a `let` I had forgotten.

Exactly (well other than "if let" here.)

Every time you have a Boolean if condition with an unwrap, it means you are not taking advantage of the type system.

Re: Is Rust Web Yet?

#122

Post by ob »

kccqzy wrote: post #121
ob wrote: post #115

Earlier quoted context omitted.

Rust noob here but couldn't you write if let Some(element) = some_vec.first() { println!("{}", element); // .. more code } and avoid the unwrap and the empty check? Edit: Added a `let` I had forgotten.

Exactly (well other than "if let" here.) Every time you have a Boolean if condition with an unwrap, it means you are not taking advantage of the type system.

Thanks, added.

Re: Is Rust Web Yet?

#123

Post by verdagon »

csomar wrote: post #118
muglug wrote: post #112

Earlier quoted context omitted.

Rust has smart type checking. The really smart stuff is (IMO) the beauty of the borrow checker. In PHP, modern typecheckers can verify that the first element always exists on an array after an emptiness check: if ($some_arr) { echo reset($arr); } Whereas in Rust you have to explicitly unwrap: if !some_vec.empty() { print!("{}", some_vec.first().unwrap()); // .. more code } The Rust version requires you to use your in…

> The Rust version requires you to use your intuition to figure out that `unwrap()` will never panic here. You should not use `unwrap` in a production product. It's there for prototyping and I think it's a mistake they have it (though the language already requires a good upfront time investment as it is). Use `?` and have your error propagate accordingly to the top of the chain. Have your own error types and convert…

We tried this style in one of Google Earth's packages for a while (using an internal C++ class similar to Rust's Result). So many operations could theoretically fail (e.g. indexing out of bounds or an expected key not existing) that pretty much every single function in that package returned a Result. These "unexpected" errors would just fly up the stack, manually unwinding it, because nobody could really do anything with them. Once we had that, I really questioned some of our policies.

I can imagine a language where panics don't crash the entire application, but instead blast away the surrounding "region" of memory, leaving the rest of the program intact and able to keep running. Similar to catch_unwind, but if the language is aware of region boundaries, and only allows certain methods of communication between them, it would leave the rest of the memory in much more predictable possible states.

It may sound surprising, but it's actually possible with the right language constructs (Erlang folks know what I'm talking about!) and that way, we could once again have panics for unexpected errors, and Results for expected errors.

Re: Is Rust Web Yet?

#124

Post by neandrake »

muglug wrote: post #71

I've spent the last few months porting the guts of a 100 KLOC PHP command-line utility I wrote to Rust. Thanks to the wonderful Rust documentation it's been a mostly painless endeavour. What I've gained as a result: - execution speed (about 3x faster, single-threaded) - better-documented data structures Things I've lost: - ease of iteration - concise, readable code - really smart type inference - a bunch of time thin…

I imagine that especially for a command line utility you also gained an easier deployment story when using rust, given the static linking and lack of interpreter. Requiring PHP to be installed to use a tool has caused me issues, especially with some of the recent PHP 8 updates introducing breaking changes. It’s a better story for PHP on a server where it’s more centrally managed.

Re: Is Rust Web Yet?

#125

Post by muglug »

ob wrote: post #115
muglug wrote: post #112

Earlier quoted context omitted.

Rust has smart type checking. The really smart stuff is (IMO) the beauty of the borrow checker. In PHP, modern typecheckers can verify that the first element always exists on an array after an emptiness check: if ($some_arr) { echo reset($arr); } Whereas in Rust you have to explicitly unwrap: if !some_vec.empty() { print!("{}", some_vec.first().unwrap()); // .. more code } The Rust version requires you to use your in…

Rust noob here but couldn't you write if let Some(element) = some_vec.first() { println!("{}", element); // .. more code } and avoid the unwrap and the empty check? Edit: Added a `let` I had forgotten.

Yes, but IMO that makes the code a bit more abstract:

You've left behind an explicit "is this collection non-empty" and you're instead relying on a property of a non-empty collection.

The PHP version can also be written as

    if (($element = reset($some_arr)) !== null) {
        echo $element;
    }
But that code is similarly divorced from the imaginary pseudocode equivalent

Re: Is Rust Web Yet?

#126

Post by staticassertion »

melissalobos wrote: post #96
staticassertion wrote: post #91

Earlier quoted context omitted.

Nope, it's written correctly as-is. Probably the "time to tests pass" is about equal, but the iteration and maintenance is far better in Rust.

> but the iteration... is far better in Rust That is something I would find hard to believe, if you mean iteration of changes. I have coordinated a few rust rewrites, and at least seeing engineers live programming, it takes far far longer to change and compile Rust code than python. Could you talk more about your company's process or how you mean?

The time it takes to run `cargo check` is nothing compared to dealing with bugs, terrible tooling, weak errors, etc. All of those areas have been radically better with Rust.

As an example, type errors in Rust are radically better than mypy, it's no competition. In general rust's type system is just way better, we have to use Any all over the place because mypy can't even handle a Json type (no recursive types at all).

There's nothing that Python really does better in terms of iteration that I can think of. Obviously you don't have to compile code, but `cargo check` is seconds, that is not the bottleneck. We use hypothesis in Python and quickcheck in Rust, cargo is way better than pip, working with loosely typed data is about the same in Rust, maybe a bit better, and working with strictly typed data is wayyyy better.

The tooling for working with crates, having an actual lockfile, higher quality libraries, etc. It just all makes Rust more productive.

We've run into maybe one rust footgun, which is that binding to _ drops the value immediately. We've run into so many Python footguns, like, did you know that in Python if you want to do circular imports you need to put your imports at the bottom of the file? Or use absolute imports everywhere? Neither of which seem to work 100% of the time by the way, something that makes writing graph data structures quite cumbersome. The other day we ran into a stray comma turning a value into a tuple. The papercuts and footguns across the tooling and language just add up really fast and basically don't exist in Rust.

I don't know how people get stuck on the borrow checker, frankly. It's one thing if you're very new to the language, but within weeks it should be very simple to avoid those errors. I maybe hit a "fuck, what" borrow checker issue once a year, in which case I hit up the Discord, they fix it, and I file an issue with rustc so that the error message will get improved.

This is based on about 7 years of Rust and Python experience, with 6 years of professional experience in Python and 3 in Rust.

Re: Is Rust Web Yet?

#127

Post by staticassertion »

muglug wrote: post #94
staticassertion wrote: post #88

Earlier quoted context omitted.

How so? We use many of the crates listed on the linked page - sqlx, rusoto, actix-web, tower/tonic, etc.

Yeah, but the thing you're building is quite a bit more complex than the average consumer-focussed website.

I guess, but if you're just building some basic CRUD app that's never going to change, why would iteration speed matter anyway?

Re: Is Rust Web Yet?

#128

Post by Sytten »

This website really needs an update. Many people mentionned Axum. On the DB side you should check out sea-query and sea-orm.

Many negative rust comments over here. It sure did take me a few months to get comfortable with the language and its idioms, but man do I not want to go back to languages without a borrow checker now. The compiler and clippy is just so good at catching bugs. Give it a few years to mature the async/await (it is a mess currently no gonna lie) and it could displace Golang especially for cases where you care about tail latency.

Re: Is Rust Web Yet?

#129

Post by verdagon »

melissalobos wrote: post #96
staticassertion wrote: post #91

Earlier quoted context omitted.

Nope, it's written correctly as-is. Probably the "time to tests pass" is about equal, but the iteration and maintenance is far better in Rust.

> but the iteration... is far better in Rust That is something I would find hard to believe, if you mean iteration of changes. I have coordinated a few rust rewrites, and at least seeing engineers live programming, it takes far far longer to change and compile Rust code than python. Could you talk more about your company's process or how you mean?

I'd like to hear more about the Rust rewrites you've coordinated. Why do you think Rust took longer to change than Python?

I've felt this a little bit, but can only theorize why; the borrow checker makes mutability into a viral leaky abstraction, such that a change over here can sometimes cause widespread refactors on other components that would be decoupled in other languages.

Jury's still out on whether that's healthy long-term for a codebase, especially once the original writers have left. Jury's also still out on whether it encourages us into better architectures to begin with. Maybe it evens out, maybe not!

Re: Is Rust Web Yet?

#130

Post by LAC-Tech »

mamcx wrote: post #111
LAC-Tech wrote: post #45

I spent about the past month learning rust - and decided it just wasn't a usable language for me. I think what it comes down to is that I'm just not that into bondage and discipline from a compiler. Yes, I know, it's trying to make my code 'safe', and I'm horribly cavalier and I should feel bad, but: 1. the borrow checker rejects valid programs, has a lot of corner cases it can't catch, and is in active development 2…

> I spent about the past month learning rust This is a red flag for your complains: Is VERY likely you believe Rust is wrong, when the fact the problem is that your code is not good. I know this, my first 3 months starting Rust were thinking between "I'm a failure as developer" and "Rust is wrong" or "What? Why can't do this?". For first time after learning more than 12 languages I was truly in shock. And even, for s…

shrugs

Who knows, maybe rust clicking for me was just around the corner. I kept thinking "finally I'm understand this" and then something else would happen.

I'll leave it to the incredibly patient programmers who can spend 3 months just learning it. I'll use all the time I save to write more tests, and probably end up with something much more correct.

Post reply on HN