[deleted]
Rust 1.24
41–50 of 215 posts
Re: Rust 1.24
#42tokio-minihttp is 1 in plaintext benchmark in TechEmpower Web frameworks benchmark
https://www.techempower.com/benchmarks/#section=data-r15&hw=...
Re: Rust 1.24
#43tokio-minihttp is 1 in plaintext benchmark in TechEmpower Web frameworks benchmark https://www.techempower.com/benchmarks/#section=data-r15&hw=...
hyper is 6 and actix is 7
https://github.com/actix/actix-web
Rust is represented well!
Re: Rust 1.24
#44Can someone sell me on using rust over python? I am just gernerally curious as to the advantage beyond rust being compiled.
That's a bit like asking someone to sell you on using a plasma cutter over a dremel tool. It can be done but it's not particularly useful or sensible.
Re: Rust 1.24
#45Is rustfmt fast enough to reasonable be put on a save hook?
Been using it as a save hook in vscode (with RLS, too)... never noticed any slowdown because of it.
The bug where it _refuses to run_ if lines are > 100 chars is annoying
Re: Rust 1.24
#46Earlier quoted context omitted.
Performance is quite a bit higher for rust. And it's a much safer language by design (and forces the programmer to be as such). That said, development time in Python is much faster. Honestly, it depends on what you're building.
I'm curious what parts of Rust you think are safer than Python. Edit: The only big thing I can think of is the safety of compile-time type checking to ensure you won't end up with some kind of runtime error from mismatched types. Is there something I'm missing?
Immutability by default, exhaustiveness checks (make sure that you match over all variants of an enum or cover all valid values in an integer), return flow validation (did you forget a return somewhere? Is it the right type?), and, as you mentioned, type checking being mandatory, all libraries define their accepted types. Not only that, being types "cheap", it is customary to wrap base types in explicit types that won't be compiled:
type Point(u32);
fn foo(p: Point) {...}
foo(0u32);
^^^^ expected Point, found u32Re: Rust 1.24
#47Incremental compilation! And it's only going to incremental-er from here, as the compiler learns how to cache more and more sorts of interim artifacts to avoid redundant work. Though I think the wording in the OP is a bit off: > Historically, the compiler has compiled your entire project, no matter how little you’ve changed the code. This isn't quite correct. When you change the code in a given library, it has histor…
Have there been any thoughts around making the compiler something akin to a stateful server with an embedded datastore for the caching rather than using the filesystem?
What would be the benefit of this approach over using the filesystem?
Re: Rust 1.24
#48Earlier quoted context omitted.
I'm curious what parts of Rust you think are safer than Python. Edit: The only big thing I can think of is the safety of compile-time type checking to ensure you won't end up with some kind of runtime error from mismatched types. Is there something I'm missing?
When you work with the type system it checks a lot more than you check in Python. In Python you pass around untyped tuples and maps because defining classes won't gain you anything (and is surprisingly cumbersome and unpythonic), whereas in an ML-family language like Rust you use lightweight, fine-grained types to check that every function call is correct and you can refactor fearlessly. (I'd recommend using a langua…
Well, O'Caml and Haskell predates Rust by decades. I was delighted to see Sum-Product types in Rust when I played with it. They go a long way to cleanly model the problem domain. Obviously you can simulate them, but it's much easier to get wrong or "cheat" (say having a bunch of fields, only some of which are valid depending on a tag).
Re: Rust 1.24
#49Earlier quoted context omitted.
I'm curious what parts of Rust you think are safer than Python. Edit: The only big thing I can think of is the safety of compile-time type checking to ensure you won't end up with some kind of runtime error from mismatched types. Is there something I'm missing?
When you work with the type system it checks a lot more than you check in Python. In Python you pass around untyped tuples and maps because defining classes won't gain you anything (and is surprisingly cumbersome and unpythonic), whereas in an ML-family language like Rust you use lightweight, fine-grained types to check that every function call is correct and you can refactor fearlessly. (I'd recommend using a langua…
> I'd recommend using a language with garbage collection unless you really need to not though; OCaml is quite Rust-like but means you won't have to worry about the borrow checker
OTOH, Rust arguably has a better story for tooling (build system, dependency management, etc.), a more full-featured standard library, and better concurrency support. Depending on your priorities, some or all of these might be worth having to learn the borrow checker.
Re: Rust 1.24
#50Is rustfmt fast enough to reasonable be put on a save hook?
Been using it as a save hook in vscode (with RLS, too)... never noticed any slowdown because of it. The bug where it _refuses to run_ if lines are > 100 chars is annoying
I've been running the nightly version with "error_on_line_overflow = false" and it's been a fairly smooth ride. It's worth mentioning that I also haven't seen it fail to format a line within 100 characters since switching to the nightly version a month or so back.
https://github.com/rust-lang-nursery/rustfmt/blob/master/Con...