Live data from Hacker News

Welcome to Comprehensive Rust

google.github.io

101–110 of 204 posts

Re: Welcome to Comprehensive Rust

#101
post #86

I still play with Rust (and Zig), but I have decided to put my work efforts into SPARK[1], the subset of Ada, for high-integrity software and formal verification. I know AdaCore and Ferrous Systems are collaborating in trying to bring a lot of Ada/Spark's capabilities to Rust, but this is still going to be some time. Ada has a longer legacy in this game. I am working on safety critical control systems and there is a…

NVidia also went through a similar decision for their high security critical firmware.

Re: Welcome to Comprehensive Rust

#102
post #68
post #39

It's kind of surprising to see that Rust is so rapidly accepted by wide range of developers. Unfortunately I'm from DataScience field, so I cannot see much motivation to learn Rust, but I am considering learning it, because language itself seems exciting! Is there anyone on HN who is from DataScience field like me and has learned Rust? It would be much appreciated if you could share the experience.

Rust has amazing integration with Python through PyO3 [1] so see it like a safe alternative for high performance calculations and operations. The rust data science ecosystem itself is starting to come together with projects like Polars [2] (Pandas alternative), nalgebra [3], Datafusion [4] and Ballista [5]. Of course nowhere near Python but that is hard to beat today. [1] https://github.com/PyO3/pyo3 [2] https://gith…

Also dfdx [1], which is shaping up to become a great neural network library (though GPU support is still WIP, give it a couple months before production use).

Of course the ecosystem isn't as diverse as python yet, but if you're willing to call a bit back and forth between rust and python it's great.

1: https://github.com/coreylowman/dfdx

Re: Welcome to Comprehensive Rust

#103
post #8

The first thing I implore everyone to do when evaluating Rust is to check out a non trivial project and start hacking on it. I have always found the compiler to be unacceptably slow in these cases, especially if you come from C rather than C++. If you work your way up from Hello World you may not ever notice this until you already invested a substantial amount of effort.

Slower compile times are a small price to pay for memory safety and much higher productivity.

I get those with Go and I have blazing fast compile times too.

Re: Welcome to Comprehensive Rust

#104

The first thing I implore everyone to do when evaluating Rust is to check out a non trivial project and start hacking on it. I have always found the compiler to be unacceptably slow in these cases, especially if you come from C rather than C++. If you work your way up from Hello World you may not ever notice this until you already invested a substantial amount of effort.

I work on quite a large Rust project, and my regular `cargo check` takes around 5 seconds. Of course, I'd be happy if it were instantaneous, but "two deep breaths" worth of turnaround time is hardly a deal-breaker, especially given all the bugs that the compiler prevents for free that I don't need to spend time tracking down.

EDIT: I checked just now and it takes one second to `cargo check` the shallowest crate in our workspace, and six to check the deepest.

Re: Welcome to Comprehensive Rust

#105
post #20

Earlier quoted context omitted.

Rust macros are not the fault for its slowness. expansion is one of the fastest compilation phases. Time is rather spent in other steps like type checking, llvm optimizations and such. The issue is more Rust's generics as they cause a lot of code to be passed to llvm (among other issues for Rust's slowness).

Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. This is because building in debug mode also compiles proc macros in debug mode, so while the macro itself compiles quickly (because it's an unoptimized build), it ends up running slowly (because it's an unoptimized build). I know this from obser…

> Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros.

Oh that's interesting. But note that it's an issue caused by (from the perspective of the language) user code being slow, and also only if you compile in debug mode. You probably don't want to unconditionally compile proc macros in release mode, as most times they probably don't get invoked thousands of times. Ideally you would probably a) invoke macros in a parallel fashion, with multiple expansion threads, and b) maybe have rustc signal to cargo somehow that there are tons of invocations of a specific macro and that it might make more sense to recompile the proc macro with optimizations turned on.

Re: Welcome to Comprehensive Rust

#106
post #90

This is great. I'd recommend the Learn Rust With Entirely Too Many Linked Lists [0] tutorial as the next step. It really helps you grok the borrow checker. [0]: https://rust-unofficial.github.io/too-many-lists/index.html

Yeah, that is a fun tutorial indeed :-D I forgot to add that one to the list of https://google.github.io/comprehensive-rust/other-resources..... Would you care to open a PR for that?

Re: Welcome to Comprehensive Rust

#107

Earlier quoted context omitted.

It does not guarantee, but it is actually quite hard to cause a memory leak by accident, because at the same time Rust makes creating cycles hard.

I actually haven't tried this... do you know off the top of your head what it takes to make a cycle with Rc? It should not be possible with normal borrows (and safe Rust) since they're statically checked to be acyclic.

You could store a `RefCell>` in an `Rc` and set it to `Some(rc)` after creation.

Or you could use the recently-stabilized `new_cyclic` method: https://doc.rust-lang.org/std/rc/struct.Rc.html#method.new_c...

Re: Welcome to Comprehensive Rust

#108
post #39

It's kind of surprising to see that Rust is so rapidly accepted by wide range of developers. Unfortunately I'm from DataScience field, so I cannot see much motivation to learn Rust, but I am considering learning it, because language itself seems exciting! Is there anyone on HN who is from DataScience field like me and has learned Rust? It would be much appreciated if you could share the experience.

We developers love so much to learn computer stuff that we want to do it even when we don't need to. I worked on data science, computational science, some system engineering and embedded projects. I tried Rust on all of them but it was valuable only for the third. In data science the focus is more on speed of development and as much as Rust is more enjoyable to use than C++, it doesn't match scripting languages (name…

Rust still needs to do a lot of catching up in HPC, HFT, GUI, game engines, console SDKs, OS drivers on Apple and Microsoft OSes, Arduino, LLVM and GCC,...

Rust threading is only safe between threads accessing data structures in process own memory. It does nothing for shared resources using OS IPC, or external resources shared among threads.

It will certainly improve, as hopefully C++ will, even it never gets 100% as safe as Rust, the ecosystem has too much weight for decades to come.

Re: Welcome to Comprehensive Rust

#109
Unrelated: but why does Google use Kotlin(for developing Android apps) and Rust when they have a nice little language in Go. Genuinely curious: Is Go not a good fit for developing Android apps(Is targeting JVM the concern?) or system programming(using Rust in Android systems), what does it lack?

Re: Welcome to Comprehensive Rust

#110

Earlier quoted context omitted.

It does not guarantee, but it is actually quite hard to cause a memory leak by accident, because at the same time Rust makes creating cycles hard.

I actually haven't tried this... do you know off the top of your head what it takes to make a cycle with Rc? It should not be possible with normal borrows (and safe Rust) since they're statically checked to be acyclic.

The Rust Book has an example: https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

Of course, leaking memory is as easy as using `Box::leak`, although that's probably never going to happen accidentally.

Post reply on HN