Welcome to Comprehensive Rust
google.github.io
google.github.io
I am working on safety critical control systems and there is a lot to prune from existing work in this area in SPARK and Ada.
This book[2], "Building High Integrity Applications with SPARK" really sold me on the benefits. It is a great intro of how SPARK was used for the CubeSat program at Vermont Technical College (VTC). A CubeSat was successfully launched in 2013. I could not find any critical mission software written in Rust yet especially that far back.
I found Julia's selection for a flight collision avoidance system perplexing[3], but it proves a PLs syntax and evangelism (maybe not in this case), can bias a selection of a PL for such tasks. People find Ada/SPARK's syntax and methods verbose and similar to Pascal or other PLs, however, I was up and running quickly in it as opposed to Rust.
You can program to bare metal in SPARK, and the tools are already there to provide high-integrity software. The tools for SPARK automate most of the verification. Most of Rust's wishlist is already in SPARK (and Ada). I hope the Ferrous Systems and AdaCore collab bears fruit for Rust, but I have been programming since 1978, and I play with many PLs, but I found Rust's initial learning curve very off putting and I don't have the time to wait for it to mature to SPARK's level. And this is from someone who loves J/APL/BQN and Lisp, so I have no issue with different programming paradigms. I found Zig much easier to get things done from the start, although it does not strive to be a SPARK or Rust.
[1] https://www.adacore.com/sparkpro
[2] https://www.amazon.com/Building-High-Integrity-Applications-...
Reading theough the spark tutorials and examples seems fairly similar to the rustlings excercise. I find the ways spark prevents problems, like forbidding side effects, is more onerous than the borrow checker making me specify a lifetime every so often. I'm not saying you are wrong to prefer spark, just that people with different backgrounds will find the learning curves different. You have been programming longer than I've been alive, so you certainly have a different perspective. I started with c64 basic then c on the amiga 500, then x86 assembler on 386, them turbo pascal, then turbo c++ on the 386.
I can't argue that spark isn't more mature for formal verification, but it feels like formal verification relies heavily on correct contract specifications with no way to measure when your contracts are correct. Unit tests and coverage at least give me a little feel good that I wrote enough tests for my rust.
For me, Rust seems too complicated at this point. I will continue to play and watch it. I use the Helix Editor, which I love, and it is written in Rust!
If you go back, then assembly was mainly used in mission critical software in aerospace, for example the Apollo guidance system. To quote an article about NASA programmer, Ron Garret about options in 1988[1] and the now-famous Lisp troubleshooting from 150 million miles away:
“There is Pascal and C and Basic and machine code. And that’s pretty much it in terms of popular languages. To get anything done in any of those languages is just really, really hard.” The code for most spacecraft ended up being written in assembly language.
I want free too, but tooling makes the system, and in SPARK2014 it is the tooling, not just the formally verified spec. of the PL that makes it really groove. Rust has a great build system in Cargo, but it does not have 10% of what SPARK2014/Ada/GNAT provide as an ecosystem and apps under its belt. I do think there are people working on this for Rust (Ferrous Systems with AdaCore), but I want to ship a product before that will ever happen. Maybe my next project will be Rust or Zig with contracts or April (Lisp and APL - my favorite, although there is BQN implemented in Rust!)
[1] https://thenewstack.io/nasa-programmer-remembers-debugging-l...
[2] https://en.wikipedia.org/wiki/SPARK_(programming_language)#I...
https://www.adacore.com/ferrocene
However I love rusts cargo and build system better than Alire. As Alire seems to bolted ontop of gprbuild. I also find it unfun to go back to forward declaration and definition (ads) files.
It also seems to me the rust ecosystem has more libraries in things I'm interested in and better support for the platforms I'm interested in.
What is your main use of Rust? It all depends on what you are doing. I use Zig for fun game dev stuff, and not SPARK, but for the safety-critical control systems, it's SPARK, not Zig or Rust.
Safety is fairly important and I like ada/spark for that but rust's community seems to be farther along in terms of support for Android and looks way more active right now.
From [3]:
> Julia is [...] executable
Indeed, that's a useful feature for a programming language :)
Regarding the collaboration between AdaCore and Ferrocene, the effort is to produce a Rust toolset that is qualified for safety critical usage (e.g. verification of object code that is produced, etc). That is _not_ the same as bringing SPARK-like language capabilities to Rust. I think too many people get that confused.
And I haven’t looked at everything yet, but it suggests to install Rust like this:
sudo apt install cargo rust-src
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Android already uses Rust internally, in fact for new code it's a major language. They have made this guide to teach Rust to their engineers working on Android, according to this post on reddit: https://old.reddit.com/r/rust/comments/zrs1of/new_rust_cours...
Depending on how you want to consider trust in a wider sense too it may even be worse than “double” because I do not have the same amount of trust for the package I am ultimately installing and the script I am using to install it.
Edit: it’s actually 3 things you need to trust I didn’t include curl itself which just released a security audit that found a number of vulnerabilities here https://daniel.haxx.se/blog/2022/12/21/the-2022-curl-securit...
…security is often harder than it looks.
No, you're still trusting one thing: the host itself. You're downloading both the script and the binary from the host. Both could be backdoored, and of the two, the binary is far easier to hide a backdoor in.
As for not trusting curl, you still need to fetch the resource somehow, so you're going to be trusting some tool to do it for you. That's not relevant to increasing the attack surface.
That clearly changes the trust calculation in this scenario.
I had assumed it was some 3rd party project which would have put it in a different category of problems entirely.
But the entire conversation is kind of pointless then. “There is a secret backdoor in the official Rust binary” is not a useful part of any reasonable threat model.
Technically, if you don’t read the script, you don’t know the binary is from the same host.
That doesn’t matter, though. The chain of trust is deep, including the tooling that produced the binary, your CPU, the internet, etc.
Downloading the first file basically says “I trust this site to give me this tool and nothing else”. Where it then gets that stuff from shouldn’t matter, even if it is from a shady site. You trusted them not to do that, just as you trusted them not to open up their own site so that hackers can replace files ont it.
I think the worst thing about this is that Rust is fashionable, so encouraging inexperienced devs think that these dangerous practices are just fine. Look around at how many n00b projects now suggest doing exactly the same thing. It's simply irresponsible of the Rust crowd to keep promoting it.
(BTW, you can run `curl | sh` in a VM or with a modified bash to intercept the code and catch the bash script in the act, so it's not actually as sneaky as people believe).
If you think the Rust org is going to pwn you in a clever sneaky way, then you can't use Rust or any Rust-containing products.
In the end, you're pulling hundreds of MBs of binaries that you won't review, they're compiled from over 15 million lines of code that I don't believe you'd ever review either. Reviewing just the first 10 lines of code gives you nothing. A smoke test in a sandbox is also worthless, since a binary could detect being run that way, or delay the attack, or attack by specifically miscompiling your code (see Reflections on Trusting Trust).
In the end, you have to trust the Rust org, all of it.
You're not wrong, until the end, it should be: "you have to distrust the Rust org, all of it."
And not just Rust, Python and JS and all the others. There are languages and systems that take trust and security seriously, but these are not they.
Anyway, off the top of my head, Ada.
https://en.wikipedia.org/wiki/Ada_(programming_language)
and E...
https://en.wikipedia.org/wiki/E_(programming_language) https://en.wikipedia.org/wiki/CapROS
Qubes and SEL4 are Operating systems. (OK Labs was acquired by General Dynamics. That seems like a pretty good recommendation to me.)
https://en.wikipedia.org/wiki/Qubes_OS
https://en.wikipedia.org/wiki/L4_microkernel_family#High_ass...
Most likely they get the precompiled rustc binary just like rustup, and LGTM-YOLO the package. If they try to be diligent, they maybe take extra 150K lines of mrustc code they can't reasonably carefully review for backdoors either, and then use it to bootstrap the several sets of 15M lines of code they won't look at.
I'll be happy to update it to suggest using rustup like "normal". Could you make a PR for that?
We put out the course to make it easy for even more people to onboard with Rust.
It should not be possible with normal borrows (and safe Rust) since they're statically checked to be acyclic.
Or you could use the recently-stabilized `new_cyclic` method: https://doc.rust-lang.org/std/rc/struct.Rc.html#method.new_c...
Of course, leaking memory is as easy as using `Box::leak`, although that's probably never going to happen accidentally.
Put differently, the borrow checker won't allow you to create a cycle of refrences (the & kind). But you can do it with library types such as Rc.
(I'm sure you knew this, just adding to the discussion)
Not that it matters as much as people think. Memory leaks aren’t a correctness problem. You typically want to restart a program or service regularly anyway to deal with memory fragmentation. You also frequently have a watchdog like systemd to restart your program if it crashes. Heroku restarts your whole dyno once a day. This means in practice that programs with slow memory leaks tend to work just fine (there are plenty of them in the wild.)
It's true that memory leaks can be small enough that they don't become problems in the end-to-end behaviour of the system in regular use. But a lot of bugs are like that. For example many memory safety bugs.
The view of rust is rather that they’re not safety problems.
Whether they’re correctness problems is more complicated: in general they are, but there are lots of cases where they’re not, like short-running processes (once the process terminated it’s memory is reclaimed so freeing it is unnecessary overhead), or FFI (you’re moving memory out of your purview, you can’t know whether it’ll be disposed of anymore).
Considing whether memory leaks are a security problem brings us to the traditional CIA definition of security - the A (availability) is at risk from memory leaks.
Memory safety bugs are very different, because whether or not they affect the functioning of your software, they’re a ticking time bombs that could compromise your system. A memory leak will at worst crash your software.
It's very unlikely you'll ever see Android supporting apps written in 100% Rust (just like it doesn't support apps written in 100% C++/C) - the APIs and UI toolkit are exposed and written in Java and you'll need to bridge either way.
Supporting Rust as a native code language to augment existing support for C/C++ via NDK is much more likely.
The difference in installation procedure is probably a security measure. Piping curl to bash is a bad move and it’s the Android security department that’s pushing Rust in Android. Plus, internally, Google has well maintained aptitude repositories with projects built from HEAD. It’s nice installing something like lldb from the command line and the internal Python interpreter is the latest version. And you know all of your coworkers are running that version, too.
[0]: https://rust-unofficial.github.io/too-many-lists/index.html
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 a number of features (ergonomic and technical) and some really nice language design that permits writing quite “high-level” code. Personally, having a compiler and type system as powerful as Rusts makes it worthwhile alone.
With faster compiler toolchains and REPL like tooling.
In my space (data engineering and associated systems), Rust is a much more palatable and easier sell than an Ocaml or a Haskell.
> With faster compiler toolchains and REPL like tooling.
TBH I don't really miss a REPL, I know a lot of people love it, but between the type system, tooling like RA, and how Rust makes writing tests _so_ frictionless, I've not really had any need to touch a REPL in the last ~2 years. I've probably been abusing the frictionless test functionality to write little snippets to test out using a new library or tool, I certainly find it a lot manual work than the "type multi-line snippet into repl. Make a typo. Start it all over again. Discover that part x actually wants a y. Write it all over again. Repeat until correct. Painstaking trawl through repl history to find the set of code that actually does what we want and lift it into our actual code base" experience I have with reps-based development.
Rust has a great role to play, replacing C and C++ in all performance-critical and security-critical underpinnings of modern computation (from kernels to UI toolkits). But higher up the stack, where those concerns are outweighed by overall development costs, other languages will continue to rule; and if one's focus is there, learning Rust is probably a waste of time.
Eh, I've written and maintained data pipelines, and API layers for downstream teams in prod in Rust, and it was a much more pleasant and low-effort experience than either doing either in Python. I could have had a "complete program" written first in Python, sure, but that gain in velocity is rapidly overtaken by the hours spent debugging and fixing issues in prod, issues that in Rust, I've not typically had.
> if one's focus is there, learning Rust is probably a waste of time.
au contraire - I genuinely think that learning languages, especially ones that are _not_ similar to your day-to-day language is an incredibly valuable thing to do. Learn a Lisp, learn some Haskell, etc, it exposes you to ideas that you wouldn't have otherwise come across, and gives you extra skills and tools with which to solve problems better. Maybe not all those tools are always applicable, but when they are it's a force-multiplier.
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://github.com/pola-rs/polars/
[3] https://github.com/dimforge/nalgebra
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.
But I wish there were a language that solved the two-languages problem (fast vs. easy to work with). I find Rust quite verbose.
That's the whole pitch of Julia.
That is the motivation and purpose of Julia.
For some people's workflows it already seems to have solved the problem, but in general the "easy to work with" part is still in progress IMO. Some of it is the (in)famously annoying compilation delays, but a large part of it is just a tooling and ecosystem thing (both of those sides of the issue are being actively worked on).
The difference from C/C++/other low level languages is that it's not the language itself that's difficult to work with, it's the current tools and workflows that are suboptimal. The language is pretty well-designed and fun to work with, so there's hope that it can actually solve the two-language problem for a wider variety of devs and their needs.
Rust itself can be made "easy to work with" at the cost of boilerplate. You end up with code that's littered with idiomatically superfluous uses of things like .clone(), interior mutability, Cow<>, perhaps even such exotic features as the Any trait for encoding "dynamic" behavior.
The flip side is that it's easier to refactor this code and make it more correct and performant; "simply" replace the boilerplate with proper Rustic code and deal with the resulting compile errors. It's a very viable strategy that has no direct equivalents in other languages, not even in C/C++.
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 (namely Python) for the flexibility you get, the easiness with which you can adapt to changes and the lack of a need to focus too much on machine-related details. This is the least suited field for Rust between the one I mentioned, in my view.
Computational science needs to focus on algorithms and formulas, Rust can hide them a bit too much under "unwrap"s "iter"s and so on. Plus still no stellar library support and (my) experience with other tools (namely C + OpenMP, Julia, C++, numpy...) made me feel using Rust for that was unnecessary and slower.
When you are designing systems, however, that's where Rust is a complete game changer. Honestly I don't think C++ can stand a chance in its current level. Everything, from the package system, to the borrow checker, to the safe threading model, makes you pity your C++ ancestors for how hard they thought this kind of programming had to be. Rust makes it orders of magnitude more approachable, saner, and with better results too.
Embedded... it's nice but honestly all the dark arts of unsafe Rust are not standardized so it doesn't feel as future-proof as C already.
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.
"Only". Intra-process shared memory is by far the most important kind of shared memory. 80% of the time you see someone advocating for message-passing multi-process over shared memory multi-thread concurrency or parallelism, it's because shared mutable memory is incredibly hard to get right in just about every mainstream language except for Rust.
> It does nothing for shared resources using OS IPC, or external resources shared among threads.
Only partially true. The very same language constructs which make shared memory safe can also be used to create safe wrappers for other shared resources.
Language constructs only help if there are no other applications accessing the same resources.
There's a huge world outside of microservices.
> Language constructs only help if there are no other applications accessing the same resources.
You're mistaken. Rust's language constructs can often help you write safe wrappers around inter-process communication and synchronization mechanisms. Of course, all bets are off if the other processes don't adhere to the agreed-upon IPC protocol, but that's not the point. The point is that Rust makes it easier to not accidentally screw up the protocol yourself.
In my opinion Bevy may be one of the better ECS implementations I've seen, as ex-gamedev it's just very well thought through. It's never going to supplant Unity or Unreal but that's less of a language issue than just the scope of those codebases.
You're seeing a lot more of it showing up in OSes across Android, Linux and I've seen a fair bit of movement in the windows space as well.
As for IPC, C/C++ doesn't help you their either, that's more of a framework level concern. If anything the threading model helps when you're doing concurrent IPC dispatch(ex: MTA COM or equivalent high throughput IPC) and preventing data races.
If your use case is to replace entire tools, and your team isn't familiar with static languages, then Go is probably the better option. There's no denying that it's much easier to learn.
[0] https://pyo3.rs/
I ended up writing a book, "Data Analysis with Rust Notebooks", where I demonstrate using Rust + Jupyter Notebooks for tasks I'd normally use Python for. It's a good experience, although there are some additional limitations when using Rust as a notebook kernel.
[1] https://datacrayon.com/shop/product/data-analysis-with-rust-...
When you have to prove your intelligence level (or rather "street cred") in a competitive market you have to show that you can learn the newest complicated things quickly. Rust is pure cryptonite in such a world.
Merriam-Webster's definition: https://www.merriam-webster.com/dictionary/kryptonite
It has been adopted by most large tech companies and several high profile open source projects within ~5 years of it's stable release. It certainly has been rapidly and widely accepted.
For important projects too: Google is using it in Android, Microsoft is using it in Windows, Amazon is using it for Lambda, Meta is using it for their source control tool, Dropbox is using for their storage backend AND in their client apps, Cloudflare is using it for their core proxy, etc.
Yeah me. I’m data science/data engineering.
Wrote and debugged a lot of R and Python, fair bit of Spark too.
Learning Rust was fine. Not trivial, but definitely worthwhile. I work on more “data systems” than once-off scripts and analysis in my work, so the performance and correctness of Rust has proven more valuable to me than the flexibility and development speed promises of Python. The former lends itself to difficult to maintain, hacky, patchwork code, and the latter falls apart after the nth time you have to fix some Python code in prod that’s failed 3.5 hours into a process, because some random package has thrown some as-yet-unseen error.
There’s some interesting stuff happening in the data space in Rust-polars data-frame library gives you pandas like functionality, but with better performance and type checking, the data-fusion stuff is making strides as well. There isn’t a 1:1 replacement for all your ML libs, but it’s getting there! Linfa and SmartCore are making strides on the sklearn-like space.
Would you use Rust to replace your ml stuff in Python at work tomorrow? No, probably not just at the moment. Is it worth learning because it’ll make you a better dev, and give you more options and tools the next time you have a non-standard problem to solve? Yes, definitely.
But: I'm not well versed in Python Pandas either, and my rust is better than my python (though Ruby is my daily language, so I'm very used to dynamic languages). The thing I miss most is the rapid REPL workflow in Python, where I work out the pipelines, filters, map-reduce and so forth, on the interactive REPL and then extract that into python scripts.
The polars scripts that I worked with, were small enough and the builds are incremental, therefore fast: milliseconds. But the build-step inbetween is somewhat clumsy when exploring data.
But the end-results are just so extremely cleaner, saner and especially faster that it certainly is worth it. I worked on a dataset where crunching it in python took upwards of 14 hours, and the polars under an hour. That feedback loop alone is worth days of fighting the borrow-checker. And that immediate feedback by the compiler/checker "this column isn't guaranteed a String, it could be missing, could be unparsable; deal with this now" is priceless. Too often did I have some ETL run for 8 hours, and then choke on some column that I swore should've been UTF8. Fix it, and re-run. Wasting 8 hours. A type-checker in ETL/data flows is priceless.
Edit: to be clear: I am developer. Not datascience. But I do need to understand my users, my business, my market. Developer/devops today do need to crunch large datasets: at least I do.
Apart from the Android specific additions I mean.
In general, I feel that the new course will be useful for people who want to teach Rust. If you have a group of engineers and you want to teach them Rust, then this is a ready-to-go solution. You only need to spend some time getting familiar with the material and then you can start teaching it. I don't think there was such a resource before.
For self-study, I really like the Rust book and also Rust by Example. I've listed a bunch of good resources here: https://google.github.io/comprehensive-rust/other-resources.....
When I'm teaching the course, I start by asking people about their background — if it's primarily C/C++ people, then we can quickly page through the slides about the stack and the heap.
Kotlin made a huge effort to stay compatible with Java. You can call Kotlin code from Java and Java code from Kotlin, so orgs could migrate their apps piece by piece. The only real incompatibilities that I've experienced were when going from C code via JNI into Kotlin. All sorts of really weird issues creep up.
There was no boiling the ocean in any of the large apps I worked on at Amazon and Meta - just add Kotlin and see how it goes, it's a really easy sell to tech VPs. First we added Kotlin just for the unit tests, then for small features and eventually with Google releasing Jetpack with Kotlin extensions, for all new apps and features.
Kotlin also improved upon existing painpoints in Java and provided a ton of syntactic sugar for things that were tedious in Java. For example, proper get/set syntax for fields, data classes with autogenerated equals/hashcode, explicit nullability for types, val with 'final' semantics to get rid of all the final variables, fields in interfaces, top level functions, etc. All the functional stuff in it is nice too.
Go is much leaner than Kotlin. The VM or performance is not an issue - Kotlin generates entire classes for simple syntax, to make things convenient and compatible, but the bytecode is pretty bloated.
I imagine that Google had sufficient resources to make a Go<->Java translation layer (though Go would have needed generics) but transitioning a huge API like Android is already a large effort, and if the language isn't fully compatible with the existing code, it would have added an order of magnitude of complexity, so Kotlin was a much easier sell.
In my opinion, migrating to Dart would have been more practical than Go (as evidenced by Flutter), so thats the real head-scratcher. It would have been easy for Java devs to learn Dart because the OOP concepts translate directly.
Other factors:
Google already had a relationship with JetBrains because of Android Studio.
The Oracle Google lawsuit was happening at the time and I speculate that Google needed to show to Oracle they can move off of Java. Kotlin happened to be available.
But then they also wanted a more bare metal environment in addition to that. So something like C, C++, or Rust.
It's always been unclear whether Go belongs in that list. It was conceived or at least positioned as a "systems" language like those I listed, and there was noise early on about it replacing C++ codebases at Google, but with over a decade of hindsight now, I think in practice it's pretty clearly a Java replacement rather than a C++ replacement. (I guess there's a fun symmetry here in that Java was also conceived as a C++ replacement and also wasn't.) But Kotlin is just a much more natural way to fill the Java replacement niche on Android.
IMO, choosing Java was one of the worst decisions they ever made. There's a reason why no other platform (PS5, XBox, iPhone, Mac, Linux, etc..) don't choose a language like Java. Android has so much jank because they chose Java
Please keep submitting them. You can use the little pencil icon in the top-right of any page to quickly submit a typo fix patch. I'm from Denmark and English is not my first language — I very much appreciate the help from you to fix all the grammar mistakes :-)
I would argue that it's not as bad as it's made out to be, especially if you're not doing full recompiles and using it on modern (2019+) hardware; but it is a noticeable difference in similar large codebases.
That's fair. My comment was mostly about performance.
Additionally thanks to heavy reliance on binary libraries, when starting a new project, we only need to compile our own code.
I know this from observing a ~90s difference between debug and release builds, of a large (mostly auto-generated) crate that had a couple of thousand `#[derive(serde::*)]`s. [1]
This doesn't affect most users, because first-party macros like `#[derive(Debug)]` etc are not slow because they're part of rustc and are thus optimized regardless of the profile, and even with third-party macros it is unlikely that they have thousands of invocations. Even if it is a problem, users can opt in to compiling just the proc macros in release mode. [2]
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.
I’ve found this to be highly dependent on the hardware you are using. On my 2015 MacBook Pro, Rust was slow enough to be annoying. On my new M1 Pro MacBook (which is ~9x faster), it’s fast enough for me not to notice compile times.
They can help, but I am well aware of which kinds of bugs existing C tooling cannot catch. I still take issue with your opinion, which hold through this thread, that claims that productivity gains from not having to track these down necessarily outweighs Rust's compile times.
Coming from C++ rust's compile times don't feel extraordinarily long.
There are trade-offs, rust makes one, use it if it makes sense but these comparisons are just pointless. This whole thread is filled with such arguments. Sure use OCaml, Haskell, Go whatever suits your needs. But let's not pretend that they achieve at compile time what rust does.
Somebody is complaining about compile time, somebody says GC alternatives exist. No, if you are getting into Rust you pretty much know the trade offs. It's on you if you choose Rust somewhere where a GC, REPL providing alternative would have been enough. The miracle of Rust to me is that I usually find Rust high level enough to not have to bother with the alternatives most of the time. I would write my UIs in flutter and my web frontends in TS. I am under no illusion that a GC language would not be more productive in most cases.
Are you talking specifically about the memory use of rustc vs. ocamlopt? Or do you mean that rustc is faster than ocamlopt at compiling a similar program? Or are you saying that rustc does more work than ocamlopt because of the borrow checker?
I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care.
So I second the advise for non-trivial projects, they give a much better idea of the upsides and downsides of rust.
Also, the two aren’t necessarily mutually exclusive. Many people learning the language have reported being surprised by the way Rust seems to make "doing things right" the path of least effort, and this applies to best practices in general, not just memory safety.
Top doc comment: The same license info that's in every file. Not helpful for describing what the module does and how it fits in with the rest of the project.
Many features gained a lot of adoption accross languages over the last two decades, like anonymous functions (with convinient arrow syntax), explicit option types instead of implicit null/undefined, match constructs, well-integrated library management, for(each) loops using iterators instead of indices, map/reduce functional iterators, etc. Rust has the advantage of being able to make these core parts of the language and standard library, resulting in an overall more expressive language.
And in rust's view these features should not only be used to make coding more convinient, but also to encode intent and make undesirable things impossible. This is reflected in the standard library (for example it's impossible to access the data protected by a mutex without locking it), and the philosophy is copied by the ecosystem.
Build tooling for the C/C++ ecosystem is a mess.
https://bevyengine.org/learn/book/getting-started/setup/
The early setup docs offer ways to improve compile speeds. Some help all Rust projects (change your linker) and others are specific to Bevy (enable dynamic linking if you're not on Windows).
Yes, it's a little jarring for an intro to game development with Rust to start with, “first, change a bunch of things so your compile speeds don't suck by default”. But I appreciated it because it helps you evaluate Bevy properly (it's as fast as it'll get from that point) and it also made my non-game Rust project workflows faster.
Bevy also sets expectations well about the initial slow-ish build (“This will take some time as you are essentially building an engine from scratch. You will only need to do a full rebuild once. Every build after this one will be fast!”).
With the dynamic link feature it takes about 1s to compile + link and Bevy is very much a nontrivial runtime/library that makes use of lots of Rust features.
How slow is "unacceptably" slow?
Personally I do not find this to be an issue the vast majority of the time. Especially in combination with cargo watch which can automatically run a check/build/tests/... whenever a change is made.
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.
It feels logical because Rust is close to the metal, but I don't know enough Android or Rust to be sure.
Roughly speaking, the Android Platform is the Linux distribution running below the Android apps we all know. There are a number of daemons running on the system and these are often written in C++. We've now made it possible for Android engineers to write them in Rust instead (or to link in Rust libraries if they want). To do this, the Android build system had to be extended with new rules, see https://source.android.com/docs/setup/build/rust/building-ru....
The overall goal is to have more secure software. Rust removes a whole class of possible security vulnerabilities and we deploy it to make phones more secure. See https://security.googleblog.com/2022/12/memory-safe-language... for details on that.
For learning Rust via a non-interactive medium, I recommend the Rust Book[2]. It has all the narrative that the course material is missing.