C++ for example, is a hard language, but the learning curve is ... progressive (rise bit by bit).
Rust on the other hand, is like climbing a cliff: You're exposed to everything as soon as you start learning. That's all the Rust things (memory safety model and borrow etc) plus the rest of the knowledge that you need to learn when you normally learning a language (std library & stuff).
Luckily though, Rust did many thing in later years made it a little bit easier to use and learn. Like the rewritten books and manual and in my opinion most importantly few twists to the language.
My biggest (maybe nothing in the big picture) complain about Rust now is maybe it's too community driven, which can sometime cause minor fragmentation.
As a personal developer, if I've already followed every best practice writing my code, then to be honest, after the code is finished, I'm not willing to rewrite my code just to make it dated or work again (I mean, I'll pay my time to do it, but my hate meter will rise). Currently, Rust cannot fully deliver that.
I think Rust need strong leaders to layout a clear and stable plan, so more things can be standardized across it's ecosystem (Somewhat like what Go did, for example, io.Reader && io.Writer is life changing for me). In that way I can keep my hate meter at a safe level.
Look at the Future trait, as an example. And rust has had the equivalent of io.{Reader, Writer} since 1.0.
In Go, `error` is an interface that can later be asserted, so I can return any `error` then deal with them as late as I need.
This gives me ability to write some complex `io.Reader` and `io.Writer`. For example, an `io.Reader` that can Decode data stream, and returns both CodecError and IoError when it encountered any.
In Rust, if I want to write a similar thing, a HPACK decoder that returns both `io::Error` and `HPACK::DecodeError` for example, I need come up with another `Result` type that wraps both errors. This can sometime be tiring and makes the code inflexible (As one simple change to the `Result` may effect the entire call chain up and down).
BUT ... Maybe it's Go's fault, it treats me too well, make me want something that I cannot have for free (performance cost) else where.
Well there's stuff like error-chain to take care of the boilerplate...
Also, I believe you could define the equivalent of Go error in Rust as a trait and box it (ie. a trait object). It could be used much the same way as in Go with the additional benefit of Result being a sum type. I'm personally not a big fan of this approach but I guess it might work...
I know this basically how Go's error handling works (Put error data on heap and pass the reference), but I'm not fan of it (the put data on heap part of it) too :(
I will try out the error-chain, thank you for reminding me that.
Just to add my opinion, not to disagree: I followed the development of Rust for several years now (starting before 1.0). Rust's approach to language evolution is very much community-driven (like you said). But this also led to many really good ideas coming from people with different backgrounds. Today, Rust feels like a highly optimized breed of good ideas taken from many programming languages and I know of no other language that feels like that. Sure, every new language gets inspiration from older languages, but Rust appears to be more "extreme" than other languages (and I do not mean "extreme" in a negative sense). This was most visible in the pre-1.0 era. People had different ideas how the language should work and the Rust team tried different things and iterated on the things they learned. And I think this was totally worthwhile.
Let's talk about Python for a moment. I really like Python. It is a language with clear conventions and idioms. And most likely it achieved this state thanks to Guido van Rossum who had very clear ideas about what the language should be. And one of the core ideas is simplicity. Python (being inspired by ABC) was meant to be easy to learn (because of it's simplicity).
Now, let's go back to Rust. Rust also has clear ideas: "Rust is a systems language pursuing the trifecta: safety, concurrency, and speed" (Quoted from: This Week in Rust). And yes, "consistency" or "ease of learning" are not listed as the core ideas. However, when you look at the Rust roadmap for 2017 you will also see that the team has prioritized the following items:
* Rust should have a lower learning curve
* productivity (which includes easier usage of the language)
These issues are definitely on the radar of the Rust team. But I also think that these issues can only be tackled by an entire community which shares and discusses ideas. Rust tries to be much more than other languages and I think it is highly unlikely that a single leader will know how to direct the language in a specific direction. There are still a lot of things to be figured out. For example, let's see if the failure crate becomes the standard for error handling in Rust.
Rust on the other hand, is like climbing a cliff </quote>
c++11+ is a hill that is so freaking high that you do not see the top.. like Olympus Mons.
honestly i do not see much difference in learning c++ or rust - in order to write good programs you should know most of the c++ standard and that's a lot to absorb.
Except that you've always got a footgun in each hand, with no safeties and no trigger guards.
Rust keeps its footguns locked in the gun safe. You get them out with the `unsafe` keyword.
I don't mean to burst your bubble here. But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way.
Looking at this thread there are plenty of examples of "I love Rust, but..." or "It's a great language once you get past...". My favorite: "There's an awesome web framework but you have to use Rust-nightly..."
Javascript is thought of as a terrible language by language snobs, and yet it has a huge following. Haskell, on the other hand, is much beloved, and doesn't. Don't get me wrong, it's got its share of love, but hasn't seen the explosive growth that python or java has.
The lesson from the early 2000's is that C++ may be a superior language to Java (I used to think that way), however people were so much more productive with Java. They didn't have to worry about memory management, segfaults, crazy C++ semantics, etc. Companies were more willing to throw hardware at a problem to reduce risk/time in development. And that is still true today.
You won't.
> But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way.
This is relative. Rust is far easier to learn than C++. It has a compiler that will even enforce that you don't shoot yourself in the foot. It also has nice tooling to get you up and running quickly. It has good documentation. It has a free book. We've had no trouble getting our new grads up and running with Rust. It's not that hard.
> Javascript is thought of as a terrible language by language snobs, and yet it has a huge following.
Having a huge following doesn't make it less terrible by the measures of PL theory or sensibility. It's also the only choice on the web, but that may soon change, Rust has first class support for wasm so it's in a good spot there.
> Haskell, on the other hand, is much beloved, and doesn't. Don't get me wrong, it's got its share of love, but hasn't seen the explosive growth that python or java has.
By most accounts the Haskell ecosystem and user base are quite large considering it is intended as a research language, and the community is still growing. Rust isn't intended for research, and it's incredibly young compared to Java or Python, so it has plenty of time to catch up.
> but people were so much more productive with Java.
Hahaha. You mean people wrote a lot of Java. Let's please make the distinction between productivity and writing a bunch of enterprise crapware churned out by barrelful.
> They didn't have to worry about memory management, segfaults, crazy C++ semantics, etc.
That's exactly what Rust does for you.
> Companies were more willing to throw hardware at a problem to reduce risk/time in development. And that is still true today.
Actually companies are becoming more aware that speed is a feature, and that Moore's law isn't holding out. We're also moving to smaller form factors: phones, watches, glasses... the future is not on the desktop by any means, and no one wants to waste capacity in a datacenter needlessly.
> Actually companies are becoming more aware that speed is a feature
No. If that were true, Python wouldn't be the fastest growing language, and we'd be hand optimizing everything in assembly and using languages that allowed us to do that (C). That was the entire point I was making. It's why Java won.
I can't figure out if Rust is serious about being a true competitor, or just merely riding the peak on the Gartner Hype Cycle [1].
[1] https://www.gartner.com/en/research/methodologies/gartner-hy...
I make the distinction between script and what we software engineers do, because I had the misfortune of spending half a decade in research doing ML, and those guys are not writing production programs. They're hacking out Jupyter notebooks and writing precariously balanced code that barely works.
That doesn't make Python suitable for large applications. It doesn't diminish the fact that CUDA is growing, SGX is growing, embedded is growing, that we're now unlocking 100G fiber, that we've reached the limits of single core performance, that intel is rolling out 8+ core consumer CPUs. Python is not going to shine for any of these things, but Rust will.
Don't tl;dr; if you don't know how to r.
All else being held equal, developers and stake holders will choose the faster language, it just makes sense.
The trick is that speed is typically seen as diametrically opposed to usability, since quite a few languages achieve speed by turning all the safety rails off or existing way too close to the metal for comfort.
If rust could deliver speed without compromising on ease or safety, and I honestly don’t know if it can, then it will absolutely crush the competition.
It has to be more than safe and fast. It has to be a productive language to use. A dev can't sit for 6 months trying to figure out how to write a website, when he can pick up RoR and do it in a day.
Though, reading the post above yours, I was thinking more about the use of data structures than the implementation of them. In C++, when faced by the need to efficiently iterate through a data structure in different, incompatible orders, the tool of choice is often just to make intrusive linked lists with multiple next pointers per element. I think I've even once implemented something that was a priority queue (heap), two different lists and a tree at a same time.
While doing that in Rust is by no means impossible, it seems to me that the use of such a structure would be much more clumsy in Rust, to the point where I would try hard to solve the problem in some different way.
The languages are all turing-compatible anyway, so it's not about what can be done, it's about what approaches does the language make easy and promote. Overall I really like the kind of code idiomatic Rust tends to end up like.
> The languages are all turing-compatible anyway, so it's not about what can be done, it's about what approaches does the language make easy and promote.
Turing completeness is kinda besides the point. We probably wouldn't be talking about it on HN if it wasn't. :)
I guess what I'm wondering is does Rust encourage simpler but possibly slower data structures, or are there some complex data structures which are simpler to ensure safety than other simpler ones?
In other words, does Rust encourage simplicity at the cost of speed?
I'm happy that rust has a good set of performant data structures, but on the other I feel like it's too soon to say Rust is the big winner here as the author does. I've been very skeptical on fantastical claims by language promoters.
But taking the pain out of making common data structures is a good start.
Rust is competing in the space of C and C++, it is not competing against Java or Python. People are not gong to write operating systems in Python because it feels more productive. For simpler desktop applications you may have a point, but heavyweights like Word or Photoshop are written in C++ and Rust may be a realistic migration. JavaScript or Python is not.
Especially we've gotten used to so many of C++ shortcomings that we don't see them, but someone learning both Rust and C++ will (I'm sure) have a better experience in Rust. Even just the built in tooling (Cargo test, Cargo crates, rustup, etc.) feels so much more mature than when you're in 2018 looking at how to compile some C++ without an IDE.
For Rust to win it must be adopted by Gaming or gaming engines.
Rust is really only competing with C/C++, not JavaScript or even Java (or Go).
Like C on embedded vs C++.
On Windows large majority of apps are in .NET with some C++.
On OS X and derived systems it is all about Objective-C and Swift for desktop apps. C++ is mostly used for drivers, LLVM tooling and Metal shaders.
Android is Java with some C++.
ChromeOS is all about JavaScript.
So no, C and C++ have lost the desktop, nowadays they are used for the graphics composition engine, while the remaining APIs are built on top of it with another set of languages.
If Rust is supposed to beat C and C++ on the desktop, it needs to be able to integrate into the IDE tooling alongside the mixed language tooling experience.
Sure, this is all a matter of 'using it right', but from my experience many developers in the commercial embedded space are not programmers by trade and this learning those intricacies is a real hurdle for them.
And for another point of view of someone more relevant than my insignificant self,
CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”
https://www.youtube.com/watch?v=D7Sd8A6_fYU
"Embedded Development with Dan Saks"
http://cppcast.com/2016/10/dan-saks/
Thankfully there are industry certification standards like AUTOSAR, which now require C++, so those devs can choose to keep grasping to C and switch industry or learn more modern languages.
There's actually a website dedicated to tracking this - http://arewegameyet.com/
I think to be on pair with C++, a Rust based engine needs to have some Unreal like tooling.
Which actually seems to be a couple of WIP on that website, so I will now get to track their progress. :)
So it would be interesting to see what Seed Studios will come up with.
Does it? Existing project use what they have chosen long time ago, we can only discuss choice for new ones. And new OSes often choose something else. I am not aware of any new webbrowser, so can't say anything about that.
Yes, I agree, but that's not the full picture. People want a language in which they can be productive quickly, but once they master it, they, or at least some of them, will then look into quality and performance. Languages like JavaScript or Python (and even Go to some extent) are popular and easy to pick up, but there's not much room for further progress. JavaScript is already stretched to its absolute limits when it comes to performance and it's still not performing very well. And when it comes to quality, well, TypeScript is a thing for a reason.
I don't believe Rust will ever be as much of a language for the masses as JS, but it has a good chance to become a niche language for those who need or want more performance and/or quality than they can get with langs like JS or Python.
My biggest gripe is that they left out readability.
I like the semantics of Rust, and appreciate the performance and the transparent memory model. I am extremely excited to try Rust on an embedded project.
Bur honestly, the syntax is gruesome. Coming from Python, Rust looks like two rabid gerbils had a war dance on my keyboard.
What exactly is terrible about it? The snake_case I got used to, I kind of like having braces, and that's not really a killer argument either, because most languages have them, apart from that I find Rust also much cleaner than Python syntax. I'm really not sure what you mean. Is it the lifetime annotations (because they're somewhat necessary).
fn accumulate<'a, T: Monoid>(tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> T
where
T: From<&'a str> + From<String>,
yes, every single thing in there is necessary, it can be written in a more gruesome way, but the where clause clarifies it a bit
But let me cheat a little bit
( $(#[$attr:meta])* enum $enumer:ident { $($i:ident => $e:tt $( ( $($m:ident),* ) )* ; )* } ) => {
On the second one you got me though, I find the macro syntax a bit horrible. Sometimes I just want simple text substitution.
I guess the signature could be made more readable by using a few type aliases. The hardest part to read is the nested types.
I'm with you on the macro syntax, it is very hard to read. It is not easy to create a readable macro syntax though. All languages I know have hard-to-read macros, so this is not yet a solved problem.
fn accumulate tuples: &[(&'a Str, &Fn(i32) -> Bool)], i: i32 -> t
where
t: Monoid + From &'a Str + From String,
It's also not realistically parseable- the Haskell/Ocaml-like removal of <>s and ()s relies on application being left-associative, and if you read this under that rule you've changed the meaning (e.g. `From &'a Str`).
for i in range(100000000):
...creates in memory a list with one-hundred million integers.
Expressive yes, but sometimes it can be double-edged for new comers (and not new comers).
Also, it makes autoindent in Emacs worse.
Here is the thing about indentation versus curly-braces-and-semi-colons: It boggles me that people find it acceptable to use one mechanism to communicate block structure to the compiler, and a completely different mechanism to communicate block structure to humans, and have no way to automatically check that they have the same semantics. This is a frequent source of bugs, and is entirely preventable. When it comes to the ergonomics of computer-convenient versus human-convenient, humans should win. Therefore, significant white space is clearly preferable simply from the standpoint of eliminating the source of an entire class of bugs.
But the main thing that makes Rust harder to read is all the punctuation noise and short, cryptic keywords. While one friend once said: "A good programmer can write FORTRAN in any language.", I don't feel compelled to help them.
Readability matters.
Strongly agree. The solution that Rust, Go and other new languages have adopted is shipping a formatting tool to consistently make the semantics of indentation and braces match. I personally can't help but think that this is a worse-is-better solution when compared to significant whitespace, but at least it works. Every Rust CI I am setting up will fail the build if `rustfmt --write-mode=diff` feels like you didn't run rustfmt before committing.
> But the main thing that makes Rust harder to read is all the punctuation noise
Given the decision to favor explicit casts, references and dereferences over implicit ones, this cannot really be helped. In some ways, once you get used to it, it helps readability, because it always communicates what the things being worked on are.
> and short, cryptic keywords.
I agree that this was probably a mistake. Cannot really be helped now, though.
Overall, I think the readability argument against Rust is overstated. Sure, when you are starting out it looks like line noise, especially if compared to python. But it didn't take me more than a week or two before it basically became entirely clear and readable. The radical explicitness of the language helps readability in many ways that make it much better than C++.
Of course, much better than C++ is a low bar to pass.
I still prefer whitespace to indicate blocks though.
Python is ugly and inconsistent as hell due to lack of methods (no maps or reduce in collections for example), indentation, lack of expressions (nearly everything is a statement) and one statement lambdas.
Though rust is beyond good and evil indeed, I really don't get this obsession with brackets and C-like abominations like &*staff. Ada or SML are doing a much better job.
Autoindent is a solution to a problem that doesn't exist in Python in the first place. Having two independent representations for blocks, one for human readers (indent) and one for compilers (braces), leads to nasty bugs when they get out of sync. Autoindent is a tool to keep them in sync. In Python there is a single representation, so nothing can get out of sync.
> If I have to have another argument about tabs vs. spaces I am going to toss my monitor out the frickin’ window.
Clearly the correct answer is spaces. /s
Seriously though, I like python because not only is it pretty, it's also concise. While it's not perfect, a lot of time has been spent on language features to make them easily comprehendable.
The lesson for me from python is that UX is important, even in programming languages.
I think it's funny how people still have issues with this in 2018.
DO I = 1.100
DOI = 1.1
http://catless.ncl.ac.uk/Risks/9.54.html#subj1 intmain()
{
r etu rn0;
}Languages like Java are more verbose which does make it a bit more frustrating to write but on the flip side I find them easier to read.
I ended up just using rails in api mode which is a shame because it chews up the limited memory on my server.
Most of these issues would go away if I was a rust pro and I could just write my own libraries and read the source but it really didn't feel like rust was helping me become productive fast like ruby did.
Rust crates should have documentation though. Rust has great tooling around writing docs in comments and generating the documentation from those. Rust is also statically typed, which makes it easier to reason about what a function does without the docs. In fact, lifetimes give you even more information about the relationship between inputs and outputs than a normal statically typed language.
JavaScript would like a word with you.
Every app I've ever written that talks to postgres spends way more time...waiting on postgres than doing anything else.
It's like the joke about getting a faster processor so you're 99% idle instead of 95% idle.
I find Rust to be fairly easy to reason about. The compiler has awesome messages, and even links you to your error type with more information. I also HIGHLY recommend reading the O'Reilly book AND the official Rust book (the free one) if you feel like you're "just not getting it".
Rust is a language that rewards understanding, and stops you from making mistakes when you don't know how things are actually working. This is a revolutionary plus. At the end of the day, Rust's rules are what other languages enforce through convention and the school of hard knocks.
After all, is that not the point of computing? To have the computer check things for you that a human is prone to error on?
For sure. The Rust community takes the cake when it comes to owning criticism, wanting to make things better (as opposed to excusing issues), and self-organizing to affect change (e.g., the working groups). I like Go and its community is well above average, but it stands to learn from Rust's community IMHO.
> the meetups have been really positive. They even have the #rust-beginners channel. :)
I know, but a slack/irc/email/etc channel is a really poor substitute for having humans in a room who already have context about the problem you're trying to solve.
> I find Rust to be fairly easy to reason about. The compiler has awesome messages, and even links you to your error type with more information. I also HIGHLY recommend reading the O'Reilly book AND the official Rust book (the free one) if you feel like you're "just not getting it".
Hard to make heads or tails of this without knowing what you're comparing it to. I do agree that Rust does a fantastic job (via its error messages, documentation, books, etc) at addressing the hard problem of dealing with a compiler that pedantically enforces not-very-intuitive invariants, and I respect Rust for believing that those invariants are worth the trouble. I think they _are_ for lots of applications, but I think Rust needs to do quite a lot on the learnability/intuitability front before the economics justify using Rust for general purpose application development. For the time being, for most applications, it's just so much _cheaper_ to use something like Go in the general case.
Didn't ocaml already answer that question? Since ocaml hasn't dominated, it seems something more is required... What has rust got beyond that?
--https://en.wikipedia.org/wiki/OCaml
Rust has memory-safe concurrency without a GC.
Programming languages like javascript or python always dynamically allocate every single object. When the GC does it's job it has to stop all threads and therefore will stop your time critical code even if you avoid allocating inside it. This is what is commonly understood as an unpredictable runtime model.
What does predictable allocations even mean? Allocation is always predictable, it will happen when you use "new" (Java), "Box::new"(Rust), malloc, etc. The unpredictable aspect is the stop the world pause caused by garbage collection. Your complaint regarding custom allocators doesn't make sense because arena allocators [0] and probably others are available in rust.
As well as malloc pauses on deallocation. The only way of using your memory in realtime apps is preallocation, which often can be done in languages with GC too, it would be just very inconvenient.
At the moment custom allocation support in rust is a joke if you compare it with Ada or C++, and Box is not better than GC in this regard.
>Unstable
Besides it's very inconvenient to use. Does Box/Rc/Arc support this arena allocator, as C++'s smart_pointers do?
The 'small, easy language for ignorant developers' niche certainly exists, but it's already taken by Go.
Rust currently provides no benefit over (modern) C++ for the problems where using Rust or C++ makes sense. (Though perhaps Rust will make it easier for layman developers to learn Rust and then transition to C++.)
I'm even more perplexed by "Rust currently provides no benefit over (modern) C++."
* Rust's "pthreads and mutexes" wrappers prevent data races at compile time, and there's Rayon to compete with things like OpenMP.
* Rust's moves are destructive, guaranteed nothrow, and also checked at compile time.
* Rust's borrow checker is light years ahead of C++'s.
* Rust's type system lends itself to far simpler generic code, with trait-based generics and sum types instead of concepts and std::variant.
* Rust's iterators are much better than C++'s, to the point that Ranges is one of the most highly-anticipated additions to C++.
All of these are things C++ is actively trying to improve, so clearly at least the committee agrees they're worthwhile features.
Rust has some nice features for handling ownership semantics, but they are not significantly better than those in C++.
Meanwhile, Rust still lacks a normal exception handling story. Exception handling is absolutely necessary in 2018 for building real software systems.
(And even though Rust claims that errors are nicely dichotomized into "recoverable" and "not recoverable" camps, this is simply not true in the real world. There are obvious counterexamples that don't fit into this dichotomy.)
As I understand it, the primary usage of both is to report, and handle, errors. Rust splits it as panic! and Result<>, where panic! is naturally left for logic errors (ie states the program should never reach, regardless of circumstance; maintaining invariants), and Result<> is for everything else.
Exceptions do the same, but you can catch the broken-invariant case as well? I'm not sure how often you want to recover from such a state though.
Another aspect is retrieving the stack-trace, which iirc doesn’t exist in a normal result-type, but error-chain! magically handles it for my case (never looked into how, or at what cost)
Otherwise, the other major difference is that rust enforces that you explicitly handle all result types, making it part of the API contract, while most languages, with unchecked exceptions, leave it as a new runtime error to be found after updating your libraries. Java gives you checked exceptions, but in a much more syntax-unpleasant fashion (but thats always the case with java).
As far as I'm aware, Result<> seems to me a much cleaner solution than exceptions for the same use-case. A bit of concern for API updating, since the errors are part of the API so its more difficult, but at the same time, I'd rather update the library and fix the codebase, than update and wonder if a new Exception exists (or perhaps, always existed? Is there any way to find out the list of possible exceptions in C++, without reading the function, and all the code it depends on?).
The primary unpleasantness is that a single use of Result<> infects the entire callgraph until its handled, but thats true with exceptions as well. I'm not too happy about async/await for the same reason
Of course, part of the reason I'm interested in using rust as my hobby-language is because I'm absolutely sick of runtime errors and writing worthless tests in python, so maybe there's an appeal thats missing for me
Pretty much always in real systems software.
Imagine a multithreaded server that handles HTTP requests. A catastrophic invariant failure when handling one requests shouldn't bring down the whole server.
Or imagine an application that calls into a money transaction routine. (This routine can itself call other routines, and so on for 12 stack frames deep.) A catastrophic failure in sending money shouldn't bring down the whole app, it should show a clean "money transfer failed, please try again" message.
Essentially where you'd have asserts() in C. eg Your in-place sort function is meant to maintain a sorted list for all elements traversed so far: you add a panic check to guarantee this. It fails; the invariant is broken, and there's no recovering from such a state (your sort is not sorting! you're going to add a handler for this..?).
A web-request failing is a simple, normal, expected failure (hence the Result<> type). Adding 1+1 and getting 3 is a broken invariant, and there's no coming back from it. Again, you can (probably) catch it in Java since it throws exceptions on anything and everything... but why would you want to? If you take its to its conclusion, you're not trusting any aspect of the language anymore: you'll have to check every bit of code for arbitrary outcomes.
It seems to me similar to javascript allowing you to basically pass in anything to everything and get ...some... output, but its an extremely bug-prone methodology.
panic! is, afaik, intended for those situations where it should bring down the whole application (before you start adding $3 to person A, but subtracting $2 from person B); primarily to catch programmer errors, not execution errors. Errors that can be recovered from are Result<>, and the Result<> type forces you to handle all possible outcomes (which the caller might decide is a panic!). A failed web-request is most certainly a Result<> in this model, not a panic!.
Given that Rust doesn't actually solve any of the actual problems C++ programmers have, there is no motivation to switch.
- sending dangling references to thread functions. Lambdas with automatic reference capture creating threads from inside functions that exit are terrible here.
- returning a pointer or reference to an invalidated iterator
- returning a pointer or reference to the contents of a temporary
Yes indeed, C++ programmers never actually have these problems, they are purely imaginary. /sarc
> Why on earth would an organisation move their codebase to Rust when they can just run Clang? Well, you can ask C++ professional at Mozilla.
#include <iostream>
#include <string>
#include <string_view>
int main() {
std::string s = "Hellooooooooooooooo ";
std::string_view sv = s + "World\n";
std::cout << sv;
}
C++'s type classes are concepts, which are hardly more than syntactic sugar over SFINAE.
Neither can really compare to Rust's enums or traits.
We've also found that the learning curve is, in our opinion, a bit overstated. We've ramped up several new grads on Rust with the O'Reilly Rust book. We see real productivity in about two weeks, which is actually faster than it was to ramp them up on our C++ code base. The compiler errors are amazing and it's almost like giving them a built in tutor.
I'm very bullish on Rust becoming the language of choice in the 2020s for everything from operating systems, web services, desktop applications, and more. It's that good.