Microsoft is gearing up to improve the security features of Windows 11 and upgrade the default file system with a more robust and efficient solution. Developers at the tech giant are independently working on two new features – booting with Rust inside the kernel and using ReFS instead of NTSF as the default file system.
Rust is officially everywhere.
Microsoft is one of the advocates of Rust programing language. On top of that they are rather happy when spreading some FUD about C/C++. So replacing a couple of lines of C++ into Rust (unsafe). Good for you Microsoft.
The only one spreading FUD here is you. In case you haven’t noticed, 1) the language wasn’t developed by MS, but rather Mozilla, and 2) your own beloved Linux kernel is also incorporating it.
All they said is that Microsoft is one of the advocates of the Rust programming language. I think that is quite a defensible statement these days. It does not in any way imply that Rust originated at Microsoft.
As for why MS is putting Rust into Windows, it seems that Geck is pretty cynical about that but I am not sure why. The benefits of Rust in Windows seem very clear and have been well communicated by Microsoft themselves. We do not have to search for ulterior motives.
As for why MS would want to spread FUD about C/C++, I am not sure. I suppose driving people away from C/C++ might result in higher .NET adoption. That feels like a stretch. At any rate, I believe that MS is also a significant advocate of C++ ( especially through Herb Sutter ). So, I am not really sure what Geck is saying.
All that said, my own understanding is advocacy for Rust in Windows is one of the factors in why the Linux maintainers were willing to entertain the idea of allowing Rust in the Linux kernel. So, I am not really sure what point you are making either.
@anevilyak
It’s a nice little experiment. Trying to introduce another language in GNU/Linux. Lets give it a decade to see on how it goes.
I am not the biggest fan of the term GNU/Linux at the best of times but trying to use that label for the literal Linux kernel is just too much. There is none of the “GNU Operating System” in the Linux kernel that is for sure.
If you are saying that Linux distros are “introducing another language” then that is very confusing and many, many languages are represented in a typical Linux distro.
FUD about C/C++? I’m sorry but windows is still written largely in C/C++ bro…
cb88,
I’m also curious what exactly Geck meant by this.
I don’t have any gripes with the article, IMHO it does a fair job mentioning the work involved (converting types to use rust primitives instead) and the limitations (the use of “unsafe” wrappers for the rest of the kernel.). We shouldn’t put too much stock in a press release, but this is a very interesting development as it means windows is in the race to take up rust conversion in earnest for core kernel development and not just as an experiment for linking in rust drivers.
@cb88
Just read what people like Mark Russinovich are saying publicly. On how we should all start to perceive C/C++ as legacy. That is spreading FUD. Microsoft never could an never will be able to retire industry standards like C/C++. If we will ever move to something else we will decide that. Not Microsoft. They are free to rewrite Windows (kernel) in Rust. I have no problem with that. Lets see them do it first.
Geck,
What specific evidence do you cite for FUD? You are putting the onus on the reader to back your claims, but multiple readers here are questioning your claims including me and the onus is always on the one making the claims.
https://twitter.com/markrussinovich/status/1571995117233504257
Thanks for the link, but what he’s saying isn’t FUD, it’s what many of us actually think about C/C++ and the notorious memory faults that stem from using them.
Geck, if you want an example of actual FUD, check out one of the replies to the tweet you linked to:
“Yeah…I heard a certain website got pwned due to it’s backend being written in Rust.
Which means nothing; but if it’s the language of choice for that website, I want nothing to do with it.”
Yeah I agree with that statement and don’t see how it’s FUD…
Fear Uncertainty or Doubt… of which there are none about the fact that Rust eliminates a class of errors and mistakes that C/C++ has been battling for decades. You can still write bad code and or cause bugs in Rust… but at least they should not be memory related.
It’s FUD. The only reason you don’t recognize it as such is as you are a part of it. Spreading it. In short, nobody is retiring C/C++ anytime soon. Development and standardization of C++ will proceed as usual. In the foreseeable future. And no, new projects won’t all start in Rust. In addition billions of lines of code written in C/C++ won’t go anywhere in decades to come. So stop spreading FUD in regards to C/C++. Or should i say more specifically against C++. As C/Rust is something that majority of Rust developers uses anyway.
Geck,
Facts != FUD
You can’t call it FUD just because you don’t like the facts.
Straw man. You are refuting arguments that nobody is making.
Also please note the semantic difference between those saying C/C++ should be totally replaced in new work and those who predict C/C++ will be totally replaced in new work. I mention this because you’ve repeatedly mistaken one for the other. I guess you must be doing this because you consider your best argument to be against the substituted (ie wrong) claims, but this “rebuttal” that C/C++ aren’t going anywhere isn’t rebutting what almost everyone is saying.
You’ve succeeded in getting every comment to unanimously disagree with you, I’ve never seen such consensus on osnews before. If you are trolling all of us, bravo! Your hand was very well played! Otherwise though, you should become wise to the fact that you cannot dismiss decades of insecurities by calling it FUD to a bunch of software professionals.
@Alfman
We are literary discussing the comment made by Microsoft exec, which you agree with. And then you say i am refuting the claims nobody is making. Anyway.
Geck,
I’m not sure why there’s a misunderstanding here because I specifically highlighted the difference between saying safe languages should be used for new work and predicting that safe languages will be used for all new work. Nobody including the tweet, is saying the later, yet you keep trying to refute it. That’s why it’s a straw man.
@Alfman
The main problem here is most people still know on how to read. So saying publicly that in your opinion industry should declare C/C++ as depreciated. This doesn’t leave much room for interpretation. So for me that is good enough. I don’t even know what you are trying to discuss now. Considering that most people still know on how to read. Hopefully. I will just leave it at that.
Geck,
By acknowledging the opinion is that unsafe languages should be demoted and not the assertion that they will disappear any time soon, you’ve corrected the mistake, so I too am ok with leaving it at that.
Based on Mark Russinovich’s tweet (CTO of Microsoft Azure), I also consider this FUD against C/C++, there was no need to mention that language, he only needed to says that RUST is great and he will use it until his paycheck stop flowing. It was a direct tweet against C/C++. So, it is FUD, this is an agenda.
But what is the catch with Microsoft with RUST? are they going to use the EEE (Embrace, extend, and extinguish) or do you think those days are over?
martini,
For the record, I think twitter is an awful platform for discussing nuanced topics like this. The quaint summaries rarely do justice to the subject matter so I’m never happy to see twitter provided as a source, but here we are. This is a full quote of the tweet from Mark Russinovich that is alleged to be “FUD”:
There are two things to unpack here. Firstly there’s the claim that C/C++ are holding back security and reliability. Secondly there’s the opinion of what to do about it and whether or not to stop using C/C++ for new projects,
Time and time again unsafe languages including C/C++ have been the cause of security and reliability over decades. For better or worse the truth is that humans have a tendency to create invalid code under C/C++ since it’s so easy to make those mistakes. This problem is so notorious that instead of pretending we could preemptively fixing all the memory faults, we resort to security mitigations that use probabilistic techniques like “address space layout randomization”. ASLR cannot fix the faults humans create in C/C++ code, it just makes it more difficult for hackers to use the faults to modify arbitrary process memory. While ASLR provides a degree of mitigation, it’s objectively worse than safe languages where out of bounds memory accesses don’t happen in the first place. The classes of errors that C/C++ are vulnerable to are objectively true.
But now what of the opinion that we should replace unsafe languages like these with safe ones? I’d say this opinion is justified by the facts, but I’d concede it’s still just an opinion and there’s room to debate what should be done. However calling it “FUD” does not advance this discussion in the least. To be clear, there might be merit in different opinions, but the point here is that there’s no merit in justifying one opinion by calling the other opinion FUD.
Edit: patent -> patient.
@martini
I agree about the agenda part. Just do your project in Rust. If you feel that is the way to go. Like it’s done with any other language. As for what their aim with Rust is. I doubt they know ATM. On what to do with it. Rewriting a dinosaur, like Windows, or more specifically kernel, in Rust. Good luck with that. They don’t have resources for that.
Geck,
The “agenda” part is BS argument that can be thrown at just about anyone for having a different opinion.
Take a guess which one is you.
The agenda argument is bullshit that overlooks people’s real pragmatic needs.
While it might be possible for MS to have an ulterior agenda, you haven’t made a remotely compelling case for it. Microsoft’s motives make perfect sense at face value. They have a large preexisting code base and want to gradually migrate parts of it to use a safer language.
Obviously you’re entitled not like like rust, but the degree to which you’re throwing out accusations of it’s users and the companies starting to use it is uncalled for.
You are inventing artificial restrictions that don’t exist in reality. If you don’t like other people mixing vanilla and chocolate, then perhaps you’re the one with the problem.
@Alfman
In a decade or two we will see on just how Windows and Rust mixed. Will it be like water and oil. Or some sort of emulsion will be the outcome. Currently it’s just too negligible to conduct a serious discussion about it. Considering it’s still mostly an agenda. It’s like a drop of oil on top of an ocean.
Geck,
With all due respect, I think you are too fixated on declaring rust a failure to come up with a reasonable milestone for it’s success. Absolutely nobody is expecting C/C++ to replaced in a “decade or two” considering that C/C++ market adoption is several decades in the making. For those of us who actually believe in the merit of safe languages, slow steady progress would be really fantastic. The most reasonable way for this to happen is through a combination of new projects and gradual legacy conversions.
Like what FUD about C++? That it started life as a nasty hack on top of a C compiler, basically a pre-processor that accepted C++ code on the input end and outputted C code at the output end? That the above decision doomed the language to not have garbage collection, memory safety, array safety, pointer safety, or even a stacktrace (in C++, everything gets flattened to a contiguous hexadecimal sludge), thus throwing away most of the benefits of OO programming? Those are not FUD, those are facts.
C++ was substandard even back when it was launched. It started life as a “let’s see whether we can, without thinking too much if we should” experiment. The sooner C++ vanishes and gets replaced with Rust, the better. I am not usually a language snob, but the fact C++ is a nasty hack on top of a language (C) that is itself a nasty hack on top of PDP assembly is responsible for a ton of security holes and financial damage that’s entirely avoidable. Make it die already. At least C has the benefit that it has its place in history back when those things were not fully figured out yet, C++ was an entirely avoidable mistake.
kurkosdr,
Fully agree 🙂
Also reflection. Languages with reflection like C# open up huge potential for interop interfaces like soap. I’ve had a project or two where the lack of reflection in C++ resulted in the need for painstaking coordination of object metadata by hand. There are known hacks like abusing macros or even parsing header files, but IMHO we’re worse off with a lack of native reflection.
I’d like clarification about what Geck meant before jumping to conclusions, but I didn’t notice any microsoft FUD in the article.
@kurkosdr
Yeah. What you wrote is a good example of spreading FUD. Fulled by “”current thing”. Like lets say saving the environment with electric cars. As we have it all figured out. Reality obvisuly being totally different. But note that i don’t see it. In next decade or two majority of existing software stacks widely used in the ndustry will still be C/C++.
Geck,
Everyone knows it’s a long and difficult transition. Heck, it’s many decades past due by some counts. But unless you truly believe in using unsafe languages until the end of time, then logically, we’ve got to start somewhere. Why not the present?
By saying unsafe language. That is spreading FUD.
Geck,
Haha, you’re kidding me, so calling C/C++ unsafe is the big FUD reveal? Thank you for clarifying what you mean, I thought there would be more to it.
Congratulations on proving to everybody here that you have no idea what you’re talking about. C is 100% known to be an unsafe language to the entire software industry, the only reason it’s still used is because there’s entirely too much code written in it to maintain that can’t simply be tossed out overnight.
I never in my life heard Java or Python developer running around and calling C/C++ unsafe. It’s the Rust folk. That seem their sole reason for existence. We invented memory safe language, obviously not, and now everything else is unsafe. But we use C, like all the time, but our C usage, although unsafe, it’s still safe. For the love of… So yes. It’s FUD.
C/C++ is by far responsible for the most and the worst security vulnerabilities, and suffers from some severe backwards compatibility chains it has around it. If you could break backwards compatibility with C and older C++ standards you could have a nice language. But you can’t pretend those older parts don’t exist and if you trust your devs to write good C++ welp, you’re basically screwed. you need severe training wheels and tooling to make sure the code is reasonably safe. You can write really terrible rust code too, sure, but its more difficult to write subtly bad code in rust. There is also a learning curve, for sure. I think especially with Microsoft you’re seeing them weight the costs and benefits and Rust is basically winning. Its not like this is the first time Microsoft has explored using other safer programing languages to rewrite parts of windows. Rust is just the first one they’ve decided helps them more than it hurts them. Microsoft had C++ net/ Csharp and others they played with, but Rust is the only one to get this far. So I don’t see this a s Anti C/C++ Fud but a genuine achievement for Rust.
If it’s a code rewrite from C++ to Rust. Then it’s clearly targeted against C++. If it would be some new code written in Rust. Then it’s an achievement for Rust.
I was hoping ReFS would improve performance over NTFS, but the scant few benchmarks I can find put ReFS a little bit slower, but only by a small margin.
However, those were read/write benchmarks. From what I understand, ReFS is is much, much faster in some of the other FS activities that NTFS is slow at – such as, deleting a directory with a ton of file entries. NTFS is really slow at this. It’s painfully slow. Hopefully ReFS is much faster at this and other FS metadata operations
Missouri has an “unofficial” motto that you can see on their license plates: The Show Me State
Since ReFS has been around for many many many years, and not often implemented due to differences and incompatibilities with key aspects of Windows, I’d like to go on record with, “I’m from Missouri!”
Surely Microsoft would have previously used their own tools (cl, ml/ml64, link) to compile the kernel. Is this the first time they have used a third-party compiler to generate Windows code? I wonder how their security team decided that it was safe to do so, surely they didn’t audit all of the Rust compiler and standard libraries.
djhayman,
It’s an interesting question that deserves a better answer than I can provide, but I’d like to point out that it’s not strictly necessary to use rust’s standard library. Applications can eliminate some bloat by not using the standard library and kernels don’t usually use the “standard library”. It’s relatively easy to build all the abstract data types you’ll need. The same is true of C/C++, where many application developers don’t even use the standard libraries like STL and streams for standard applications.
That’s true about not necessarily needing the standard library (or at least not needing all of it), but interestingly I’ve seen pull requests on the Rust standard library submitted by Microsoft employees specifically for kernel code… They wanted to add extra “try” versions of some of the methods on the vector class to prevent panics in the case of an out-of-memory scenario, because having Rust panic in kernel code would probably be quite catastrophic :-D. So at least some of the standard library seems to be making its way into the Windows kernel, with Microsoft actively contributing back to Rust.
I suspect the comment from Geck are based on not actually a result of this article, because nothing posted by Geck seemed related to the article. Unless Geck is claiming Rust is already perfect as is and free of unsafe methods, which seems to contradict Rusts own milestones. So it would be good for Geck to clarify.
Overall, as far as I can tell, bringing Rust is a massive positive, at least from my own perspective as I grow older Rust is the first language I have come across in years that I find quite intuitive.
On ReFS I’ll reserve comment until the proof is in the pudding.
I am not on the Rust hype train. Will wait another decade or two. Before potentially considering it as a generally agreed upon industry standard and replacement for C/C++. If Rust ever gets to there. So a couple of lines of Rust (unsafe) in Windows sounds to me more of a PR thing than anything else. PR thing targeted against C/C++. Reality being something else.
Geck,
There’s a difference between being skeptical of their long term commitment to rust versus calling them out for “spreading some FUD about C/C++”. It’s your prerogative not to believe in rust, but it does tackle many of the longstanding well documented problems with C/C++ and many of us believe it’s about damn time safe languages get a shot in mainstream kernels. This is why we are happy to see a safe language finally gaining traction in both of our dominant operating systems. Obviously there’s a ton of work to do and this will take a long time, but the news offers a rare moment of optimism for those of us who believe kernels should embrace safe languages.
So if you doubt their long term commitment in regards to Rust. And they are vocal about the need to put C/C++ into a legacy mode. As imagine they even rewrote a couple of lines in Windows to Rust. Why should i be optimistic about such outcome? Killing of the only viable language used industry wide. Regardless of the platform. Do whatever with Rust. I don’t have a problem with Rust as a language per se. But this agenda against C/C++. Sane people will fight that and keep C/C++ as first class industry standard in the foreseeable future. Regardless of the hipsters.
Geck
I didn’t say this, please don’t put words in my mouth.
You don’t have to be optimistic about it. Honestly, that’s your business. I’m just glad safe languages are getting more attention by major players in the industry and it seems we’re finally seeing a more significant attitude shift than in the past, which is great by me.
That is simply false, both in terms of “killing” and in terms of “only viable language”. Even rust advocates admit that C/C++ are going to continue being around for a long time. There’s tons of legacy software out there that isn’t going away any time soon. But many of us feel they should be demoted for new code & new projects for the sake of eventually making software more robust to corruption faults. This will take a long time, but I for one am hopeful that things are starting to change.
Given your attachment to C/C++, I understand why you and other holdouts may be frustrated with new languages stealing the spotlight. However it’s only a matter of time before older generations who have the most attachment to old languages retire from the industry. New generations will naturally have less loyalty and be more open to new ideas and modern languages. You may not like it, but you don’t have to like it for this to be true.
“Sane people will fight that and keep C/C++ as first class industry standard in the foreseeable future. Regardless of the hipsters.”
I have not really seen Rust advocates suggesting that C or C++ will lose their status as very widely used and popular languages anytime soon. I assume that is what is meant as “first class industry standard”. Indeed the message from Microsoft that set this discussion off makes it very clear that they do not see moving entirely away from C/C++ anytime soon. Rather, they see value in using Rust as a way of mitigating some of the short-comings of those languages and are picking their spots where that can be done in a targeted way.
I am not sure that it is fair to call people “hipsters” for wanting to use something “safer”. Rust has been shown to be far less susceptible to the source of 70% of security bugs found in production C/C++ code. I have seen that same stat from multiple sources including from MS. That sounds like a pragmatic, sound, engineering driven motivation and not simply a “hipster” popularity contest.
C++ will have its fans and not everybody will love Rust. A fairly well respected and well known C++ dev might be Andreas Kling ( of SerenityOS ). He has called C++ his favourite language. Still, he did go looking for something “safer” and found Rust. He did not like it though as he found it a poor fit for the kinds of inheritance-heavy OOP code used in his project ( most notibly GUI stuff ). In the end, he is writing his own “safer” language ( Jakt ) which currently compiles down to C++.
We will see if Rust has the staying power that C++ has had and will probably continue to have for a while. That said, Rust seems to solve real problems today. I would expect it to become increasingly common to bring Rust into C/C++ projects to address short-comings in those languages. It also seems likely that we will see projects that would have been written in C++ in the past to be increasingly written in Rust from the start. This will naturally eat away at the popularity of C++ over time ( if not Rust than something else ).
My own view is that Rust, or something even better, will eventually push C/C++ to the sidelines as security and multi-threading become more and more mainstream requirements ( not just hipster stuff ). We will see.
Ha ha no, it will become a legacy thing much like COBOL. Learn Rust or become a dinosaur maintaining increasingly ancient codebases.
When it comes to C++, we are talking about a language that not only lacks basic concepts such as garbage collection, but forces the programmer to think at the assembly level, not even the procedural high-level language level. Here is an example: lack of array safety is an assembly-level problem. In high-level terms, if I am assigning anything to an array, I only have to care about what happens to the data in the particular array I am assigning to, the idea that a “buffer overrun” can happen that will corrupt data in other parts of memory, even parts of the memory that hold the program instructions or the return address, that is an assembly-level problem. Then you also have to be mindful of old-fashioned high-level problems such as managing allocated memory due to lack of garbage collection, and then you also have to be mindful of the OO problems you’d have to think about anyway (plus perverted problems like multiple inheritance that better languages avoid). In the meantime, you can try your best to be productive.
There is a reason most corporations eagerly jumped ship to Java (and later Python). And even before that, there were companies programming in languages such as Pascal and Tcl for the sole purpose of avoiding C++, because with C++, a single programmer in the company failing to think in assembly terms for one minute puts the entire company at risk.
Or at the very least, learn Go. It’s close to the C++ mindset but without all the suck.
Obligatory closing quote from the Unix Hater’s handbook:
“Over the past few years, we’ve known many programmers who know how to program in C++, who can even write reasonably good pro-grams in the language…
…but they hate it.””
BTW I think the chapters on C and C++ of the Unix-hater’s handbook should be mandatory reading for every C or C++ zealots, because it eloquently demonstrates that the talking points the zealots have memorized are PR intended to explain away fundamental design blunders, not sound arguments. The rest of the book hasn’t aged well, but C and C++ are still the same awfulness as they were back then, and of course they are causing avoidable security issues and financial damage just like they did back then:
https://web.mit.edu/~simsong/www/ugh.pdf
@Alfman
So then you do feel that Microsoft is serious about Rust? In the terms of we can put C++ into legacy mode. Don’t develop and standardize the language anymore. And we are safe?
@tanishaj
Indeed. Nobody had to force companies to explore lets say Python. And in the end Python managed just fine. Why do we have to force it so much with Rust?
@kurkosdr
I don’t buy it. That everybody hate C or more specifically C++. In such case no real force would be needed. To try to persuade developers into using Rust. Considering how safe it is.
Oh please, not everyone hates C++. People who don’t want to learn new stuff love C++. People who get their juices flowing by complexity and doing tasks such as freeing memory manually so they can feel 1337 love C++. People who don’t care whether their programs have security holes, memory leaks, or crashes with no ability to diagnose, also love C++.
On the other hand, programmers who want memory-safe, garbage-collected languages, the ability to read other people’s code without having to decode other people’s perversions, and the ability to debug at least some of their program’s crashes, hate C++
Of all the programmers I’ve met who claim to love C++, none of them wants to debug C++ core dumps (instead you have to give them precise instructions to replay the scenario that caused the crash, otherwise they close the report as “could not reproduce”). I think that says it all.
Geck,
Microsoft are effected by C/C++ flaws just like the rest of us and it makes sense for them to want what rust offers. They might lie to get ahead, but why lie to stay behind?
Developers are free to use rust or not in their own projects. Please elaborate who is “forcing it” with rust and how? Without a good explanation, this really comes across as bias.
@kurkosdr
In my opinion majority of programmers “hate” C/C++/Rust.
@Alfman
Lets then rather wait a bit and see on what they come up with in the future. A lot of internal ideas and projects are rather short lived. And during this time we can still do things like develop C++ as a standard further. To be more concurrent friendly, more memory safe … And things like having GCC front end for Rust. All this things are promised and still a couple of years in the future. It’s in my opinion much safer to continue like that. Then to say OK Rust is safe, C++ is not safe. We obviously want it safe. What is there to think about. Well.
Geck,
Where I have heard this before? Haha. You’ve used the same argument about manufacturers open sourcing their drivers: let’s just keep waiting. The thing is, when problems have persisted for so long over decades with little progress by incumbents to show for it, then it may be time to give someone else a shot. We’ll see what comes from the C/C++ camp in the future, but honestly there are a lot of other frustrating aspects with macros, include files, forward declarations, etc that make it rather cumbersome compared to other languages…by the time you fix all of the things developers find annoying, it won’t really be the same language any longer and it wouldn’t be backwards compatible.
While backwards compatibility is important, it can also hold back progress. Some of us think C++ is already too complicated and it’s a big problem to update the language given all the legacy code and at times troublesome syntax trees that have to be supported.
C/C++ obviously have staying power, but if you want GC-free memory safety today, rust is the clear leader and I don’t see C/C++ catching up because of backwards compatibility, which is extremely important for C/C++. A new language with a clean slate less encumbered by the past seems to be a much simpler & cleaner path forward. For example I like d-lang a lot, they’ve fixed most C/C++ annoyances while keeping a familiar syntax. D is somewhat less sophisticated than rust, . but If you want to add safety features to an existing language, perhaps it would make more sense to use D lang for a better foundation than C/C++.
@Alfman
I can tell you where you heard it before. With Fuchsia. You acted in the same hipster alike way. And we all know how that ended. With GNU/Linux and device drivers. It always worked just fine. What some would like is to further extend upstream driver support. As with root access and upstream device drivers that enables end users to have more control over the hardware. Fuchsia AFAIK was never about that. And AFAIK it never did device drivers as good as GNU/Linux.
Geck,
We were talking about android manufacturers and their reliance on proprietary blobs. “It always worked just fine”? This negates/ignores a lot of the frustration the community has experienced over decades in regards to FOSS on run of the mill ARM hardware.
Like you, I’d love to see linux just work on ARM as well as it does on x86, it would be fantastic. I would love to use a lot of commodity hardware in projects if it just worked under a standard linux environment. A similar topic came up in another recent article.
https://www.osnews.com/story/136082/janos-turn-your-phone-into-an-iot-board-2/
But until then, I think it’s fair to say the FOSS experience of linux on ARM is lacking, to say the least.
It’s unclear to me if google intends for Fuchsia to compete with linux on mobile, but I would welcome the competition. You don’t believe Fuchsia has potential, and that’s fine, but I’d still say that even FOSS operating systems can benefit from competition to prevent them from becoming too complacent. IMHO competition has a way of piercing through roadblocks and getting the ball moving when nothing else has worked.
I love diversity, Rust, Vlang, Go, Zig, so much innovation, so many smart solutions to long standing problems. In many cases so much better, but obviously still in their infancy and far from complete.
Perhaps when these languages or some other have been around another 10 or 20 years, when they become middle aged like C++, we can expect many great things.
Diversity rules, the mono-language apparatchik is dead!
And I fully expect to still be writing Java, PHP, Python and Pascal 20 years from now.
But the aim of Rust is not really about diversity. It wants to become C/Rust instead of C/C++. To the extent Rust folk is now rewriting C++ code into Rust. So maybe in the next 100 years it’s doable.
Geck,
C is just as unsafe as C++, and even more so to the extent that you’re using more pointers than abstract data types.
I think it’s very important to understand why Rust is designed to work along side C code: it isn’t because this is the ideal way to write software, but because it’s necessary in a world dominated by C software and C APIs. Even though you don’t like rust, it should still make sense why it pragmatically needs to be compatible with C APIs. Consider that if rust did not offer solid C integration, then it would significantly impede legacy developers from considering the inclusion of rust in their projects.
Alfman
It just makes sense doesn’t it, and if I was the curator of some caringly nurtured and cleverly constructed C API I should be very very happy. The better Rust gets the less likely anybody will ever need to make my baby redundant!
It’s like a build on your strengths philosophy.
We are finally moving out of the era of languages that were initiated for punch cards.
Yeah. It’s not ideal.
It is kind of easy to spot the SpinDoctor of this thread.