Rust was released in 2015, it's merely one and a half years old, while Go was released in March 2012.
If you count the inception period of Rust (pre-1.0) you should also count Ken Thompson's and Rob Pike's work at plan9, which doesn't make more sense …
Fun fact: Go's first commit is 44 years old [1] ;)
[1] https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfae...
I agree that they had very different priorities in beginning and it changes with time. My goal was to merely point out core rust people in Mozilla and elsewhere now recognize that industry usage is an area of high importance in coming months/years in contrast to purely technical concerns of past.
Has Rust actually settled down on some stability?
>> Currently Rust is about Go's age but nowhere close in usage.
Rust sits in a very useful niche not served by other languages, and in steady state will probably be more popular than Go.
Go has a very well designed ecosystem. I like it, use it, and am very impressed with everything about it I have seen. However, I don't see use cases that Go serves vastly better than other available alternatives.
Rust is a powerful language, but with that power comes the ability to write "fancy" code -- esoteric, unreadable, and unmaintainable.
Citation? I see a lot of people talking about both, but not very many public projects in either. Rust at least has a "killer app" on the way in the form of Servo, whereas I haven't heard of any user-facing programs in Go.
http://www.tiobe.com/tiobe-index/
A Github search turned up 2,658 Go repositories with more than 100 stars:
https://github.com/search?l=go&q=stars%3A%3E100&type=Reposit...
compared to 348 Rust repositories:
https://github.com/search?l=rust&q=stars%3A%3E100&type=Repos...
Notably, Docker has more stars than Go itself.
Edit: you may also be interested in IEEE Spectrum's interactive list of the top programming languages:
http://spectrum.ieee.org/static/interactive-the-top-programm...
With the default parameters, Go and Rust are 10 and 26, respectively.
Rust: https://www.rust-lang.org/en-US/friends.html
Without counting Go usage roughly looks 10 times more than Rust.
I don't. It's a measure of the overall success. Design is but a small part of that. Community, outreach, corporate back up… play a huge part in the success of a language.
Go is a wonderful example: doesn't even provide parametric polymorphism (generics), and they got away with that! Feels like Google backup matters more than the core language here. Either that, or someone please explain why omitting generics today is not a big mistake. Feels like dynamic scope all over again.
Though Dart has generics but not much usage in industry.
Only because one can opt-out of the type system and use a catch all "interface {}" .Actually even the std lib does that ... a lot.
C (and later C++) became popular because Unix was successful. Safe systems programming and safe browsers are nice to have but not completely safe if the underlying OS is unsafe (Windows in particular). Rust's "killer app" would be a safe OS. The first attempt (Redox) is already there.
I was looking through the pointer safety portion of the safety brochure: https://doc.rust-lang.org/book/unsafe.html#what-does-safe-me... and wondering how to approach unwrapping an ethernet packet on the wire in the easy unsigned pointer-specific way it can be done in C and came across a pcap implementation in Rust (sample source): https://github.com/ebfull/pcap/blob/master/src/raw.rs Are you serious? Rust is not for me, thanks.
In my opinion Rust is about doing things right. It may have been about safety at first but I think it is more than that given the work of the community.
Yes I know there is the right tool for the right job and is impossible to fill all use cases but IMO Rust is striving for iPhone like usage.
I have never seen a more disciplined and balanced community approach to creating PL. Everything seems to be carefully thought out and iterated on. There is a lot to be said to this (although ironically I suppose one could call that safe)!
PL is more than the language. It is works, community and mindshare.
If Rust was so concerned with safety I don't think much work would be done on making it so consumable for all with continuous improvements of compiler error messages, easier syntax and improved documentation.
Rust is one of the first languages in a long time that makes you think different.
If it is just safety... safety is one overloaded word.
The importance of Rust is that it's raised the baseline for low-level languages in the modern age. If any future systems languages emerge that don't feature memory safety, it will have to be a deliberate choice that must be defended rather than just an implicit assumption of how the world works.
With that said, can you recommend a good source to really understand best practices and patterns for ownership and borrowing? I feel that's the biggest hurdle to using Rust (at least in my case).
If you look at Rust from a systems programmer perspective and compare it with the systems languages OP lists then, yes, safety is THE most radical feature.
But Rust can compete on so many more levels. Web services, user facing applications for example. Languages competing in that space usually bring memory safety, so it's kind of a non-issue. Safety enables Rust to be a viable choice for these tasks, but it needs more than that to be on-par with the other languages. And Rust's got plenty of things going for it, so there's nothing wrong with stopping to play the safety card (since that is expected anyways) and painting Rust as a language that is actually fun to work with.
How ? There are languages with more expressive type systems high level type systems (Haskel/OCaml presumably). There are languages with much more mature libraries, ecosystems and tooling (C#/Java). There are languages with both (F#/Scala).
What is it that makes Rust a good applications programming language ? You said it your self GC doesn't really matter that much in this space and GC based languages are just more elegant and not to mention the tooling is way more mature. Runtime also doesn't matter that much and with the recent changes to .NET can be avoided anyway.
This Rust fanboyism is turning in to the new node hype "use node for everything node is web scale fast because it uses an event loop io instead of thread based io", "use rust for everything because the type safety is literally the best and it's the only language with a strong type system out there". I get it it's new and shiny, I like it to, and it has a strong argument to make in the systems programming - the designers are doing a good job of making trade offs that let you retain low level control while still having memory safety - but these tradeoffs are just that and they come at the expense of higher level stuff, higher level languages don't need to make these because they don't pretend to be systems programming languages.
I actually wish rust would accept its systems niche even more and move the stdlib to crates and make nostd the default mode. Personally, I see no reason to market rust for webapps or gui stuff, it cant/wont compete with Rails/QT for years to come if ever there.
On the other hand there is a quite dark cloud on the horizon with the stable vs nightly split. You can't run infrastructure on nightly builds; or add nightly builds to distributions.
Rocket is a recent one. I talked with the owner of Rocket and one of their goals was to help push the boundaries of Rust by playing with the nightly features. With that sort of meta-goal using nightly is sort of a prerequisite. Meh.
You can use almost all of the code generation libs on stable via a build script. Tiny bit more annoying, but if it's a dependency nobody cares. A common pattern is to use nightly for local development (so you get clippy and nicer autocompletion) and make the library still work on stable via syntex so when used as a dependency it just works.
The most used part of the code generation stuff will stabilize in 1.15 so it's mostly not even a problem.
The looming dark cloud of stable vs. nightly only looks like a dark cloud to those outside the Rust community.
The article that made its way up Hacker News awhile ago (https://news.ycombinator.com/item?id=13251729) got pretty much no traction whatsoever in the Rust community.
In 2017 we'll get Tokio and lots of Tokio-ready libraries. Some of them already work and compile with stable Rust. And maybe in the end of the year we can take a proper look what we can do with Rocket, or Diesel...
That said, if you want to play with nightly Rust, it's pretty trivial. Rustup https://www.rustup.rs/ makes it easy to install multiple Rust toolchains and switch between them, in a fashion similar to rvm and rbenv.
rustup run nightly cargo build --release
You were saying? In any case, there's no such thing as a stable vs nightly split. There's pretty much zero libraries that require nightly, and the few that have a nightly option for optional features will no longer require nightly after the macros update lands.
So I guess, it would be better to say that Rust is about decreasing unsafetyness or whatever the correct word for that is.
edit: since I see posts about Go, this is evidently another approach toward decreasing unsafetyness by providing fewer and easier to understand primitives so that the programming logic is harder to write wrong. It might come at a moderate cost for some applications.
There is a trade-off between safety and expressiveness. Clearly you can always shoot yourself in the foot if your language is expressive enough (like any Turing-complete language).
But I think that is beside the point here. This is about eliminating whole classes of errors.
A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs.
A good memory model can eliminate all unsafe memory problems.
There are also languages that can eliminate all data races from your programs.
All these advances in PL theory make it easier and safer to deal with hard problems like concurrency, memory management etc. and thus allow us to focus on what our programs can actually do.
It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language.
Especially since the systems we use are often dynamic with changing requirements.
Do you consider silently trimming value during mandatory explicit type conversion a type error?
This is a common misunderstanding of being Turing complete. A program running in an interpreter isn't unsafe just because the programming language and the interpreter are Turing complete. Being Turing complete doesn't mean being able to gain root access, overwrite the boot block, scribble on the hard drive, etc.
It depends what you call a "type error". Is calling `car` on a `nil` instead of a `cons` a type error?
Like this "safe concurrency" claim sounds really fearless to me, even though I know they mean some guarantees towards thread safety and all that, not actual safe concurrency.
I think the word you're looking for is "safety". Safety is inherently relative and mostly about risk management. There's no such thing as 100% safe by definition.
As you consider higher (application) level notions of safety, it generally becomes less practical to achieve that safety statically (at compile-time), so you'd want your language or your framework or whatever to facilitate the implementation and performance optimization of dynamic (run-time) safety. At the moment I'm thinking about automatic injection of run-time asserts (of application level invariants) at appropriate places in the code. (At the start and maybe at the end of public member functions for example.)
If you subscribe to this idea, then it sort of follows that Rust's borrow checker may be "in the wrong place". That is, rather than forcing you to write code that is memory safe in a particular statically verifiable way, Rust could have instead enforced memory safety by injecting run-time checks into the code and optimizing them out when it recognizes code that appeases the borrow checker. (Of course the optimizer could report what run-time checks it was not able to optimize out, if you wanted to self-impose static verification.)
(Statically optimized) dynamic safety is more scalable than statically verified safety. As a "systems language", Rust may be less concerned with higher/application level safety. But I think this might be a little short-sighted. The definition of "system" is expanding, and the proportion of "higher level" safety concerns along with it.
That kind of lack of transparency about what in the hell your code is doing at runtime is really inappropriate in a system's language.
It's an interesting idea, and it would be neat to play with in a language that wanted to restrict itself to more business-logic level safety concerns, but it would absolutely come at the cost of not being appropriate for systems-level tasks.
It's simple (only the two tiers), but it is another tool for abstraction and managing complexity.
I have no doubt that people have had their lives ruined, or even died, as the result of flaws in system programming, but is anyone actually tracking this? Is it "countless?"
"What have you done? That vase was priceless!"
"Oh good, I was afraid it was expensive."
Rust: "If you're not doing this, you're a murderer."
I'm a huge fan of thorough designs, engineering formalities and quantifying application performance, but if we're building some fast food ordering app is expected to increase sales by 10 percent as soon as it's done and there's no risk from quality or availability or performance of the application (other than the 10 percent extra sales, we expect people to walk in / drive thru like normal if it under-performs on those metrics) then it's obvious the business value is in launching a minimal implementation as soon as possible using tools that optimize for productivity, not safety or performance.
Too often I see dogmatic pure functional TDD line of business app with continuous deployment infrastructure that could break for two weeks at a time without impacting anyone, or the copy-pasted-code-from-google-searches business-critical application that loses money for every hour it's offline but has no software development lifecycle or monitoring or alerting or anything.
But in all seriousness, I am curious about this as well.
In my CS program we had an ethics class that included stories of bad X-ray machine software that overdosed people. Bad, bad bad. I don't think many people died as a direct result, but 10 years later there was probably a spiked cancer incidence. Did software kill people? Well yeah....kinda.
In airplane systems, there have been a number of cases where bad alerting / warning systems basically either misled the pilot or lulled them into a false sense of security prior to events that caused crashes. Did software kill people? Uhm, yes, I think, sort of, but not directly?
It's only when we get fully sentient AI that arms itself and decides to clean up the human pestilence that we'll be able to draw a straight line there. :)
I think realistically we need to ask: would it be a better situation if no system program were allowed for lack of safety. Because I think humanity in general is better with existence of unsafe software vs no software exist at all unless it is safe as per rigorous safety standards.
I think the core of it is this:
> Safety in the systems space is Rust's raison d'être. Especially safe concurrency (or as Aaron put it, fearless concurrency). I do not know how else to put it.
But you just did! That is, I think "fearless concurrency" is a better pitch for Rust than "memory safety." The former is "Hey, you know that thing that's really hard for you? Rust makes it easy." The latter is, as Dave[1] says, "eat your vegetables."
I'm not advocating that Rust lose its focus on safety from an implementation perspective. What I am saying is that the abstract notation of "safety" isn't compelling to a lot of people. So, if we want to make the industry more safe by bringing Rust to them, we have to find a way to make Rust compelling to those people.
What's the difference? Both of the statements have the premise that Rust is – and ought to be – a safe systems programming language. However, the latter captures not only the REAL goal, but also the nuances and tensions: while safety is indispensable, we must do something else too, for the programming society to accept the safe tools we are trying to promote. That means ergonomics, that means performance, that means ease of use, that means wide availability – and that might also mean advocation of visions of a better world, which is what this blog post of Graydon's does.
> The mission of the Python Software Foundation is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers.
"Facilitate the growth" does not imply that dominance of a certain practice (whether that is use of Python, or adoption of its core principals) is a goal. So you have an incentive for the PSF to say "our international community is growing at a sufficient rate" and focus instead on "advancing the language," which may or may not be aligned with adoption. In such a framework, it becomes easy to justify backwards-incompatible major releases that, regardless of whether their opinion is justified, many users consider to be user-hostile. Framing Rust towards a larger mission that implies user adoption of core principals as a fundamental goal seems much cleaner in that regard, and could conceivably avoid similar pitfalls.
I'm all up for a marketing shift though. I agree Rust is much more than safety and I think graydon2 missed your point there. The fireflower simile is excellent. Plus I've seen lots of people confused about Rust, including here on HN. Those are the people to whom marketing failed and should be targeted better.
I would go a step further, "fearless programming". Though I would hesitate on 'easy'.
Rust gives you fearlessness in all the things, but it does mean learning new style and discovering new solutions to old problems. To fully understand 'Send' vs. 'Sync', for example, means really groking the Rust type system. Once you get the type system, then fully utilizing it with the expressive generics becomes unlocked, and then at that point you've transcended from Rust dabbler to fully fearless Rust user.
Once this world of development is unlocked to you it is mind-blowing, but it is a journey to get there, and not everyone will have the heart to make it. It comes in stages, is wonderfully rewarding, will make you a better programmer in you other favorite languages, but I think we should be careful with statements like 'Rust makes it easy'.
It does make hard things easy, but only after you've fully embraced Rust. This feels more accurate: "Hey, you know that thing that's really hard for you? Rust makes it fun."
Rust is cool enough that it doesn't need to be promoted with excess hype.
If it was just safe and not C/C++, it would be another Ada, Modula-2, D, etc. It's important to market all the key benefits of it in a way that lets potential users know it will help them solve problems faster and with less trouble down the road.
So you might occasionally see the unsafe package being used to deallocate memory, even though there are better ways to do it, e.g. controlled types.
The other point, is that Rust prevents data races via the type system, while you can deadlock Ada tasks if the monitors aren't properly implemented.
It's not clear to me if you're suggesting otherwise, but you can definitely deadlock Rust as well (although it's true that Rust statically prevents data races).
Ada side is producing a new model for parallel and concurrent programming called ParaSail:
http://www.embedded.com/design/programming-languages-and-too...
http://www.math.umn.edu/~arnold/disasters/ariane.html
Although that was not a failure of language safety, but an overflow issue. The software was designed successfully for another rocket, and was reused for a rocket that didn't match the original specification.
1) No manual memory management, everything is static and you have memory safety
2) Garbage collection, you have memory safety
3) Manual memory management, you lose memory safety
Rust provides memory safety in the case of manual memory management.
Ada provides more ways to automate memory management, though.
Controlled types are Ada's version of RAII, used for arenas and smart pointers.
Also in Ada you can dynamically allocate everywhere, so a common pattern is to use a subroutine parameter to do stack allocation. If it fails, by throwing an exception, recall the subroutine with a smaller size.
(I guess in this analogy C is a parachute that you have to open manually, while Rust is a parachute that always opens at exactly the right altitude, but isn't any heavier than a normal parachute.)
For example, if I have a big string, I may create a hashmap where both keys and values are references to some portions to that original string.
Then, I may pass this hashmap to another function that will transform this hashmap into structs that contain reused portions of those string references.
Rust compiler will make sure that the original string is not destroyed or moved in any way in memory while this is happening.
While it is certainly possible to do this in C and C++, the development cost there is way higher. In C++, one would be sensible to stick to a slower version that copies and allocates data, unless he/she is really sure that the need for performance justifies the code complication.
Meanwhile, juggling the references this way in Rust is common and almost sloppy: the hashmap contains references to strings because it was probably created from iterator that iterated over references. The developer might not even need to notice it unless the string reference in result might be kept around longer than original. The compiler will tell about the type mismatch, and the developer will then create a new string from the reference, and then he/she will move on.
There is a similar story when such code needs to be refactored. The word "sloppy" still works here, but in a good way: offloading "being very, very careful" stuff to compiler is deliciously fun.
I like to say that Rust lets you toe the line perfectly, and dance near it as much as you want. C++ does not, since you're afraid you may accidentally cross it.
I think the safety aspect of Rust appeals to a lot of beginning programmers. They can feel safer looking down their nose at us dangerous C or C++ programmers.
> Rust is a parachute that always opens at exactly the right altitude
This isn't a good metaphor. Frequently it's safer to pull higher, and on some occasions, you're safer opening lower than you had planned... I think a canopy that always opened at the prescribed height would cause many unnecessary deaths. That doesn't say anything about Rust, one way or the other.
Maybe, but it also appeals a lot to many of us experienced programmers who know how hard things can bite us. It's not so much that we can't get things right. It's that it's really expensive to revisit old assumptions when circumstances change, and it's phenomenal to be able to document more of these in a machine-checked way.
I still think the point is valid, though, even if the analogy isn't.
Is that a bad thing? All programmers start as beginners, and if C is too painful to begin with then they'll learn via an easier language, and then comfortably spend their whole careers using those easier languages. If we want to expand the field of systems programmers organically, then we need to make tools that don't punish beginning programmers.
> They can feel safer looking down their nose at us dangerous C or C++ programmers.
What makes you feel like anyone's looking down their noses at you? Every language in history has been made to address the perceived flaws of some prior language. Safety is a crucial selling point for a huge chunk of people, and C and C++ have failed to appeal to this market. Just because safety isn't a priority for you doesn't mean that the people for whom it is a priority are suddenly pretentious.
Rust can make such an important contribution to such an important slice of the software world, that I really fear that trying to make a better pitch and get as many adopters as quickly as possible might create a community that would pull Rust in directions that would make it less useful, not more.
Current C/C++ developers really do need more safety. They don't need a more pleasant language. Non C/C++ developers don't really need a language with no GC. Now, by "don't need" I absolutely don't mean "won't benefit from". But one of the things we can learn from James Gosling about language design is, don't focus on features that are useful; don't even focus on features that are very useful; focus on features that are absolutely indispensable... and compromise on all the rest. The people behind Java were mostly Lispers, but they came to the conclusion that what the industry really, really needs, is garbage collection and good dynamic linking and that those have a bigger impact than clever language design, so they put all that in the VM and wrapped it in a language that they made as familiar and as non-threatening as possible, which even meant adopting features from C/C++ that they knew were wrong (fall-through in switch/case, automatic numeric widening), all so they could lower the language adoption cost, and sell people the really revolutionary stuff in the VM. Gosling said, "we sold them a wolf in sheep's clothing". I would recommend watching the first ~25 minutes of this talk[1] to anyone who's interested in marketing and maintaining a programming language.
If Rust would only win over 10% of C/C++ programmers who today understand the need for safety, say, in the next 5-10 years, that would make it the highest-impact, most important language of the past two decades. In that area of the software world change is very, very slow, and you must be patient, but that's where Rust could make the biggest difference because that's where its safety is indispensable. A few articles on Rust in some ancient trade journals that you thought nobody reads because those who do aren't on Twitter and aren't in your circle may do you more good than a vigorous discussion on Reddit or the front page of HN. Even the organizational structure in organizations that need Rust looks very different from the one in companies that are better represented on Reddit/HN, so you may need to market to a different kind of people. So please, be patient and focus your marketing on those that really need Rust, not on those outside that group you think you can win over most quickly because they move at a faster pace.
The number of C++ developers griping in HN threads about language-level problems effecting their work tends to disagree. It's not as if they wanted C++ to be designed that way. It was just only one with big companies' support that had zero-cost abstractions for programming in the large & great compatibility with C libraries. Many would love a better language. Matter of fact, they tell us in Rust threads here.
" Non C/C++ developers don't really need a language with no GC."
They might benefit if the app is aiming for max performance (esp HPC), memory efficiency (eg embedded), or minimal latency (eg real-time. From there, they basically choose among C, Objective-C, C++, or Fortran. Rust has features superior to those in terms of safety & abstractions. On HPC side, Julia is already showing the kind of takeup a language can get if it's faster than Python/NumPy but not C or Fortran.
"if Rust would only win over 10% of C/C++ programmers who today understand the need for safety, say, in the next 5-10 years, that would make it the highest-impact, most important language of the past two decades."
I agree. Let's hope it happens. With that on the demand side, we'd also see tools like Frama-C, Saturn, Astree, and so on start popping up for the unsafe part of Rust. On top of a shitload of libraries doing things the safer way since community encourages it. It's really the network effects that matter in programming languages. I think Rust might have good, network effects if it takes off.
Absolutely, but my emphasis was on the difference between "love" or "want", and "need". Switching a programming language is extremely expensive, doubly so in systems programming. Organizations won't pay the price for something that doesn't make a big impact. Unlike many other new languages, Rust does have the potential to make a big, bottom-line impact, but that impact is almost entirely due to safety.
> They might benefit if the app is aiming for max performance (esp HPC), memory efficiency (eg embedded), or minimal latency
I don't think max performance is an issue at all, nor even minimal latency where you need it (there are realtime GCs, and GC languages do support arena GC allocation in embedded and realtime settings, like realtime Java), but definitely it's a big gain in memory efficiency.
But again, I said they could benefit. It's just that the main focus shouldn't be on those that would benefit, but on those for whom the language is indispensable, or tremendously beneficial.
> I think Rust might have good, network effects if it takes off.
Absolutely, it's just that if you want Rust to really have an impact rather than just be popular, you need that network effect to be in the right network, and for systems programming, that network is not well represented on HN and Reddit. While these venues are good for marketing, and while the message will get to some of the most important crowd, it may have a negative effect as it would attract many that don't really need Rust, and if they end up making up most of the community, they may slowly push the language in directions that may make it less appealing to those who really need it.
When choosing languages people look at community, libraries, existing in-house expertise and availability of programmers. All these require popularity.
Just hear the pain: https://news.ycombinator.com/item?id=13276351
And some of them are watching you with great interest.
Any time your code takes in untrusted input, it should not be written in an unsafe language.
(Early in my career, I spent four years doing maintenance programming for a mainframe OS. Every time a machine crashed, taking a few hundred users off line for several minutes, I got a crash dump, which I had to analyze and fix. Most of the errors were pointer problems in assembly code. When Pascal came out, I thought we were past that. Then came C. I had hope for SafeMesa, but nobody outside PARC used it. I had hope for Modula I/II/III, but DEC went under. I had hope for Ada, but it was considered a complex language back then. Rust finally offers a way out of this hole. Don't fuck up this chance.)
For me, safety is the killer feature in Rust. It's also exciting because it brings systems level programming to a new generation of programmers without all the risk.
So basically just about all programs, all of the time?
> Any time your code takes in untrusted input, it should not be written in an unsafe language.
Not just that, but my theory is that untrusted input should only be stored in data types specifically designed for untrusted input [2], and should undergo safety/sanity checks during conversion to more high-performance types. For example, a general rule might be that untrusted integer inputs may only be converted to (high-performance) native integers if their value is less than the square root of the max integer value.
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
[2] https://github.com/duneroadrunner/SaferCPlusPlus#quarantined...
Nice to see these languages on Rust's team radar, specially Sather.
Just shows how you guys have researched prior work, congratulations.
Depending on what you define as system programming OCaml also has the whole bare metal Mirage OS [1] thing as well.
And of course OCaml is a pretty darn safe language (albeit its threading/concurrency libraries are fragmented so the safety is more type safety than concurrency).
[1]: https://mirage.io/
All the languages on my snippet also have GC, but are less known than OCaml, maybe hence why he omitted it.
http://www.embedded.com/design/other/4375616/ParaSail--Less-...
If you look at Rust from C then the point is safety, but if you look at it from the other direction, e.g from F# then what attracts you is that you will get the same safety guarantees (and perhaps a few more) but without the GC and heap overhead.
As a big rust fan, I wouldn't go that far. You can offload a lot more work to the type system in a language like F# or Haskell. Rust is very safe from e.g. a memory perspective (excepting unsafe operations), but there are additional levels of assurance you can get by aggressively forcing the type system to catch logic errors for you that you can't really do in Rust.
As for performance, I agree, although a more accurate description would be that it's much easier to get C-level performance with Rust code while you have to put in some more effort to get it in any high-level functional language.
And the perf will surpass C in some situations due to abstraction. One popular open source platform spends 30% CPU time on malloc and strcpy because tracking ownership was so difficult and it wasn't obvious it'd be a hotspot. In Rust that would be a non issue from beginning.
If you're a Java programmer, Rust is mostly about tighter resource usage.
If you're a Python programmer, Rust is mostly about type safety and speed.
;)
Most of the C that I do these days is Arm Cortex-Mx work. Realtime cooperative multi-tasking using an RTOS on the bare metal. It seems like Rust would be a great option for that kind of work if the low-level ecosystem were complete enough.
Some osdev stuff still needs nightly, but there's been really great movement on tooling, with stuff like xargo, and https://github.com/rust-embedded/ is a group of people trying to work towards improving things generally by identifying common needs, etc.
What did he mean by this?
Edit: "merely", relatively to Rust :) on an absolute scale, still way better than C for concurrency.
1) Memory safety is or should be a top priority for all software everywhere. The OP goes so far as to state: "When someone says they "don't have safety problems" in C++, I am astonished: a statement that must be made in ignorance, if not outright negligence."
This is borderline offensive nonsense. There are plenty of areas in software design where memory safety is either a peripheral concern or wholly irrelevant - numerical simulations (where crashes are preferable to recoverable errors and performance is the chief concern), games and other examples abound. It's perfectly true that memory safety issues have plagued security software, low level system utilities and other software, it's true that Rust offers a promising approach to tackle many of these issues at compile time and that this is an important and likely underappreciated advantage for many usecases. There's no need to resort to blatant hyperbole and accusations of negligence against those who find C++ and other languages perfectly adequate for their needs and don't see memory safety as the overriding priority everywhere. Resorting to such tactics isn't just a bad PR move, it actively prevents people from noticing the very real and interesting technical properties that Rust has that have little to do with memory safety.
2) Rust is just as fast or faster than C++.
Rust is certainly much closer to C++ in performance than to most higher level interpreted languages for most usecases and is often (perhaps even usually) fast enough. Leave it at that. From the point of view of high performance programming, Rust isn't anywhere close to C++ for CPU-bound numerical work. For instance, it does not do tail call optimizations, has no support for explicit vectorization (I understand that's forthcoming), no equivalent to -ffast-math (thereby limiting automatic vectorization, use of FMA instructions in all but the most trivial cases, etc.), no support for custom allocators and so on. I'm also not sure if it's possible to do the equivalent of an OpenMP parallel-for on an array without extra runtime overhead (compared to C/C++) without resorting to unsafe code, perhaps someone can correct me if it's doable.
Over the past week or so, motivated largely by a number of more insightful comments here on HN from the Rust userbase, I've tried out Rust for the first time, and found it to be quite an interesting language. The traits system faciliates simple, modular design and makes it easy to do static dispatch without resorting to CRTP-like syntactic drudgery. The algebraic/variant types open up design patterns I hadn't seriously considered before in the context of performance-sensitive code (variant types feature in other languages, but are usually expensive or limited in other ways). The tooling is genuinely excellent (albeit very opinionated) and easily comparable to the best alternatives in other languages. I'm not yet sure if I have an immediate use for Rust in my own projects (due to the performance issues listed above and easier, higher level alternatives in cases where performance is irrelevant), but I will be closely following the development of Rust and it's definitely on my shortlist of languages to return to in the future.
However, I would have never discovered any of this had I not objected to the usual "memory/thread safety" story in a previous HN discussion and received a number of insightful comments in return. I think focusing on the safety rationale alone and reiterating the two hyperbolized misconceptions I listed above does a real disservice to the growth of a very promising language. I think Steve Klabnik's blog post to which the OP responds is a real step in the right direction and I hope the community takes it seriously. Personally, I know a few programmers who've entirely ignored Rust due to the existing perception ("it's about memory safety and nothing else") and in the future I'll suggest Rust as worthy of a serious look as an interesting alternative to the prevailing C++-style designs. I'm certainly glad I tried it.
1) Tail call optimizations are fine, the documentation is just a bit ambiguous on the matter.
2) Explicit vectorization is available in nightly.
3) The equivalent of -ffast-math is technically available, though very inconvenient to use. There may be workarounds, I'm not sure.
These points, coupled with the ability to do performant threading (in theory, even with the syntax I'd prefer), go a long way to alleviating some of my performance concerns. Well written (nightly) Rust may be closer to C++ in numerical performance than I initially thought. I'd like for some of these things to be much more convenient to use than they are currently, but the opportunities are there.
The rayon library offers similar functionality to OpenMP, including a parallel map/reduce (etc) over a vector, all in safe code for the user.
I believe a operations that allow -ffast-math style optimisations were recently added to the floating-point types, allowing one to specify individual places where reassociation (etc) is OK. This obviously isn't as automatic as -ffast-math, but usually one has only a few small kernels where such things are relevant anyway.
Lastly, two smaller points:
- C++ doesn't do tail call optimisation just as much as Rust doesn't do it. Compilers for both can (and do) perform TCO, the languages just don't guarantee it.
- C++ doesn't do explicit vectorization either, not in the standard. If you're willing to move into vendor extensions then nightly Rust seems somewhat equivalent and does allow for explicit SIMD.
That's obviously true, but not what I (or the OP) was talking about. My point was that in many applications memory safety doesn't rank highly as a separate concern, in addition to computing correct output from expected input. Because of this, describing Rust as a language that solely focuses on memory safety isn't very interesting to large groups of developers that work on such applications.
> The rayon library offers similar functionality to OpenMP, including a parallel map/reduce (etc) over a vector, all in safe code for the user.
I did look at rayon when I skimmed through the available ecosystem. The runtime cost of that approach wasn't obvious to me from the documentation, and it doesn't quite let me keep the loop-based control flow usually employed for numerical calculations (because of the need to refer to different indices within the loop, etc.), but it's certainly a viable approach. Not a direct replacement to OpenMP loops, though.
On the subject of -ffast-math, I did not encounter these recent additions you mention in the language documentation, but I'll take another look on the issue tracker and elsewhere. Thanks for the information.
On tail call optimisations, I don't believe your statement is entirely correct. It's true that C++ compilers don't guarantee TCO (although, empirically they're very good at it), but Rust doesn't seem to be able to do it at all. It's explicitly stated in the language documentation and there's a recent issue on the subject [1].
And on explicit vectorization - I'll take a look at the latest nightly Rust and edit my post accordingly if explicit SIMD is already usable. Glad to hear it.
FWIW, I think Rust has made great progress considering the age of the language, and I'm glad to see SIMD and other improvements being implemented. My objection was simply against the hyperbolic assertion that Rust has already attained full parity or even superiority over C++ in performance.
By the way, is there a way to turn off runtime bounds checking for vectors? That's another common performance sink in numeric computing.
The right granularity for error handling is important, as well as making it easy to handle (abort? providing a default value? doing something else?)
It's not that it is not important, but code usability is important as well, lest it goes on the way of C++ hell (though I don't think it can get that bad, there are some warts - like "methods" and traits)
Option<T> and Result<T,E> achieve just about the best level of granularity I could imagine for error handling.
Suppose you're trying to fetch a value from a map (use case for Option<T>), or read some value over some fallible I/O stream (use case for Result<T,E>).
Want to abort if the value is missing or an error occurred? Just call unwrap() and ready yourself for (completely safe!) crash reports. unwrap() is just a way to dynamically assert certain invariants.
Want a default value in those cases? Just call or() or or_else() on the Option<T> or Result<T,E> value you have.
Want to do something else? Use Rust's pattern matching features and branch depending on whether the value was obtained, on conditionals relating to the value (or error), and more!
The appeal of exceptions, to me, has always been that they allow you to largely separate your error handling from your procedural logic since the catch block can usually go at the end of the method/function and can usually be written later. This means you can write and test code and then come back and handle error conditions after you've gotten the success path working. Option/Result force you to at least acknowledge the possibility of an error at the point when you're writing your logic. Whether that's ?/try!, .unwrap(), a match or writing in a more functional manner, error handling can't literally be an afterthought the way it is with unchecked exceptions.
I'm not arguing that this is a bad thing, and it may be a push in the right direction for many programmers. But it's still a push and many don't enjoy being pushed.
(Or maybe I'm just missing exceptions - because, as an example: I want to read a file and what I care about is getting a fd, anything before that "doesn't matter" and I don't want to care about every step)
On the subject, this page is good for those curious about it https://doc.rust-lang.org/book/error-handling.html
I think if programming is to make progress as a field, then we need to develop a methodology for figuring out how to quantify the cost-benefit trade-offs around "engineering tragedies waiting to happen." The fact that we have all of these endless debates that resemble arguments about religion shows that we are missing some key processes and pieces of knowledge as a field. Instead of developing those, we still get enamored of nifty ideas. That's because we can't gather data and have productive discussions around costs.
There are significant emergent costs encountered when "programming in the large." A lot of these seem to be anti-synergistic with powerful language features and "nifty ideas." How do we quantify this? There are significant institutional risks encountered when maintaining applications over time spans longer than several years. There are hard to quantify costs associated with frequent short delays and lags in tools. There are difficult to quantify costs associated with the fragility of development environment setups. In my experience most of the cost of software development is embodied in these myriad "nickel and dime" packets, and that much of the religious-war arguing about programming languages is actually about those costs.
(For the record, I think Rust has a bunch of nifty ideas. I think they're going down the right track.)
I think this is a pretty big myth that only applies to some of these language features.
If you admit that it applies to some language features, then it's not a myth by definition.
In Smalltalk, #doesNotUndertand: handlers and proxies and unfortunate "clever" use of message sends synthesized within custom primitives could result in outsized costs. (It's where method_missing comes from in Ruby.) It's not that you couldn't do powerful and useful things with those facilities. It's that large projects that were around for years tended to accumulate "clever" hacks from bright young developers with a little too much hubris. Often, those costs would be incurred years after the code was written.
Yes, it only applies to some language features. But it clearly does apply to some of them. I don't think it's easy to come by quantified costs for these. Doesn't this strike you as a problem for our field?
I think this quote points to the REAL underlying issue here.
Rust is a language primarily built for systems programming. It has many strengths to celebrate, and brings curated best practices as well as its own novel features to systems programming.
However, most programmers in 2016 aren't "systems programmers" anymore. At the very least, most programmers who actively talk-up new technologies on web forums are not systems programmers. The majority (or at least the majority of the vocal and socially engaged) are web developers, mobile developers, CRUD apps and microservices, etc.
As interesting as Rust may be in the systems space, it doesn't bring much compelling new hype to the table for web stuff.
You have yet-another-concurrency-approach? That's great, but most web developers rely on an app server or low-level library for that, and seldom have to think about concurrency up at the level of their own code.
You have an approach for memory safety without a garbage collector? That's great, but most web developers have never even had to think much about garbage collection. Java, Go, etc... the garbage collection performance of all these languages is on a level that makes this a moot point 99.999% of the time.
You have a seamless FFI for integrating with C code? That's great, but after 20 years of web development I can count on one hand the number of times I've seen a project do this. And those examples were Perl-based CGI apps way back in the day.
Rust people seem almost dumbfounded that everyone hasn't jumped all over their language yet. And from a systems programmer perspective, memory safety without garbage collection does sound amazing. But you guys really need to understand that Hacker News and Reddit hype is driven by web developers, and that community isn't even sure whether or not type safety is a worthwhile feature! So really, it's amazing that you've managed to draw as much hype as you have. It's not about the mainstream popularity of your language, it's about the mainstream popularity of your field.
(1) Web apps are increasingly being split into a separation between presentation-only frontends + multiple "purely API-oriented" backends;
(2) There is a trend towards static typing in webapps.
We're currently using Go (plus some legacy Ruby apps we haven't rewritten yet) to implement microservice backends that serve APIs, and the frontend is all client-side JavaScript using React. (We also use Node.js to do server-side rendering of static HTML for Googlebot, but for a typical visitor, all the magic happens in the browser.)
For us, Go works well, and the compilation and static typing is a much-appreciated safety net compared to the everything-goes world of Ruby, not to mention much better performance and memory usage (one app is went from being multiple Unicorn processes consuming 2GB RAM in total, down to a single process using ~60MB and a fraction of the CPU usage).
But this isn't "systems programming" at all, and yet for me, Rust is very much on the table as a possible next language. I'm not sure if its complexity is large enough of a hindrance yet. Go is already a challenge for junior programmers who are used to dynamically typed languages, Rust much more so. I'd love to be able hire all seniors, but all the hot startups are taking them. (Though in that sense, Rust may even serve as a good carrot.)
As for static typing on the web side, TypeScript — which is essentially static typing for JS — is also most definitively in our future. The last year or so, Microsoft has made it easier to work with a mix of legacy JS and TS, so you no longer have to convert the entire codebase to migrate, which is great.
I don't think every company is going to move away from their classical Rails or PHP stack, of course, but there's definitely a trend, and I can imagine Rust becoming a popular alternative to the other statically-typed languages, including Scala and Java.
Rust is only about a year old. Once the library support grows, it's going to be a giant in just about every space I can think of.
Rust means software that can be written once and used "forever". Thus it enables true open source. In comparison C/C++ pay a mere lip-service, by also giving you, along with the code, lots of reasons to worry.
This is the real innovation behind Rust.
Interesting to see forks of older OSS Perl web apps still in use today.
Yes! Dreamwidth is a fork of the old LiveJournal code that is still being developed by a small team of folks who would rather see a small site run in an open, transparent fashion than be beholden to large corporate interests and the whims of monetization.
We're a very happy little family and it's always exciting to see Dreamwidth links end up on HN. :)
https://dlang.org/
1. several small languages also introduce the type system to try to solve the memory safety problem. But all of them are less famous. Because there are many reasons that makes a language being accepted massively from other tons.
2. in many cases, it is not hard to do manual memory management. There are many great software done with manual memory management. Although I admit the quest to memory management is always wonderful for system. But go to the follow #3.
3. linear/affine type system[1] is not the panacea. The case of "used exactly once" is just a small case. Forcely to this pattern makes large boilerplates. And constraints and verifications to system can not be done many levels and aspects. Is this truly valuable to add all into type system?
4. memory safety of Rust comes with price, which have added many complexities and language burdens to itself. Who like to read the following function declaration?(just borrowed as example):
fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'a str
5. So, finally, the question arises: does the current form of the memory safety of Rust deserve as the hope of next industry language? I'm afraid...
> fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'a str
Anybody who cares about the validity of pointers would like to read that. It very explicitly tells you what must be true of the arguments for them to be valid and for how long the result will be valid.
In general, you seem to be over-valuing conciseness. If you think conciseness is more important than memory safety, feel free to not use Rust. But frankly, it is trivial to make a language more concise. That's not a hard problem whatsoever.
However, I feel that Steve Klabnik is trying to dispel myths about Rust not being anything "but" safety, to shape how other Rust developers talk about Rust, not denying that Rust's central purpose is around being a safe language.
This is because there is a lot of miscommunication about Rust. A lot of people who aren't immediately sold on the language walk away thinking it's slow (it's not), it's complicated (not really), and not production ready (it actually is). And that's because Rust developers don't know how to talk about Rust. I am guilty, for one.
Since Steve is such a huge part of RustLang development, it's his duty to direct the conscious effort to promote the language.
No reason to get into a debate over click-baity titles. :)
Nim follows a different approach.
Details: http://nim-lang.org/docs/manual.html#threads
Benchmark (with Rust): https://github.com/costajob/app-servers
Billions of dollars and countless lives lost? I'm not saying that buffer overruns aren't a thing but this seems like marketing claims without substance. Yes, I read through the examples below, still think he's overstating it.
My eyes have seen the glory of RUST, it's really javascript, right?