Rusts tooling is pretty stellar.
Macros make IDE support a lot harder than in other languages, the atrocious compile times sure do as well. While IntelliJ Rust and rust-analyzer both try to do their best (kudos to the teams working on them!), it's still nowhere near anything I'd call "stellar".
There are mitigations being worked on right now, like compiling macros to WASM[0] and Cranelift[0], but these endeavours, while very promising, I wouldn't call production-ready yet.
[0] https://github.com/dtolnay/watt [1] https://github.com/bytecodealliance/cranelift
EDIT: Also, debugging. I'm not sure of the current state of it, but last time I checked, it was pretty much just GDB integration that was working. CLion (which I think uses GDB?) is able to give you a nice UI for basic debugging, don't know about VSCode integration.
Still, even if it works, it's not at all comparable to debugging in C#/JVM, you're limited to very basic stuff compared to these languages / the well-known IDEs for them.
So, again, it may be "fine" or even "good", but imho it's not exactly stellar :)
Optimized builds though, yeah, you routinely hear about multi-hour builds. As long as there's a dev-friendly fast mode though, slow optimized builds don't bother me all that much.
Now, "atrocious" may have been bad wording without context: I think it's just taking very long to finish the normal edit-start-debug cycle, compared to other languages (Go, Java, C# for example). I don't have any numbers right now, but I'll try to update my post once I get home, I've done a few basic emulator projects in Rust :)
At least, it was long enough to be annoying to me. Maybe I'm just too used to C#, which I use at work.
Many of the hours-long optimized builds for Rust projects that I've seen have turned to <10 seconds without optimizations on a clean build (possibly libraries are still cached tho), and even fairly large ones are still less than a minute. Tiny projects are around a second or less. I'm usually looking at pathological cases though, so I'm not sure how well those hold up in general.
So I'm not looking for interactively fast - very few languages achieve that on even medium-sized codebases, even if they're interpreted. But under a minute for a couple million lines of code in the project and libraries fits in my "reasonable" range.
VSCode with RLS gives you decent IDE support - not Visual Studio for C# standard, but much better than a large number of languages.
Also C++17 is much better version taking away the deficiencies of earlier versions and if not better at least provide similar run-time guarantee and safety as Rust (which also needs to rely on unsafe code to do anything meaningful with systems programming).
So if you use either modern incarnation of C++ or Rust, you will get same safety guarantees. Just with C++ you will not have to climb the mountain of learning just to do simple things.
I think Rust gets a lot of hype because it's syntax is complex and learning curve is much higher than C or C++ and programmers see new shiny language which got some traction as Panacea for all the programming problems.
As a C++ Dev who's done some rust on the side this is utter horseshit. Regardless of which C++ version you use it is utterly trivial to write code with undefined behaviour. Even if you're extremely diligent you will eventually be hunting down a bug caused by undefined behaviour.
Rust allows you isolate such instances of unsafe-ness to specific parts of your code base. When you're auditing for safety, you only need to audit those specific parts because everything else is safe by default. For example, the implementation of std::vec::Vec uses unsafe, but it exposes a safe interface. So once you've audited the few hundred lines of std::vec as being safe, you're sure that the millions of lines of code relying on it are transitively safe.
> which doesn't require active internet to work
cargo build, cargo clippy, rustfmt, rust-analyzer, rustc all work without internet. If you want to fetch dependencies from the internet, you need an active connection. If you're in a situation where internet isn't available, you can work around this by writing all the libraries you need. Same with rustup - it needs the internet to download new versions of rustc and cargo.
> you will not have to climb the mountain of learning just to do simple things.
I'm sorry you felt this way. Learning materials are improving all the time and the language is improving too. For example, future combinators were a pain but with the advent of async-await it's easier to write and read code that deals with Futures. Give it another try :)
Why can’t cargo be simple enough like pypi where all the dependencies are in intranet and private or another way is all the dependencies are in my own simple folder and can update it separately whenever I need rather than relying on an internet connection.
Rust cannot match C and it will always need to interface with C code, so in the end it will only be as safe as the C code it is interfacing.
I do not understand why to create complex syntax and semantics and difficult to learn language in spite of so much development in compiler world. Like Swift which is similar to Python style syntax. Also Swift is performant and secure enough to provide replacement for objective-c.
Hopefully FP (functional programming) becomes more mainstream and take away all this burden of imperative languages like Rust. But being pragmatic understand for hardware C will be there at least for the foreseeable future and Rust and any FP language can only do so much.
On a personal level Python made code beautiful by white-spaces, pep-8 and cultivated a habit of trying to write beautiful code. It did not succeed completely in writing every library beautifully because in the end it needs to interface with C libraries where practicality beats purity.
Rust copied gofmt and introduced rustfmt. Still Rust has miles to go until it is just able to be as clean as Python for beautiful code and cultivate it as very important habit like Python. It will take Rust may be another 30 years or more to come close to it, given its syntax and reliance on C interface.
Any other language I see at present with safety guarantee and as clean as Python is Swift.
I like lisp, Haskell and other FP which can achieve a lot with very little code, easier to refactor and maintain in the long run. Rust is just opposite of it. It’s as difficult to learn as Haskell with complex syntax and semantics, but less powerful than C.
> Hopefully FP (functional programming) becomes more mainstream and take away all this burden of imperative languages like Rust.
Pure FP is overrated. It is a nice academic model of computation, but it doesn't reflect the way how hardware works. Hardware is mutable and memory is limited.
> It’s as difficult to learn as Haskell with complex syntax and semantics, but less powerful than C.
This is a subjective opinion, not a fact.
> as clean as Python
:D :D :D
Now, not everybody actually need great performance, so some distance between hardware and abstraction is ok, but the amount depends on the use case.
I mean I don't see people complaining how you don't need to manually manage memory in SQL expressions.
Well, they don't complain about not having to manually control the low-level bits of query execution, but later they frequently complain about performance problems. And then they add hints, setup buffer sizes, indexes, etc.
Also, Rust (and to some degree C++) shows that you can have both very high-level, productive abstractions and low-level control. They call that zero-cost abstractions. The price to pay is a steeper learning curve, but not actual productivity or final performance.
This is the most exciting part about Rust actually. I know how to write Kotlin, Scala, Java or C# code that's close in performance to C or C++. But this will be ugly, unsafe and hard to maintain, non-idiomatic code. Rust gives ability to write code that has almost Python-like expressivity but is still fast as if it were hand-optimised loops and pointers.
Just about everything in software engineering is a compromise of sorts. Not knowing Rust or C++, I doubt they're as high level as something like Haskell or domain specific languages like SQL. Are monads first class citizens on C++? Type classes? Generalized Algebraic Data types? Parametric polymorphism & pattern matching? And so on.
Would you really achieve the same amount of type level guarantees, equally concise control flow and concurrency on C++ with an equal amount of lines of code as would be possible on Haskell? If not, then there obviously is a productivity penalty. Just like on Haskell there is that performance penalty for not being able to drop down close to the metal.
From what I can tell, these languages are not aiming to be very high abstraction level languages but instead solid systems level languages with some convenient abstractions and design patterns baked in from higher level languages.
Sticking only to some zero-cost abstractions limits how high level abstractions it is possible to bring to the language. This in turn limits productivity.
Anyway, type safety is not the same as productivity. If it was, then nobody would use Python or Ruby and everybody would use Idris. I became much more productive quickly in Rust than Haskell.
Haskell also has metaprogramming in terms of Generics and Template Haskell, allowing you to create custom DSLs and such. Sadly, it kind of leads to pretty ridiculous compile times and mixed editor support so I'm trying to avoid that.
We should remember productivity is really subjective and not the same thing as high level abstractions. We're typically the most productive on the language we have the most exposure to, whatever it may be.
I agree with you on this we are most productive in the language with most exposure.
Indeed many in Rust community do not realize that the LLVM infrastructure they use for Rust to make its code executable by real hardware is itself written in C++.
Rust is still miles away to compile itself and may not happen. So survival of Rust is dependent on progress of C and C++. So I doubt it is even be viable to call it their replacement.
And the operating system is written in C, and the CPU in VHDL (or sth similar). Compiling itself is a property that only academics take care of. LLVM and C are not going anywhere anytime soon. There are more important things to do now. That's why Rust is already much more loved and popular language than Haskell - because it focused on important stuff and getting job done, not theory that looks only nice on paper, but doesn't match how hardware (and generally the world) operates. Real stuff is mutable. Not being able to mutate stuff in Haskell directly is a productivity killer. Many of the "abstractions" you can build in Haskell exist solely to workaround this limitation.
Exposure has nothing to do with this. Rust is new and Haskell is since forever, yet Rust already far surpassed Haskell in terms of adoption.
Just like with Elixir and many other high level languages I don't think it's meant for building low level systems where you're heavily constrained by resources.
But why wouldn't it be able to interact with external systems? I'm not having any problems building an API that interacts with a database, caching layer etc.
https://bartoszmilewski.com/2014/10/28/category-theory-for-p...
FP languages are not in the same problem domain as system programming languages, so claiming FP should replace Rust is just ridiculous (and as a side note: Rust borrows many things from Haskell/Scala as well, so some FP is there).
I will wait and watch when Rust will be used to control Apple or Android hardware as performant with similar safety guarantee like Swift or now Kotlin.
It's also same as C++ used by Microsoft to provide underlying abstraction of hardware on Windows.
As for hardware abstraction - not sure what is your point - Rust can use any C API.
Don't know how iOS, but Android does offer native APIs, so Kotlin is not the only officially supported choice there. Actually for anything that needs performance, e.g. games, Kotlin is a nogo.
Google already mentioned a couple of times at Android Fireside Q&A sessions that it is weighting Kotlin/Native adoption on Android.
And even if not, Rust isn't taking C++ and Java place on Android, specially after Project Treble changes, where drivers can even now be written in Java.
Google and Microsoft are indeed adopting Rust, with some products already in production, although they are also among the major ISO C++ contributors, so it remains to be seen how much Rust love from their security teams will spread into the OS development teams.
For example, I still look forward to the day that Azure Sphere actually offers something else other than C, in spite of its security sales speech.
Apple is not adopting Rust to replace their C and Objective-C code, rather Swift, as they quite clear mention on the Swift documentation.
> Swift is a successor to both the C and Objective-C languages.
It does have registries[1] and vendoring[2].
[1]: https://doc.rust-lang.org/cargo/reference/registries.html
[2]: https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
This deserves clarification. You only need to audit those specific parts because everything else is safe IFF those parts are safe.
Rust syntax is simpler than C++. Rust is a much smaller language. To me it appears much more like a mixture of C and Haskell, rather than C++.
Rust RFC's process is also from there.
Hopefully rust can have something like PEP-8 in Python to inculcate habit in programmers to write beautiful readable code.
As for pypi, it is Perl that (as far as I know) invented language specific packaging. Then Bundler, a Ruby project took and improved the situation and let people easily create repeatable and predictable installs. Some of the people behind Bundler then went on and built Cargo. Packaging for Python is and has always been a mess, which people shy away from rather than copy. There are some signs of improvement in later years, but it is not from pypi.
As for RFCs, I would assume the RFC process should reasonably be attributed to IETF. They were a bunch of decades ahead of Python there..
This is absolutely, completely wrong. If you want to write safe C++, you must follow a very strict discipline, essentially equivalent to appeasing the Rust borrow-checker. The main difference is that straying from this discipline in Rust leads to a compile-time error, while straying from this discipline in C++ leads to unsafe, but probably working, code, that you will only discover is unsafe after much work.
And in both languages, you sometimes need to drop from the safe subset to do some things. In Rust, that is signaled explicitly with `unsafe`, in C++ it just means using more C-like constructs.
It would also be very interesting to see what subset of modern C++ vs Rust could be used for safety-critical code. Given that several C++ idioms like RAII depend to some extent on exceptions, and those are not permitted in safety-critical code (per Bjarne's own standard), I would not be surprised that Rust will become very attractive in this sector once it matures.
Static analyzers typically catch trivial stuff like returning a pointer to a stack from a function. Which is easy to spot during code reviews. But they don't catch more sophisticated UB that can result from bad interaction of code in different units. And this it the kind of UB we're the most interested in being protected from.
And compiling in debug does enable bounds checking for arrays, vectors and iterators invalidation.
Rust still needs to define what actually is UB in unsafe blocks, how multiple implementations might affect the language and a memory model.
Not saying that it is perfect, rather that it can be made safer than how many make use of it, which is important, because there are plenty of codebases out there that will never get rewritten into something else.