6 ms·

The 'any' in that person's comment was ridiculously absolutist, I agree. Looking at things from a more general standpoint, there are many examples of Rust bein

The 'any' in that person's comment was ridiculously absolutist, I agree. Looking at things from a more general standpoint, there are many examples of Rust being used in production already. Admittedly as previously stated where the need for functional safety assessments aren't stringent nor is the need for a robust set of commercial grade tools. That's still a solid chunk of the market. I think a lot of open source projects that land in commercial products don't have the same degree of quality tooling associated with commercial counterparts. That doesn't stop those products from succeeding. On the basis of examples such as Microsoft's disclosure of the use of Rust in the Windows 10 kernel's IPC COM bridge, Google's use of Rust in OpenTitan and a couple of others that I'll need to dig up (but evidently do exist in the public domain), I would say that in the general case Rust doesn't need a 10-20 year horizon to work in the same general spaces as C. Time will tell how true that ends up being but the trend is quite clear to me (and I was a Rust nay-sayer for quite a while before actually doing a reasonably sized OS kernel port that made me see the value). Excuse the slight meandering but you come across as the sort of person who would appreciate some of these points. The significant value add that Rust brings is compile time memory safety - something that C/C++ simply don't have or likely to in a scale-deployable manner. The security and safety stick is hitting so hard now that a lot of the traditional arguments against an upstart programming language option are now seemingly more palatable to a lot of shops. There's a lot more to Rust then just the memory safety - I often lament about how the other bits don't get enough attention. The threading is top-notch, the expressiveness as a result of functional patterns is addictive (I find myself using Rust programs as alternatives to everyday Python/Ruby scripting - 'tis true!), the generics are lean and not overwrought as C++, the composability using traits is a good middle-ground to insane class hierarchies in C++. I could go on! Now it may be that there emerges another alternative but at present Rust has blazed a memory safety trail that I don't see anyone in a position to challenge. When C and C++ are massaged to get to a similar space, they likely won't be the same languages anymore anyway. Speaking about performance parity as a related aside: As an admittedly crude but IMO representative example Rust is already at par or better than C and/or C++ for the only truly open and idiomatically comparable suite I could find - drum-roll...micro-benchmarks - specifically The Benchmarks Game (results publically available). Now I concede that micro-benchmarks don't represent reality but they are what _every_ compiler engineer uses first to sanitise their port (and even what a lot of processor architects use in their RTL simulations - because that's often all they can run to completion at KHz rates) and therefore have good representative value in the first order. More representative macro-level use-case comparisons are harder but there are sufficiently many examples of higher level frameworks (web servers etc) that showcase Rust's safety and performance. Those didn't require commercial grade tooling and a fair number are being used in production today. About ISA convergence - and talking about the low perf deep embedded end - which is where the compiler tooling is lacking - Arm has been providing zero dollar cost licenses for the past 2 years now. See Arm DesignStart Eval and DesignStart Pro. You can do Cortex-M0 and Cortex-M3 evals at 0 USD upfront cost and have pretty much the same royalty arrangement as you would with any alternative. Heck at 75K USD you can even do a Cortex-A5. Such initiatives are likely only the beginning so the trend is quite likely going to be convergence. That's all speculation I admit but the argument is a lot easier to buttress with concrete examples now. I would urge folks to give Rust a go. Wait - that sounded like a pun! :)

pjmlp 7y ago
> Now it may be that there emerges another alternative but at present Rust has blazed a memory safety trail that I don't see anyone in a position to challenge Apparently Ada (among other alternatives) keeps being forgotten by Rust community. Genode OS and NVidia are two high profile examples that decided to go with Ada/SPARK instead of Rust due to tooling, market certifications and not having to deal with borrow checker. There is even a Webminar from NVidia explaining why they went with Ada, after considering Frama-C and Rust as possible alternatives. Rust community has more to gain, by gathering around all the languages that provide memory safe systems programming, instead of trying to be Duncan MacLeod among them. On positive note, Microsoft has held an internal Rust Summit, and Kenny Kerr has made public his first Rust/WinRT attempt.
- fork-bomber 7y ago
  I think it's incorrect to state that Rust 'forgot about Ada'. Rust was designed to approach safety in a very different way. Ada's take on safety has an emphasis on strong semantic typing and run-time correctness. Rust's take on safety emphasises compile-time correctness. Very different. I would argue that compile time safety is a better way to go but everything has trade-offs to consider. Rust's borrow checker gets bad press because it forces programmers to confront their unsafe programming methodology and fix it. I think it's beautiful and ends up teaching you more rather than cultivating a culture of 'let me do what it takes to shut the compiler up so I can ship the product'. I find it very disingenuous to write the language off because it strives to be militant about safety. Oh and Ada's compiler is super testy too! It just doesn't get the same bad press simply because far too few people use Ada compared to Rust. I personally think that the reason people fundamentally add a moniker like 'Duncan MacLeod' to Rust is simply because Rust has gotten far too many things right and that irks dyed in the wool folks. Especially given that the choice of programming language is often enough a more emotive issue than a technical one. Having been one such person myself, I see a lot of folks spout FUD as a default position when confronted with evidence of the good design choices Rust has made. This is true. Now that does not mean that Rust is perfect - not at all. However, it's safety features, in the face of high performance - are very compelling. Once folks draw a box around the emotive aspects and start doing objective analyses, Rust does make one pause and ponder. That's the reason why there is evidently a growing sub-culture of Rust enthusiasts even within large traditionalist companies like Google, Microsoft, Intel and Arm, to name a few. Back to the point (!) Ada simply became too niche despite aiming to be general purpose by design. Today the open source Ada community is small compared to the Rust community and I think that is a huge problem for the perpetuation of the language, irrespective of the subset of high profile folks who've switched to it from C. A large and vibrant community is the reason why Rust's future holds more promise. The language evolves by open source consensus-by-merit (on Github!) and that's a very strong proposition for it's future. Balancing nimble-ness and backwards compatibility has worked well thanks to the editions feature (something that C++ has now borrowed from Rust). I'd love to see Ada succeed but at present I personally think Rust stands a better chance. Time will tell.

pjmlp 7y ago

> Now it may be that there emerges another alternative but at present Rust has blazed a memory safety trail that I don't see anyone in a position to challenge Apparently Ada (among other alternatives) keeps being forgotten by Rust community. Genode OS and NVidia are two high profile examples that decided to go with Ada/SPARK instead of Rust due to tooling, market certifications and not having to deal with borrow checker. There is even a Webminar from NVidia explaining why they went with Ada, after considering Frama-C and Rust as possible alternatives. Rust community has more to gain, by gathering around all the languages that provide memory safe systems programming, instead of trying to be Duncan MacLeod among them. On positive note, Microsoft has held an internal Rust Summit, and Kenny Kerr has made public his first Rust/WinRT attempt.

fork-bomber 7y ago
I think it's incorrect to state that Rust 'forgot about Ada'. Rust was designed to approach safety in a very different way. Ada's take on safety has an emphasis on strong semantic typing and run-time correctness. Rust's take on safety emphasises compile-time correctness. Very different. I would argue that compile time safety is a better way to go but everything has trade-offs to consider. Rust's borrow checker gets bad press because it forces programmers to confront their unsafe programming methodology and fix it. I think it's beautiful and ends up teaching you more rather than cultivating a culture of 'let me do what it takes to shut the compiler up so I can ship the product'. I find it very disingenuous to write the language off because it strives to be militant about safety. Oh and Ada's compiler is super testy too! It just doesn't get the same bad press simply because far too few people use Ada compared to Rust. I personally think that the reason people fundamentally add a moniker like 'Duncan MacLeod' to Rust is simply because Rust has gotten far too many things right and that irks dyed in the wool folks. Especially given that the choice of programming language is often enough a more emotive issue than a technical one. Having been one such person myself, I see a lot of folks spout FUD as a default position when confronted with evidence of the good design choices Rust has made. This is true. Now that does not mean that Rust is perfect - not at all. However, it's safety features, in the face of high performance - are very compelling. Once folks draw a box around the emotive aspects and start doing objective analyses, Rust does make one pause and ponder. That's the reason why there is evidently a growing sub-culture of Rust enthusiasts even within large traditionalist companies like Google, Microsoft, Intel and Arm, to name a few. Back to the point (!) Ada simply became too niche despite aiming to be general purpose by design. Today the open source Ada community is small compared to the Rust community and I think that is a huge problem for the perpetuation of the language, irrespective of the subset of high profile folks who've switched to it from C. A large and vibrant community is the reason why Rust's future holds more promise. The language evolves by open source consensus-by-merit (on Github!) and that's a very strong proposition for it's future. Balancing nimble-ness and backwards compatibility has worked well thanks to the editions feature (something that C++ has now borrowed from Rust). I'd love to see Ada succeed but at present I personally think Rust stands a better chance. Time will tell.