It's time to halt starting any new projects in C/C++

https://twitter.com/markrussinovich/status/1571995117233504257

by mustache_kimono • 4 years ago

766 863 4 years ago

twitter.com

thesuperbigfrog4• 4 years ago

How much support does Microsoft give to the Rust Foundation (financial and otherwise)?

Does Visual Studio (not VS Code) support Rust programming?

Are there plans for an official Rust SDK for Azure? https://github.com/Azure/azure-sdk-for-rust

daviddever23box• 4 years ago

https://github.com/microsoft/windows-rs

They're a founding member - no idea as to the amount of financial support that Microsoft provides to the Rust Foundation....

mikeyouse• 4 years ago

Per their membership page, Platinum members provide $300k/year - but of course the real value is paying MSFT employees to work on Rust projects.

zibby82• 4 years ago

Why does Visual Studio need to support Rust when VS Code has amazing Rust support?

qbasic_forever• 4 years ago

It's been ages since I last looked but IIRC Visual Studio is still the go-to and only real option for oldschool win32 programming (i.e. native windows, COM, etc.). I'm sure there are plugins and machinations to make VS Code competent at win32 too but for some companies and shops they're sticking to Visual Studio.

scoutt5• 4 years ago

Never underestimate the power of creating UIs with a drag and drop editor. Command line tools for general users ended in the 80’s.

As far as I know, creating and dealing with UIs in Rust is a pain.

I’m waiting for MS Visual Rust.

thesuperbigfrog4• 4 years ago

> Why does Visual Studio need to support Rust when VS Code has amazing Rust support?

It's about 'skin in the game' and dog-fooding. If Microsoft is serious about Rust, they will use it internally and support it officially.

It's easy to give an opinion on Twitter about how everyone should use Rust and stop using C / C++ for new projects.

Officially supporting Rust in your enterprise software development tools and SDKs shows that you are serious and committed to what you say.

somewhereoutth• 4 years ago

For systems programming, use whatever the Linux kernel uses. For everything else, there is javascript.

thesuperbigfrog4• 4 years ago

> For systems programming, use whatever the Linux kernel uses.

https://www.zdnet.com/article/linus-torvalds-rust-will-go-in...

> For everything else, there is javascript.

Scientific / numerical computations? GPU / CUDA programming? Machine learning? Natural language processing?

pipeline_peak2• 4 years ago

To be fair, anything done in Python can be said about JS and under V8 will execute faster.

But idk what OP is saying lol

kbenson• 4 years ago

A case could be made to consider libraries systems programming, as the "system" is often more than just the kernel. If you have libraries doing the heavy lifting of all that, then the language on top that calls into those libraries for the bulk of the intensive work matters quite a bit less.

antegamisou• 4 years ago

Scientific / numerical computations? GPU / CUDA programming? Machine learning? Natural language processing?

We serve CRUD here, sir.

jpgvm2• 4 years ago

I don't think it's possible to choose a worse (mainstream) language for general purpose use than Javascript.

If it's not running in the browser it should simply never be JS. That is the only environment where you are stuck with it. Almost anything else is better but you should probably using one of Java/C# or Kotlin/Rust in 2022.

paranoidrobot• 4 years ago

I think this title could be misinterpreted.

There is a difference between Mark Russinovich saying this, as a personal opinion, and Mark Russinovich, Azure CTO, saying this as a company policy/directive.

This tweet does not indicate that it's from him in his official capacity as Azure CTO.

ergocoder• 4 years ago

He is the CTO. If he advocates for Rust this much in his personal life, he will advocate it at work. Because he truly believes it will make things better.

Azure will inevitably use Rust more.

cutierust4• 4 years ago

I don't want to sound too girle or fanboyish but there is no other way to say it so I'll say it (hopefully he won't read this)- Mark Russinovich transcends titles and if he's said something about technology, it's probably 99.999% true.

Also, RITF, I love Rust but remember zig exists so chill

I also want to say one thing-- sometimes it's not so easy to just decide to write a project and say okay let me write this in Rust. You have to see available ecosystem. I hate python because I'm a systems programmer at heart but damn sometimes all it takes is a pip install, import and 3 lines to get going and understanding things.

Rust ecosystem is hugely lacking. I don't want to spend time writing boilerplate FFI. I've heard zig is better in this regard

ReactiveJelly5• 4 years ago

Wouldn't pip install and import be equivalent to "cargo new; cargo add; cargo check"?

netheril96• 4 years ago

Being true is one hand. Having power of decision is another. For the latter to come, he has to speak in the capacity of a CTO.

cmeacham98• 4 years ago

The point is that if he was saying it as CTO that would presumably mean Azure is (or will soon) stop starting C/C++ projects.

twelve40• 4 years ago

RITF? Research Institute of Tropical Forestry? Rat Intestinal Trefoil Factor?

jpgvm2• 4 years ago

Personally, given this is Russinovich - his personal opinion would carry more weight with me than whatever he has to say in his official capacity as Azure CTO.

badrabbit• 4 years ago

This guy is the bonafide hero behind sysinternals.

Mark, if you read this, please start with porting Sysmon to Rust. A Microsoft supported doc on how to use Rust when developing using the DDK would be amazing as well.

Sysmon on Linux uses ebpf, would be a selling point if it was also written in Rust.

woodruffw21• 4 years ago

Calling him the Azure CTO is strictly accurate, but HN readers probably know Mark Russinovich better as one of the primary developers of sysinternals[1].

I bring that up to highlight the weight of his opinion: Russinovich is legendary in terms of his systems programming contributions.

[1] https://en.wikipedia.org/wiki/Sysinternals

tenebrisalietum• 4 years ago

In the 90's before Mark Russinovich became part of Microsoft, he was doing interesting things like adding NTFS support to floppies (search "NTFSFLP")

throwaway20375• 4 years ago

Hat tip! Google found this: https://www.digiater.nl/openvms/decus/vmslt98a/nt/ntfsflp.ht...

a-dub• 4 years ago

absolutely! came here to say just that.

also the excellent book "windows internals", which is kind of like the bsd red book, or the magic garden svr4 book, but for systems derived from the windows nt kernel.

but perhaps his best work is this: https://learn.microsoft.com/en-us/sysinternals/downloads/blu...

a screensaver that produces a realistic blue screen (kernel panic) for the version of the operating system and kernel that are installed, along with a simulated reboot that lands back into bsod as an infinite bootloop. extra bonus points because it also creates fake disk activity (for the era of hdd lights and hdds that made noise) for extra realism during the simulated boot.

stavros• 4 years ago

I remember trying to install that screensaver yet always having it crash my system, for some reason.

I did wonder how a screensaver can crash the kernel, until I remembered what it's supposed to do.

I was embarrassed for quite a while after that.

px43• 4 years ago

Also IMO it's best to avoid his fiction books, Zero Day etc. It's been about a decade since I read it, but it was the first book I've ever read where I felt uncomfortable with the level of detail the author went to when describing the breasts of every female character. The random awkward sex scenes thrown in for no reason was a weird choice.

Most importantly, there's also a complete lack of understanding of the underlying motivations behind both Islamic terror organizations, and cyber crime groups.

I love a ton of things that Mark has built, and I'm glad he's out living his best life. According to the Amazon reviews, a ton of people loved the book, but from my perspective Zero Day is a rare miss.

omnibrain• 4 years ago

a screensaver that produces a realistic blue screen (kernel panic) for the version of the operating system and kernel that are installed

I used this one at work for some time. Until I came back from my lunch break and got told by my office mate that he helpfully rebooted my PC because it had crashed in my absence.

aoetalks• 4 years ago

Re: the screensaver:

Note: before you can run Bluescreen on Windows 95 or 98, you must copy \winnt\system32\ntoskrnl.exe from a Windows 2000 system to your \Windows directory

There be dragons

pessimizer• 4 years ago

Very very rarely in my life do I feel affectionate towards Windows (and I've been virtually exclusively Linux/other-unix for a long time.) Sometimes it happened when I was writing dumb VBA in some Excel project, which I find fun for some reason. It happens when I play Windows 95/XP era Minesweeper. It also happens when I touch or have to use any part of Sysinternals. I even like reading the docs for Sysinternals, even though the UI is usually so good you hardly need them.

ripley12• 4 years ago

I feel the same way about Sysinternals tools. They give me a warm fuzzy feeling, I think acquiring+maintaining Sysinternals is one of the best things Microsoft's ever done.

The way they expose OS internals in a powerful-but-user-friendly way is delightful and empowering. I still remember the first time I used procmon; it felt like a veil was removed from my eyes, suddenly I could trivially see everything processes were doing!

Sysinternals represents an idealized Windows to me: an OS for power users with a GUI-first culture that differentiates it from Unix. Windows itself might not live up to that dream anymore, but at least we have Sysinternals.

ekianjo• 4 years ago

Appeal to authority?

dtornabene• 4 years ago

multiple people, myself included, logged in to comment precisely because the idea that MR is mostly aptly described as "Azure CTO" is a bit much. Glad the op commented the way they did, it also obviated this exact argument by simply establishing who exactly he is and not exhaustive foot stomping recitation of all his work.

philosopher1234• 4 years ago

Appeals to authority are useful and good. They’re shorthands for doing PhD theses on every topic you encounter. They aren’t bulletproof, though.

woodruffw21• 4 years ago

We do indeed listen to what authorities on subjects have to say, yes. Mark Russinovich is an authority on systems programming, and his thoughts carry weight because of his track record.

croes• 4 years ago

How about experience?

baq7• 4 years ago

what's the alternative? invent and validate everything yourself?

lbriner3• 4 years ago

Appeal to authority is when you claim something is true just because an "authority" said so.

MR is clearly expressing an opinion and reasons for it and it is up to you to decide whether his experience qualifies him to make such bold claims, whether there are edge cases for exceptions and whether or not you agree or care.

felipellrocha• 4 years ago

It’s only a falacy if the authority is not an expert in the field they’re speaking about. Example, a religious leader speaking about science matters, or an accountant speaking about engineering matters.

Otherwise, the argument is 100% valid.

gruturo• 4 years ago

Seconding this. I saw the article before its title was changed, and I admit I dismissed it right away (I know, how improper of me).

When I see Mark's name, I stop and read the article.

MathMonkeyMan2• 4 years ago

The C/C++ people hate it when you call it C/C++.

klysm• 4 years ago

“It’s time to halt starting any new projects in C or C++”

Kranar3• 4 years ago

That's a fairly recent thing that some people do as a kind of virtue signaling.

The "C/C++ Users Journal" was a very popular publication and no one took issue with its name. Nor do people take issue with Dr. Dobbs which has a "C/C++" section with articles from highly influential members of the C/C++ community.

C++ is a complex language, so people invent ways to show how dedicated they are to it, and nowadays that means pretending to get all worked up over the term "C/C++".

im3w1l• 4 years ago

I think it's also that idiomatic C++ is evolving further and further away from anything resembling C. So it's turning from C with extra features into a completely separate language that happens to interoperate well with C.

MathMonkeyMan2• 4 years ago

C/C++ is undefined if C is an instance of an integral type.

unglaublich• 4 years ago

C/C++ is as naïve as ASM/C or Ape/Human.

You come up with examples that are over 30 years old.

wahern2• 4 years ago

That's a fairly recent thing that some people do as a kind of virtue signaling.

If by recent you mean well over 20 years ago. When I began learning C circa 2000, I used to hang out on comp.lang.c, and "C/C++" was very much frowned upon. And for good reason--people felt entitled to ask C++ questions in a C newsgroup, which was and remains a poor idea. Even if they were asking questions relevant to both, e.g. regarding pointers, it's still a much better idea to ask in a C++ newsgroup. See https://en.wikipedia.org/wiki/XY_problem

There are people (invariably young) who resist newsgroup etiquette, convinced the etiquette is pointless, or something like virtue signaling. Over the decades they eventually come around to appreciating the wisdom, even if there's never a mea culpa.

The commercial software world, and especially the Windows world, often had a much different culture than what developed online, especially in the FOSS and Unix subcultures. For the latter especially, C++ was relatively uncommon until the 21st century. C++ (with KDE, etc) and then Python had the effect of importing or creating whole new subcultures in these communities without any memory or appreciation of the pre-existing culture.

DoingIsLearning• 4 years ago

The distinction actually makes perfect sense during the hiring process.

If a recruiter approaches me with a C/C++ gig then I will immediately assume that either the hiring manager doesn't know what they want or the hiring manager didn't actually write the job specs, none of those scenarios sends a positive signal.

kazinator3• 4 years ago

That's a fairly recent thing that some people do as a kind of virtue signaling.

It was a pretty common correction the comp.lang.c newsgroup in the 1990s.

"Hey you dolt, there is no C/C++; they are different languages."

"Oh yeah? Well look at how when I run cl.exe, it says Microsoft C/C++ compiler!"

"Haha, C/C++ is actually undefined behavior: C++ is modified and independently accessed in the same expression ..."

woodruffw21• 4 years ago

I certainly don't. Although I also write Rust now, so I suspect someone will accuse me of having split loyalties or something equally ridiculous.

The only context in which I care about "C/C++" is on resumes, where it's a sign that I need to ask a little more about the person's background.

pengaru• 4 years ago

The only context in which I care about "C/C++" is on resumes, where it's a sign that I need to ask a little more about the person's background.

Is that because you'd expect anyone actually experienced in either to know better than to lump them together so casually?

ncmncm25• 4 years ago

It's a sign of a liar, and you can round-file it without reading any more.

JonChesterfield3• 4 years ago

So far that on a CV has always meant "can write neither C nor C++"

LAC-Tech5• 4 years ago

Fair enough. I'll stick to C and C++/Rust.

mappu• 4 years ago

You see it a lot more often from the Microsoft world since MSVC only supported "C/C++" as a combined language, there was no separate C compiler.

kevin_thibedeau2• 4 years ago

They had a C compiler for kernel drivers.

pclmulqdq• 4 years ago

MSVC is a C++ compiler only. It doesn't actually support C.

spacechild14• 4 years ago

Well, technically it is one compiler, but it can operate in different modes, depending on the file input. So I don't this distinction is all too relevant.

omoikane• 4 years ago

I personally don't see this level of pedantry from the people I work with. Even if C90/C99/C11/C++98/C++11/C++17/etc are all different, we understand people use "C/C++" to mean "that pervasive family of languages which most systems and libraries are built on".

madmulita• 4 years ago

It's GNU/C/C++ !!!

another2another• 4 years ago

The correct name is GNU Visual Clang++

treme• 4 years ago

I envy CTOs with street cred on hn

cutierust4• 4 years ago

Jibe ;)?

nr2x• 4 years ago

Well, if online MBA programs are the street, there’s plenty with cred.

synergy205• 4 years ago

I'm waiting for Rust to support both static and dynamical link equally well. static link produces binaries too large for my embedded boards when stdlib is needed. dynamic link looks like a second class citizen to me in Rust. Is there some hope?

woodruffw21• 4 years ago

The workflow with `cargo` isn't as nice with dynamic linking, but `crate-type = "dylib"` has worked for a while now. Any crate built with that should produce a shared object instead, which you can link in like any other.

slavapestov• 4 years ago

Since Rust doesn’t have a stable ABI or separately compiled generics, wouldn’t dylibs necessarily be limited to exporting a C ABI?

woodruffw21• 4 years ago

My understanding (which might be wrong) is that you can rely on Rust not making incompatible ABI decisions between builds of the same optimization level on the same compiler version. In other words: you don't need to export a C ABI as long as you're able to enforce that every crate is built dynamically with the same compiler and flags.

That is of course still a significant restriction!

absolutelynobo• 4 years ago

you can use no_std when available.

not sure how dynamic linking would help when your boards don’t have enough (flash ?) space… the linked library still needs to go somewhere? how small of a flash medium are you using?

ReactiveJelly5• 4 years ago

Maybe multiple entrypoints?

The busybox style of packing everything into subcommands of one big exe is admittedly a hack, but... if it works for Busybox, and it works for Go, and it works for Git, and it works for Docker, then it works for me.

synergy205• 4 years ago

yes no_std for kernel or boot code or MCU boards, that's what rust-embedded is doing and I think it's fine.

many embedded boards typically have 16~64MB Flash running Linux with musl, one rust binary statically linked can easily exceeding 10MB. multi-entry is hard to manage when you have quite a few unrelated tasks, so yes I really need a true shared lib based rust for the mid-range embedded boards, which are, quite a huge number.

raggi• 4 years ago

dylib linking works well enough particularly for embedded cases. As an example Fuchsia did some research on this comparing it to C++. dynamically linking libstd amortized similar savings to dynamically linking libstd++, with trivial binaries going from hundreds of kilobytes to tens of kilobytes with a megabyte sized shared object for std.

As you'll read elsewhere in the thread there isn't an ABI guarantee, as there also isn't so much for C++ either - but particularly for embedded you can solve this in your build process. A competent package manager in a distribution can also solve for this.

schemescape2• 4 years ago

This is a tangent, but how do people comply with the MIT (or other) license when statically linking binaries?

You have to include the copyright notice and license, but I almost never see that being done (and, based on the Rust projects I’ve seen, there are often tens, or even hundreds of MIT/BSD/Apache licensed dependencies).

deadbeeves3• 4 years ago

People who use permissive licenses usually don't care about the license-inclusion clause, so most people just don't bother with it until someone comes asking. At the end of the day, fixing that problem is just a matter of including a new text file in the next release. It's nowhere near as big of a deal as when someone complains that you're not complying with the GPL.

By the way, whether you're linking statically or dynamically doesn't affect whether you ought to include the licenses of your dependencies. At least not for BSD, I'm less certain for MIT.

LAC-Tech5• 4 years ago

agreed, zig only from now on

TakeBlaster162• 4 years ago

Zig is production ready? I must have missed the 1.0 release announcement

LAC-Tech5• 4 years ago

It's not.

But to be fair it feels more ready than rust did at 1.0

sanxiyn7• 4 years ago

There is nothing wrong with using Zig in production before 1.0. You just need to weigh cost and benefit, including cost of dealing with breaking changes.

For example, Dropbox started to use Rust in production before 1.0, see https://blog.convex.dev/a-tale-of-three-codebases/

dleslie7• 4 years ago

Zig doesn't satisfy the safety concerns that make even modern C++ undesirable.

LAC-Tech5• 4 years ago

Have you ever used zig?

jasfi• 4 years ago

Nim is what you want.

mistrial9• 4 years ago

are the rumors true, that much of Azure was really bolted-together Ubuntu things.. has that changed, aside from the reality of web-facing service pages growing by the thousands themselves...

retcore• 4 years ago

No, Azure was never a Linux distribution variant but a NT derived distributed hypervisor OS codenamed RedDog led by Dave Cutler with some heavy VMS experience in the team. It's almost COM+ under the hood.

Grim-444• 4 years ago

Imagine how much impact we could have if we used all the effort gong to develop Rust and port everything over to Rust to instead just improve the wrinkles that exist in C++.

Mountain_Skies• 4 years ago

If we did that, the Rust folks wouldn't be able to claim credit for the colossal amount of very important code written in C and C++ that gets ported over to Rust. I've never seen a language where feathers in the cap are more important than they are to the Rust community.

mustache_kimono5• 4 years ago

Gosh, every Rust post feels like Thanksgiving dinner. Let's settle down.

... if we used all the effort gong (sic) to develop Rust and port everything over to Rust to instead just improve the wrinkles that exist in C++.

If you read the tweet, you might notice Mr. Russinovich isn't actually advocating porting everything to Rust. If you'd care to explain how one might iron out the little wrinkles in C++, you have a captive audience.

dodobirdlord3• 4 years ago

Most of the worst issues with C++ can't actually be fixed without backwards incompatible changes that would break large amounts of existing code. Google spent several years advocating for the approach that you're suggesting, but was unable to persuade other members of the C++ standards committee and recently announced that they're working on a replacement language. The rationale for Carbon goes into great detail on why fixing C++ isn't a viable option.

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

https://github.com/carbon-language/carbon-lang

jimbob452• 4 years ago

I don’t feel that his opinion is all-encompassing. If Rust is being used in the name of security and reliability, then C/C++ should remain king of game development, where those two aren’t as important.

dleslie7• 4 years ago

C# is the new King of game development.

generichuman3• 4 years ago

Only if you're using Unity / Monogame / other custom game engines that use C# as their scripting language.

Unity (IL2CPP) and Monogame (BRUTE) transpile the C# (byte)code to C++ to be able to deploy to consoles and the C# version they support lags several versions behind.

I don't think we can call C# "the new King of gamedev" until it is officially supported by console makers but it seems unrealistic for a couple of years.

Hopefully C# 7's NativeAOT fixes this (Sony & Nintendo will probably need to ship a runtime for C# for this to happen), I don't want to deal with transpiling stuff, I just want C# support out of the box.

m0llusk2• 4 years ago

Have you tried working with Bevy at all? It's very good: https://bevyengine.org/learn/book/getting-started/ecs/

jimbob452• 4 years ago

Hey, I’m not saying Rust wouldn’t be my first choice for game dev. I’m just pointing out the scope of his opinion.

dleslie7• 4 years ago

What's the asset pipeline story? Is there an editor, even?

What it looks like is another Raylib, Allegro, Ogre, etc; an engine these days can be expected to have tooling for artists and designers first and foremost.

bcrosby95• 4 years ago

I've always wondered, why isn't it important here? Are security researchers just not looking?

Especially for networked games.

gpm8• 4 years ago

Companies are definitely juicer targets, but I'm cynical enough to think that it's largely because it's not the game developers money that is at risk of being stolen, the incentives don't line up to encourage good security practices.

dleslie7• 4 years ago

Game developers generally persist hand to mouth. Rust isn't popular with us simply because there isn't a Unity or Unreal that offers Rust as a first class offering, and so it's up to the rare few who are interested in building engines from bare to build a new one.

tejohnso2• 4 years ago

For the sake of security and reliability.

I just read a few C++ vs Rust comparisons online yesterday and didn't see anything about a significant difference in security or reliability. Mind you the articles weren't very technical.

How is Rust so much more secure and reliable than *modern* C++?

tester756• 4 years ago

I'd pick Rust over "modern" C++

just because I don't have to deal with 15 compilers, 15 IDEs, 15 build systems, decades of language experiments, kind of compiler-flags driven development

41b696ef1113• 4 years ago

The true real win of Rust. Knowing that you are incredibly likely to be able to compile it without any hoops. Random C/C++ project can still be a roll of the dice.

thoweiruo234232• 4 years ago

also, know 50+ "best-use" subsets of C++.

sseagull2• 4 years ago

Give rust a few decades and it will get there.

Remember when python was simple? And you just had setuptools? Popularity breeds complexity and fragmentation.

robotnikman• 4 years ago

I ran into those issues when trying to build some old modding software for a game that was written in C++ (Corsix Mod Studio if anyone is wondering).

I was not able to figure out how to get it to build, maybe someday I'll fire up a VM running XP and whatever version of Visual Studio was popular in 2006 and try again.

rodgerd• 4 years ago

Don't worry, the GNU people are looking to fix that.

woodruffw21• 4 years ago

The primary defining quality of Rust (in a security context) is spatial and temporal memory safety: if you're an ordinary user of Rust, you cannot write code that produces memory corruption.

Modern C++ is really nice (I write mostly C++17 and later for work), and does a great job of obsoleting bug-prone patterns from earlier versions of the language. But it's still very easy to introduce memory corruption (of either sort), especially for less experienced C++ engineers. Some kinds of corruption (like double frees) have become even more common as beginner mistakes, in my experience, thanks to the complex mental model required for move construction (compared to Rust, where moves are statically checked).

throwaway20375• 4 years ago

I would call myself an average C++ programmer. Starting with move semantics in C++11 (very cool!), I found myself frequently making bugs by re-using an "already moved" container (like a vector). I couldn't find any simple way to avoid that mistake. And, from my tooling, it was a hard problem to debug, as are double frees. Do you have any advice to avoid re-using "already moved" containers?

dleslie7• 4 years ago

But you can use code that introduces memory corruption. Plenty of crates make use of unsafe blocks.

imron10• 4 years ago

How is Rust so much more secure and reliable than *modern* C++?

Rust catches things like use-after-free at compile time. *modern* C++ still lets things slip through e.g.

    #include <iostream>
    #include <string>
    #include <string_view>

    int main() {
      std::string s = "Hellooooooooooooooo ";
      std::string_view sv = s + "World\n";
      std::cout << sv;  // oops, use after free
      return 0;
    }

DannyBee3• 4 years ago

If by "slip through", you mean "warns you about by default", then yes it lets it slip through.

  clang++ -std=c++17 test.cc
  a.cc:7:29: warning: object backing the pointer will be 
  destroyed at the end of the full-expression [-Wdangling-gsl]
      std::string_view sv = s + "World\n";
                            ^~~~~~~~~~~~~

In any case, I think the philosophical differences between C++ and Rust are well understood, and the different views of the cost/benefits there are also well understood.

In practice, rust will take over when it convinces enough C++ developers that the tradeoff is worthwhile.

That rarely happens by CTO's, or anyone else, telling everyone they are doing it wrong, but instead by helping people see easier ways of doing things, and ways to get work done faster/etc.

Or, you know, waiting for everyone who does it the old way to die.

ragnot• 4 years ago

I mean I get it. On the other hand you really should know the constructs you are using. std::string_view is essentially a reference to a char array and you are assigning a temporary object (r-value) to it. Standard C++ rules say that you can't expect the lifetime of that object hold past the expression.

dodobirdlord3• 4 years ago

Memory unsafety makes securing large codebases difficult because even minor errors in unimportant parts of a codebase have the potential to compromise an entire binary if an attacker can figure out how to get execution to reach the unsafe code and exploit it. Human code review is fallible and junior engineers exist, so if you want to be confidant that your codebase is free of such vulnerabilities you need to depend on static analysis. Rust makes this a lot easier because a lot of the guarantees you'd want to make using static analysis on your C/C++ codebase are built into the language, and the language helpfully flags for you the sections of code that need careful human scrutiny.

pornel6• 4 years ago

The type system can express thread-safety.

If you try to touch a data structure from a wrong thread, it will stop you at compile time. You don't need to fuzz such problems under a sanitizer. You have a compile-time guarantee for your entire codebase and even your dependencies. If you try to use a thread-unsafe library from a parallelized code, it won't compile, and it will show you exactly which field of which struct needs to be wrapped in atomic or mutex to work (at this point people say "but what about deadlocks!?". They are very easy to track down compared to heisenbug memory corruption.)

This makes parallelization of code relatively easy and way more reliable. Rust markets this as "Fearless concurrency".

ModernMech6• 4 years ago

Using modern C++ is like walking a tightrope. If you stay within the constraints, you'll do mostly fine. But it's a fine balancing act and there's a steep cliff to fall off if you don't pay enough attention.

Look at it from the perspective of someone brand new to C++. How do they know what is "modern" and the right way to do things, versus "legacy" and the wrong way to do things? As a beginner, there are thousands of resources available to you on the internet -- some new, some decades old -- with code of varying quality that may or may not be "modern". All of it is valid C++ and will compile, but some of it may have footguns that are nonobvious to the new programmer. There's no "modern only" compiler that will reject said footguns, because C++ takes the position that leaving the footguns there is a feature.

This isn't the case with Rust. Maybe it will become more like C++ in the future as the language changes, only time can tell. But for now, code that compiles in Rust is guaranteed to be free from various classes of bugs that still are possible to compile in C++, despite "modern" C++ having fixed various issues.

Another way of saying this is that "just use modern C++" is a variation of "you're holding it wrong" or "just don't write buggy code", which has proven not to be scalable advice that leads to safer software.

ReactiveJelly5• 4 years ago

Someone else downthread: "young developers can pick up Rust quite fast, and that makes it vastly easier than trying to find talented C/C++ developers."

I hope so. I have a hypothesis that the big-O for language success is "How easily can new programmers learn it?" Nothing else matter. JavaScript was slow, but everyone learned it, so it got fast. Python still had bad tooling, but everyone learned it, so it got better. And C got popular in the first place cause it was easier than assembly.

I wanna ask my managers if we could try hiring Rust devs. I don't like hiring people fresh out of college, but I can't manifest more money to hire experienced C++ devs. If the pool of good-enough-Rust devs is growing faster, and maybe already bigger than the good-enough-C++ pool, why am we interviewing people who don't even know what they don't know about C++?

bitL4• 4 years ago

Dunno. Young devs can pick basic Rust constructs fast but when it comes to complicated stuff where performance is critical... There must be raw talent and lot of grind. IMO it's easier to write super complex stuff in C++ than in Rust as there are just too many cognitive things to keep in mind in Rust to even compile. C++ for talented folks makes life easier there. Like JavaScript, yet another language written for bad to average developers to keep them from shooting themselves in the foot.

adamnemecek2• 4 years ago

The complicated stuff is only on compile time. Unlike C++ where the complicated stuff is metastasized between compile time and run time.

Also the truly tricky things in Rust are relatively few and can be escaped with an unsafe.

crabbygrabby• 4 years ago

Really interesting take, I've had the opposite experience. I've also seen very talented c++ devs screw things up in prod that rust doesn't even allow for. Really recommend taking it more seriously, it's fun once you get a handle on it. Also the tooling is really good now.

thoweiruo234232• 4 years ago

However, without a lot of experience, C++ code often turns out to be surprisingly slow.

idontpost• 4 years ago

Like JavaScript, yet another language written for bad to average developers to keep them from shooting themselves in the foot.

I can't imagine anyone ever describing vanilla JavaScript this way.

Klonoar• 4 years ago

IMO it's easier to write super complex stuff in C++ than in Rust as there are just too many cognitive things to keep in mind in Rust to even compile.

Surely you can describe this with more than a throwaway sentence, given that more and more people are seeming to experience the opposite.

Like JavaScript, yet another language written for bad to average developers to keep them from shooting themselves in the foot.

Nobody would describe JS this way - the entire existence of that language is filled with projects attempting to make it better for "bad to average developers" because it is certainly not what you're describing.

Edit: minor formatting of quotes.

josephg• 4 years ago

in Rust as there are just too many cognitive things to keep in mind in Rust to even compile.

That hasn’t been my experience. Rust (the language) doesn’t seem to get any more complex as programs get bigger. Lifetimes, while complex in isolation, tend to compose really well.

Most of the pain of learning rust seems to be experienced up front. (Well, other than async but I don’t consider that ready yet).

In comparison, my experience of C++ was that it has way more “spooky action at a distance”. A bug in one part of the code will cause problems in another totally unrelated part of the code. I’ve had memory bugs in C++ which took weeks to track down. Maybe C++ has gotten better - I haven’t touched it in over a decade. I haven’t wanted to. And I can’t see many reasons I’d pick it up now that I know rust.

chocolatemario• 4 years ago

When you say JavaScript, do you mean java? Rust undoubtedly raises the floor which is great, but designing scalable systems that enable new members to ramp up is a timeless skill independent of language.

As someone who isn’t a rust native but an interested outsider, it can obviously be cumbersome to use on my pet projects compared to something like python, js, c# or C. Dealing with references to generically types traits adds a lot of syntactical burden (re: shit for me to type) and defining types and their implementations leaves something to be desired regarding its grammars.

That being said, my toy programs do not require particularly complex types and the rust compiler is nothing short of a brilliant. The book is a surprisingly easy read, the module system is fine, cargo is decent out of the box, and there is an interesting mix of paradigms in the language itself. In my mind, the power of the compiler is certainly the big feature of rust and that compilers input language is decent enough such that I wouldn’t dislike using it as a daily driver.

stormbrew3• 4 years ago

IMO it's easier to write super complex stuff in C++ than in Rust as there are just too many cognitive things to keep in mind in Rust to even compile.

It keeps you from compiling (many of) the bugs you'll happily write and deploy in C++. I don't think there's really much practical difference in "cognitive load" between modern C++ (which is painfully complex in ways that are largely not even useful) and rust. C++ just lets you pretend it's lower and you ship more bugs.

Imo, writing rust is like the best parts of writing C++ with a stern but helpful assistant.

Ar-Curunir5• 4 years ago

It's not easier to write "super complex stuff" in C++ than in Rust, precisely because C++ has much more cruft that the compiler can't check for you.

And so what if Rust is lowering the bar for entry to systems programming? I'd much rather fresh ideas and fresh blood enter the field, than it slowly dying as the only people with arcane C/C++ knowledge slowly retire/die.

howinteresting6• 4 years ago

In complex apps and services, Rust is generally faster than C++ because (especially over the long term, as there's churn in teams) C++ developers copy around stuff way more than necessary.

tdeck• 4 years ago

Are new devs less likely to screw things up in Rust? Probably. Is a modern Rust codebase easier to onboard with than a 40 year old monstrosity of a Microsoft C++ codebase? You bet! Are more people excited about learning Rust? Probably. Is rust much faster to learn than C++? Call me a skeptic.

I've written Rust professionally and would rather write Rust than C++. That said, almost every concept you need to understand C++ is also needed to understand Rust, but then Rust adds additional complex semantics that aren't going to be intuitive to novices and don't trivially map to either other common high-level languages or obvious low-level concepts.

jnwatson• 4 years ago

You don’t have to know about exception safety, move semantics, meta-template higgery jiggery, or the 30 years of cruft that C++ has accumulated.

Good riddance.

ReactiveJelly5• 4 years ago

Well, our C++ codebase has a lot of threads that talk a lot, and buffers we'd rather not copy. Plus ad-hoc NIH versions of stuff that exists in Rust's stdlib, like mpsc, or ad-hoc NIH versions of popular crates, like for logging.

I sometimes just wish I could punt to Tokio. Why am I managing threads? Threads are an implementation detail!

I see it as, Rust tells you about the complexity and helps you with it. C++ waits until you trip on it, and then tells you to use Valgrind.

I could be wrong, though. Or I could be 5 years too early.

est312• 4 years ago

That said, almost every concept you need to understand C++ is also needed to understand Rust

I agree that many basic C++ concepts are also present in Rust, but C++ is more than just its basic concepts: it's a huge set of features on top of those that interact with each other in complicated ways. Like how constructors aren't functions but something very special. If you just want to be a beginner C++ dev who works alone on their piece of software that doesn't have any dependencies, you can be fine, you just use the subset you are familiar with. But if you want to maintain other people's code, you need to fully understand what it is doing, the C++ features it's using. Rust's whole feature surface is absolutely smaller than that of C++, and the features that exist integrate way better than the C++ features.

Plus, if there is a gap or misconception in your knowledge, in Rust you would get a compiler error, often very well explained. In C++ you would get a segfault, often not a really nice one.

Ar-Curunir5• 4 years ago

Unlike C++, the Rust compiler actually helps you when you encounter those complex concepts, first by refusing to compile in tricky situations, and then by providing helpful suggestions.

quickthrower22• 4 years ago

Another option is get your existing devs to learn Rust. I think people would be more happy to do that than learn C/C++.

foomatic3• 4 years ago

Why not just hire good people and ask them to learn C++. I mean how the heck did anyone actually pass this magic barrier of becoming a "C++ dev" in order to get hired as a C++ dev?

diego_moita• 4 years ago

Because, little by little, C++ became "unlearnable".

Long ago C++ made C a little bit more complex. Because there were already lots of C programmers that wasn't a big deal.

But then it didn't stop. Little by little C++ grew into a monstrosity. A lot of people went along. I gave up.

For new programmers to climb in 2-3 years a mountain that seasoned programmers took 15-20 years to climb is asking too much.

ReactiveJelly5• 4 years ago

Cause those person-hours have to come from somewhere.

Am I spending 2x of the new hire's time making them learn a harder language? Am I spending 2x of a senior's time teaching the new hire?

What's the payoff in sticking with C++? Better libraries? Better tools? IDEs? That stuff will all shift as time goes on, if popularity is against it.

hardwaregeek• 4 years ago

Because “just hire good people” is on par with “just hire good pilots”. Easier said than done.

lbriner3• 4 years ago

This is a common fallacy imho that if I am a good dev, I can easily cross-train.

I have been writing C# almost exclusively for around 20 years and I am still learning tricks/tips/gotchas and not just for new language features. That is why my experience is important. Even in something like Java which looks very similar to C#, it takes a long time to work out what works differently, good patterns and idioms, the correct libraries that everyone uses for stuff etc. even when I know what I am looking for.

When I looked at Rust, I got some of it because I have previously written C and C++ and didn't have a problem with the concept of pointers or references but it still took me several weeks to get a basic example working and I had to ask on a forum in the end.

So yeah, not easy!

Cthulhu_2• 4 years ago

I mean I could learn C++, but I don't wanna. I did some of it back in school (game development) and I don't particularly care for it. I don't want to do memory management myself or even have to worry about it.

noobermin2• 4 years ago

Ok, so I hate to be too direct but the rust enthusiasm always struck me as annoying like the meme about arch users telling everyone they use arch and so should you, but on that token, I always felt it strange given it's literally over something as mundane as a programming language choice. BUT, this as a reason seems to explain a lot more for why evangelists, particularly those in management type positions in large IT companies are pushing rust so much. Wanting to weaken the economic position of a certain type of developer makes a lot more sense.

woodruffw21• 4 years ago

Wanting to weaken the economic position of a certain type of developer makes a lot more sense.

Just more anecdata, but this isn't true for my company. We're hiring for Rust because we're seeing more and more clients take memory safety seriously (and ask specifically about it as a design consideration).

These things have a way of balancing themselves out: developers like Rust, so there will probably be an eventual "glut" of Rust programmers like there was for C++ programmers in the 1990s. But it's a multiparadigm language, so I don't expect there to be consistent wage deflation based on that (and especially not in systems, where finding competent engineers is a perennial problem).

Ar-Curunir5• 4 years ago

No Rust Evangelist is out there thinking, "Hm, how do I put C/C++ developers out of business today"

IshKebab2• 4 years ago

I love that you can't accept the possibility that Rust is good so much that you had to come up with a genuine conspiracy theory to explain its popularity.

cercatrova4• 4 years ago

Surely you're joking, because I simply refuse to believe that you think Rust developers are actually sitting around thinking how to put other devs out of a job instead of, you know, using Rust simply because it's a better, more well designed language.

spion• 4 years ago

I'd actually prefer a GCed language, but Rust gets so many of the other things right that its still better than anything I've seen before (despite forcing a borrow checker on me).

sophacles9• 4 years ago

Buggy whip manufacturers were also concerned that the car was just a conspiracy to drive them out of business.

ransom1538• 4 years ago

You can find good C++ devs, if ySegmentation fault.

bitwize• 4 years ago

Yep. C and C++ devs, Rust really isn't for you; it's for your replacement.

lionkor• 4 years ago

Ahhh, okay, good. Am in the process of learning it, but I think I'll stop and get ready to be replaced instead. After all, being in my 20's, ive become too old to "get it".

hungrygs• 4 years ago

Umm, no thanks.

TedShiller• 4 years ago

Has he ever heard of kernels or device drivers? Probably not.

malkia• 4 years ago

Most likely yes, check SysInternals and Windows Internals books.

weakfish• 4 years ago

Google his name

atonse• 4 years ago

Love this comment so much. Almost ranks up there with the one where someone tried to explain to cperciva about that award and he was a recipient.

dang• 4 years ago

Hey, could you please stop posting unsubstantive comments to HN? You've been doing it a lot, unfortunately, and we have to ban that sort of account because it's not what this site is for and destroys what is for.

If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.

whb07• 4 years ago

Inside Azure there’s an over reliance to C#, and the older versions of it to boot! So one team in charge of making .NET run faster and better, while the other one drags on using decade old versions

Then for “speed” there’s weird mashups of C++ and C# that are just littered with terrible internal build tools that harken back to a nice 2010s and the idea of:

“Idk it builds in my machine just fine”

As far as Rust goes, it’s as plentiful as F# projects (so not existing).

But that’s just what my close friend says at least.

origin_path• 4 years ago

This ^^

Really, anyone senior in Microsoft shouldn't be making this sort of argument. They already have a perfectly fine memory safe language that they could use way more widely than they already do. The number of bugs in Windows that either shouldn't happen or are too hard to debug when they do, because Microsoft insist on still using C++ instead of C#, is just phenomenal. Why can Google ship a mobile OS in which large chunks including the entire GUI layer run on a JVM, but Microsoft can't ship memory safe code in Windows for even the non-performance sensitive parts because they have some irrational fear of C#?

The issues there are obviously cultural. If Rust is hard-man enough to convince Microsoft devs to adopt it when they otherwise reject C# then fine, whatever, do what it takes. But to generalize this to the rest of the software industry is silly. Most of us have been writing code in memory safe languages for a very long time, and they could be used way more widely than they are. If you want to make more code memory safe you'd be better off advancing .NET ngen or JVM AOT at this point than pushing Rust, at least they can handle arbitrary data structures in safe ways.

jcelerier6• 4 years ago

Why can Google ship a mobile OS in which large chunks including the entire GUI layer run on a JVM

I'm sorry but what the fuck. I paid my fucking phone 1k€ and yet it's bewilderingly slower than a RPi4 with a native apps stack. Every single interaction in the UI is slow and has some amount of lag, even with a 120fps screen. Android is to me the very best argument against Java there is - who knows how many tens of thousands of man-hours spent into optimizing it and it just does not perform to any acceptable level even with best in class hardware. It also has the most app crashes I have seen on any platform.

m0llusk2• 4 years ago

The volume of existing C, C++, Objective-C, and C# code is phenomenal. Even if this strategy is generally adopted there will continue to be lots of this legacy code for many years to come. In particular there will continue to be such legacy code right up until 2038 at least.

solomatov2• 4 years ago

The old C/C++ and other code in popular languages is forever with us. Look at what happened to COBOL, it's still relevant and IMO, will be relevant in 20 years.

synergy205• 4 years ago

carbon, and the newly announced alpha stage efforts called cppfront, can potentially act as a "typescript" for c++, new compiler can enforce memory safety at an upper layer before they're converted to c++, maybe there is hope for c/c++ code for years to come as long as they keep fixing issues along the way.

solomatov2• 4 years ago

Having written enough Rust code, I could bet that it won't be an easy task to rewrite C/C++ code with a borrow checked language. You just need to write code differently for this approach to work.

kllrnohj4• 4 years ago

Is anyone attempting to do the same with C though? Carbon & cppfront, if successful, would only "save" C++. C would still be left out to dry. Then again, the C committee is also pretty much phoning it in and has been for quite a while now.

Gigachad4• 4 years ago

There is still shitloads of COBOL code in use. And we still consider it depreciated and not suitable for new projects.

13of40• 4 years ago

"for those scenarios where a non-GC language is required"

C# code is out of scope for this discussion.

quickthrower22• 4 years ago

Sure

CameronNemo3• 4 years ago

Even more of a reason to implore a moratorium immediately.

1970-01-012• 4 years ago

Is he actually doing it? Making a plan and a policy to replace the bone marrow of MS with Rust? Or is this just a pie in the sky tweet? I don't know what Mark is like as a CTO, so I really don't know what to expect here.

sanxiyn7• 4 years ago

Which part of "new projects" did you miss?

cutierust4• 4 years ago

He stopped reading after Microsoft with his head racing hard to somehow bring them down

1970-01-012• 4 years ago

Without a roadmap, plan, and policy, I read this as a "maybe someday" tweet. Seems like something Elon Musk would say.

ncmncm25• 4 years ago

I really don't know what to expect here.

I do. This is Microsoft.

encryptluks23• 4 years ago

LOL... Two of the most successful Windows tools I've seen in a long time are both written primarily in C/C++. Winget and Windows Terminal. Please let me know when Microsoft has a major Rust-win, because so far they haven't.

kayson• 4 years ago

Can you even use Rust for Windows GUI programming? Is it a practical choice at all for interfaces?

Gigachad4• 4 years ago

GUI code is fine with garbage collection. So it still fits with his message.

supernovae• 4 years ago

azure doesn’t run a gui

jiggawatts2• 4 years ago

In theory yes, but there's a lot of quirks and limitations.

The main issues are:

- Rust string types assume UTF-8, but Windows generally uses double-byte Unicode encodings. The Windows string type isn't even UTF16, because it can include invalid code points. This means that at every API call there will be the overhead of converting the string encodings and having to "deal" with invalid strings somehow.

- Rust compilation is still very slow. In C++, it was a simple matter of including "windows.h" and then start typing code. In Rust, trying to do this naively would result in terrible "inner loop" for the developers. There are some fixes, but they're fiddly.

- Enormous API surface with missing metadata. This is a problem with Rust-to-C interop in general, but the Win32 APIs are so huge that it's impractical to solve manually. There have been efforts by Microsoft to produce official and authoritative interface definitions with additional metadata such as tagging "in" and "out" parameters, etc... This isn't sufficient for Rust, which has a much more complex type system than vanilla C pointers. E.g.: lifetimes, non-null by default, etc...

At this time, programming in Rust for Windows is basically writing C++ code in Rust syntax, but with a slower compile time than C++ would have. Arguably, there isn't even much of a safety benefit, because that would require an extensive set of "shims" to be produced to make Win32 act more like Rust and less like C/C++. Take a look at the size of the .NET Framework standard library to get an idea of what that entails. Not impossible, but not a trivial effort either!

The best and most authoritative bindings are: https://github.com/microsoft/windows-rs

The "demo" looks okay at first glance:

    unsafe {
        let event = CreateEventW(None, true, false, None)?;
        SetEvent(event).ok()?;
        WaitForSingleObject(event, 0);
        CloseHandle(event).ok()?;

        MessageBoxA(None, s!("Ansi"), s!("Caption"), MB_OK);
        MessageBoxW(None, w!("Wide"), w!("Caption"), MB_OK);
    }

But if you start digging deeper into callbacks that manipulate structures that include hideous things such as lists of strings separated by null bytes, you're back in "the weeds" just like with C/C++.

cutierust4• 4 years ago

Pretty sure most win32 now has an alternative utf8 function?

becurious• 4 years ago

I tried to spin up a project with the Microsoft Rust bindings but for what I needed (DirectX12) there’s a lot of necessary helpers in the header files that haven’t got ported over there. And working from one of the samples it was nowhere near as reliable as the C++ version. Beyond ‘oh the C++ code isn’t catching errors’ - every HRESULT was checked as it was using the WinRT bindings.

Kenny Kerr has done an excellent job with both the C++ and Rust bindings, but the Rust one isn’t there yet.

What I’d like to see is more use of a WinMD style metadata for the ABI for functions in DLLs you create. It would be quite simple to define a Span type that could then be imported and called safely from a diverse range of FFIs. I really shouldn’t be having to declare the ABI all over again with ctypes in Python.

bzxcvbn• 4 years ago

I'd imagine that he would recommend C# for GUI programming.

0x4573• 4 years ago

No, it isn't. Yes, you can make Windows or macOS or Linux GUI in rust. Yes, there are options, but:

- ecosystem for GUI is weak

- Can't' imagine using anything, but relm or gtk-rs

- Existing GUI paradigms don't work well in Rust at all

As much as I love writing rust, I would rather write "core" in rust and link with it from something else for GUI.

ghoward27• 4 years ago

Unless he means that Rust should be used on projects where the Rust compiler is available for all relevant platforms and C and C++ can be used otherwise, I disagree.

In fact, until LLVM is replaced, C++ will probably be the language of choice for new languages. Even `rustc` requires a C++ bootstrap for that purpose.

There are also other important C++ and C libraries that will continue to mean C and C++ may be better choices than Rust in certain cases.

And don't get me started on embedded.

Also, that doesn't even matter when the purpose is a hobby project (such as mine) where the programmer has no interest in Rust (such as me).

I like how Trevor Jim put it [1] better:

If you decide to write your project in C/C++ you must have a plan for handling the inevitable memory corruption in advance. Anything else is malpractice.

This is possible to do. I've released a non-trivial program that has had no known memory bugs ever since 1.0 on 2018-10-26. It is written in C. And I challenge anyone to find one in any release since then. You might find one, but I think it will be tough.

In other words, it's possible to put C and C++ on the same footing as Rust when it comes to memory bugs; after all, even Rust is not perfect there.

Yes, it takes more effort. A lot more effort. For my hobby projects, that works fine because I'd rather work in C with the extra effort than in Rust.

Oh, and it's possible to make C as good as Rust: I've got macros to do automatic bounds checking. I've got RAII and stack traces. I've got structured concurrency, which will give the same capabilities as the Rust borrow checker if you adjust your coding style. And all this in portable C11.

So no, Rust is not the end-all be-all of languages. Sorry.

Rant about absolutist opinion over.

But seriously, use Rust if it's available for your target platforms, and you have no other preference.

[1] http://trevorjim.com/using-an-unsafe-language-is-a-design-fl...

customkitchen2• 4 years ago

If we are offering absolutist opinions, I would like to offer a counterpoint.

I've got macros to do automatic bounds checking. I've got RAII and stack traces. I've got structured concurrency, which will give the same capabilities as the Rust borrow checker if you adjust your coding style. And all this in portable C11.

You can do this all in C but it is an absolute nightmare. Every large C program grows some strange bespoke and incompatible versions of all that stuff at some point. And they're all a pain to use because none of it is idiomatic to the language. It's seriously awful. Things like the Linux kernel are the worst offenders. I will be happy when the C language finally reaches the end of its miserable, slow, agonizing death.

ghoward27• 4 years ago

I understand you think it's awful, but I do like it. Everyone has their preference.

synergy205• 4 years ago

"Oh, and it's possible to make C as good as Rust", do you have some concrete advice documented somewhere? Thanks!

mmis1000• 4 years ago

Probably write it in Rust first and make a direct C port based on it? (Or is there a tool do this automatically already?)

ghoward27• 4 years ago

I hate to admit this, but it took me a long time to do, mostly because I was not experienced when I started writing code, and the code has been rewritten several times over to get it right.

First off is the code in [1]. It's technically under several licenses, but I can give it to you under the public domain because bounds checking in C is important enough that I'll give it away.

The `y_ARRAY_TYPE()` macro generates a struct that is an array with bounds. Use it like this:

    typedef y_ARRAY_TYPE(uint32_t) uint32_t_arr;

`uint32_t_arr` is a bounded array of `uint32_t`'s.

You can then pass that array to functions and do bounds checks with the `y_i()` macro (for when the struct value is not a pointer) and the `y_ip()` macro (for when the struct value is a pointer).

To implement RAII, the code to do that is in the same repo, but it's...much more complicated: a full stack allocator. I just add the destructor as a parameter when allocating memory, and when the allocation is freed, the destructor is called when it's non-NULL. Then there are functions to allocate and free, but it is always done in a stack, to emulate the real stack.

By the way, the type of destructor is

    void (*y_Destructor)(void*)

and it takes a pointer to the item to be destroyed.

Structured concurrency takes the idea of a thread-local stack and sort of generalizes it across threads. The idea is that each thread has a parent, and that parent is not joined until all of its child threads are joined. All threads form a tree, almost exactly like process trees in Linux.

This means that if you want to have another thread borrow an item, you just have to make sure that thread is a descendant of the thread it is borrowing the item from, and you have a guarantee that the item will never go out of scope before the borrowing thread does.

Sometimes you need to change your code to do that. You can "push" things "down the stack" by passing function pointer callbacks to callees who then create the item to borrow and call the callbacks. Inside the callbacks, the borrowed item will always exist.

There's more to it than that (you can turn a thread tree into a DAG [2], allowing you to turn threads that are not descendants of a thread into descendants), but that's probably good enough to start you off.

[1] https://git.yzena.com/Yzena/Yc/src/commit/cf4c96b3560d/inclu...

[2] https://lobste.rs/s/8msejg/notes_on_structured_concurrency_g...

snovv_crash10• 4 years ago

Write a full unit and functional test suite and run them with asan, tsan, msan and maybe valgrind. This has caught all the memory bugs before getting to production in my experience.

You need the test suite to verify that your code does what you think it does anyways, the sanitizers are just a nice bonus to verify that it also has the safety you think it does.

drivebycomment2• 4 years ago

In other words, it's possible to put C and C++ on the same footing as Rust when it comes to memory bugs;

No. This is only true if you don't care about occasional bugs. e.g. hobby projects. But if you're talking about mission-critical or security-critical software, there is a gap - or a canyon - between C vs C++ vs Rust. And no amount of extra "efforts" by the programmer's part can bridge those gaps completely.

ghoward27• 4 years ago

The true test of what I said is "show me the code."

The code is my `bc`. [1]

Find a memory bug, any memory bug, in my `bc` after 1.0.

Rust has occasional memory bugs too; I mentioned that specifically. It still happens.

So if you really are correct, break my `bc`.

[1] https://git.yzena.com/gavin/bc

blub3• 4 years ago

Mission critical is almost meaningless when applied to the entire software industry. It’s whatever each company wrote their core software in. For twitter Ruby was mission critical, for Facebook it was PHP.

Security critical is also rather meaningless, because the idea that a specific language must be used to write secure software is something that the Rust community is claiming but is otherwise unproven and not particularly popular as an opinion. In fact I’ve seen many counters that nearly any GC language offers the same security guarantees as Rust.

Finally, there’s the mighty inconvenient fact that a large amount of safety-critical software (a well-defined term and domain!) is written in C and C++ with a track record of multiple decades while Rust is completely unproven.

howinteresting6• 4 years ago

No one's talking about your personal project here. The audience is teams of people building software to be used in production.

ghoward27• 4 years ago

Except that the tweet was pretty absolute. He could have had a reply tweet with something like "unless you have to or you're doing a hobby project." I took issue with the absolutism.

1500100900• 4 years ago

Gavin's personal project is being used in production.

alkonaut4• 4 years ago

Oh, and it's possible to make C as good as Rust: I've got macros to do automatic bounds checking.

The really tricky macro though comes when you want to check races in shared mutable state...

ghoward27• 4 years ago

No macros. This is one spot where Rust is better than C. (Though it is too limiting for my taste.)

Instead, I use ThreadSanitizer and add locks where I may not even need them. Then I may remove some, or change them to different synchronization primitives, and between every change, run TSan several hundred of thousands of times to tease out any race conditions. It's my way of fuzzing for race conditions.

hota_mazi• 4 years ago

To save you a click to Twitter's hyper slow website, Russinovich recommends to start new projects in Rust instead.

martin1975• 4 years ago

If only IBM can get Rust working on AIX..... we may even start using it. Rust is an able C/C++ replacement. Even Linus, who's picky about what goes into the kernel tree, is allowing/supporting it. It really shouldn't be a burden to pick up for anyone who's done C/C++, IMHO.

sanxiyn7• 4 years ago

I have a good news for you. Recently, two IBM employees appeared on Rust's issue tracker and reported their intention to port Rust to AIX.

https://github.com/rust-lang/compiler-team/issues/553

shmerl2• 4 years ago

Very reasonable suggestion.

krasin• 4 years ago

It's also time to have a spec & alternative free implementation for Rust. Multiple compilers and standard library implementations for C is the reason why it's so ubiquitous in the embedded space and where Rust can do a lot of positive impact.

As of now, Rust does not have a spec: https://users.rust-lang.org/t/where-is-the-rust-language-spe...

woodruffw21• 4 years ago

Multiple compilers and standard library implementations for C is the reason why it's so ubiquitous in the embedded space and where Rust can do a lot of positive impact.

I agree that Rust needs a specification, but this is post-hoc: C is popular in embedded because it's the systems programming language that survived the 1970s and 1980s, in no small part thanks to the GNU project.

sanxiyn7• 4 years ago

People are working on it, here is a draft: https://spec.ferrocene.dev/

rychco• 4 years ago

I'm hopeful for other alternatives like Zig too

andrewmcwatters• 4 years ago

I wish technical people would stop pretending that choice of programming language isn't just largely very much a personal choice and then occasionally based on whatever else the ecosystem has to offer.

Yeah, most people doing scientific computing might use Python, but then you have whole groups of people who are used to something else and would plainly prefer not to use a language for completely personal reasons.

Like, hey maybe the syntax sucks.

shadowgovt3• 4 years ago

I find that practically speaking, 80 to 90% of the decision-making and what language to use boils down to what one is trying to do and what examples one can find of somebody doing something similar. For medium to large scale software, ecosystem matters most because when you get stuck you don't want to be reinventing wheels that other people have already solved.

I have definitely, for example, used Java in a project where I would rather walk on hot coals than add more Java to the world... Except the project was to write a second webserver that included all the accreted wisdom the company had built up over the years and we already had a first one written in Java.

The pain of adding more Java was offset by avoiding the pain of having to explain to a vice president how the company got hacked a second time in the exact same way we got hacked 5 years ago...

pie_flavor2• 4 years ago

One's lived experience may be that all languages are roughly the same, but that's only because one tends to only sink time into languages roughly the same as the ones they're familiar with. Something like 70% of languages have been derivatives of Java since Java was invented, but if you cannot imagine how programming could change meaningfully from Java then you are not trying hard enough. (In particular nobody who has learned a functional language, especially Haskell, would express this opinion.) Rust is a meaningfully different language, fundamentally requiring a different approach to design while offering much more power.

tmtvl• 4 years ago

As a fan of S-expressions, yes I prefer certain languages over others simply because of syntax.

After all, isn't that why all the "safety over all" people are switching to Rust now rather than Ada 20 years ago?

UncleMeat3• 4 years ago

I believe that this is true in almost all situations. Using Java vs Scheme vs Python vs whatever is a personal choice that will likely have only modest impacts on the eventual quality of the system.

But the cost of unsafety in C++ is often a vuln. This makes it a meaningfully different choice.

benbenolson• 4 years ago

No, I’m going to write everything in C.

hgs3• 4 years ago

I tried Rust about five years ago and I had trouble expressing cyclic data structures because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap. I was rather put off by this: Instead of juggling pointers I was juggling integers. It made the code harder to debug and find logic errors. At least when I was troubleshooting C I could rely on the debugger to break on a bad pointer, but finding where an integer became "bad" was more time consuming.

The borrow checker worked fine when all I needed to do was pass data up and down the callstack, but anything beyond that was difficult or impossible to express. Has the borrow checker become smarter since then? At the time I was very put off.

dralley• 4 years ago

Juggling (raw) pointers is still an option in Rust, just not the most idiomatic one. But you're right that expressing cyclic data structures is very challenging to do idiomatically in Rust.

Using integer handles as pointer replacements does have some universal benefits though outside of Rust. You can make them more compact, they serialize more easily, etc.

Fiahil2• 4 years ago

The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap.

What ? Box, Arc (and weak) are exactly made for this.

ajross4• 4 years ago

Box doesn't solve the problem of cyclic references. And telling people they need to eat the overhead of a per-object reference count and/or weak pointer double-dereference just to write a list that can delete items in place is a pretty tall order for a language that claims to be high performance.

No, this is genuinely a big hole in the expressive space of the language. Not a lot of apps really need to do a ton of manual pointer work implementing non-trivial data structures, but some do, and it kinda sucks in Rust.

woodruffw21• 4 years ago

If the last time you tried it was 5 years ago, then you probably didn't experience Rust with non-lexical lifetimes. That was added in around 2018 (IIRC), and radically increased the number of programs that the borrow checker accepted.

That being said, you still can't do "naive" cyclical data structures without some additional assistance. But the ecosystem has matured around that: crates like ouroboros[1] provide safe interfaces for creating self-referential structures and datatypes.

Edit: NLL was indeed added in the 2018 Edition[2].

[1] https://docs.rs/ouroboros/latest/ouroboros/

[2] https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-201...

ChadNauseam• 4 years ago

Ghost-cell [0] also lets you create a doubly-linked lists (without you having to use unsafe code, and with no overhead)

[0] https://crates.io/crates/ghost-cell

ajross4• 4 years ago

That's my take too. Idiomatic Rust is "safe" in the sense that... it disallows most nontrivial data structures. Even a doubly-linked list is impossible to get through the borrow checker.

That's... not really that fatal. There's a lot of very useful code that can be written using only runtime-provided[1] containers and straightforward ownership trees.

But obviously the big problem is that for applications that do need to do non-trivial reference semantics, Rust doesn't really offer much. Applications with nonstandard allocator paradigms or weak-referenced caches or that need to do complicated graph management are mostly on their own in the world of unsafe.

And the somewhat more cynical point is: for applications that can easily fit within standard containers and standard allocation paradigms, C++ actually works really well already. Use your smart pointers. Use your containers. Follow the rules everyone tells you about not using bare new/malloc. And... it's basically just as safe, because anything beyond that would be unsafe in Rust too.

I don't dislike Rust, really. But the space between "Need to stay away from C++" and "Should probably just have written it in Go" seems to be getting smaller and not larger.

[1] Which in Rust, means "written using a ton of unsafe blocks".

peyton• 4 years ago

Agreed, having touched browser development circa Rust’s invention, I think there are some good ideas, but the execution fell flat over the years, orthogonality broke, and thus the utility is kind of limited. I’m more excited about some newer languages to be honest.

noobermin2• 4 years ago

Random question, doesn't this then defeat the whole purpose of using rust? Memory errors, that is, pointer issues are the primary source of errors that ownership in rust claims to fix. If the only way you can make nontrivial data structures is use "a ton of unsafe blocks," then you'll still likely get the memory errors, only now it's in an unsafe block...so, now everyone can just blame the unsafe block?

This reminds me of those static provers which prove everything correct up until user input, you know, the place where an attacker will inject their payload.

lmm4• 4 years ago

And the somewhat more cynical point is: for applications that can easily fit within standard containers and standard allocation paradigms, C++ actually works really well already. Use your smart pointers. Use your containers. Follow the rules everyone tells you about not using bare new/malloc. And... it's basically just as safe, because anything beyond that would be unsafe in Rust too.

If you're perfectly attentive and constantly vigilant, maybe. In practice everyone thinks they're following the rules and everyone messes it up.

Ygg28• 4 years ago

Even a doubly-linked list is impossible to get through the borrow checker.

https://github.com/rust-lang/rust/blob/master/library/alloc/...

It's part of standard lib. And you don't get more idiomatic than that.

petre• 4 years ago

But the space between "Need to stay away from C++" and "Should probably just have written it in Go" seems to be getting smaller and not larger.

We also have D which can use C/C++ libraries seamlessly.

roca2• 4 years ago

the big problem is that for applications that do need to do non-trivial reference semantics, Rust doesn't really offer much.

For those applications you can almost always encapsulate the unsafe code in a data structure library with a safe interface, such that the library is a tiny fraction of the application code. And in many cases someone else already wrote that library. For graphs, for example, there is petgraph.

for applications that can easily fit within standard containers and standard allocation paradigms, C++ actually works really well already

Not at all. For example it is still easy to corrupt memory using C++ references. Just the other day I discovered a nasty little bug involving absl::hash_map: someone had written "map[i] = map[j]" which is unsafe if the element at i does not already exist --- it can trigger a rehash, invalidating the reference obtained by map[j].

selfmodruntime• 4 years ago

Both doubly linked lists and cyclic graphs can be written in a way that satisfies the borrow checker. If not already existing in the STL, there is a crate for it 99% of the time.

pkolaczk• 4 years ago

for applications that can easily fit within standard containers and standard allocation paradigms, C++ actually works really well already. Use your smart pointers. Use your containers. Follow the rules everyone tells you about not using bare new/malloc. And... it's basically just as safe

This is "don't write bugs, lol, and you're safe" argument. It has been demonstrated many, many times on HN, that you can cause UB in C++ using just high-level standard containers and smart pointers, without doing anything suspicious with raw pointers. Bugs of that kind are virtually impossible to detect during a typical code-review. So it is not "just as safe". It is tad safer than C, but nowhere near Rust.

But the space between "Need to stay away from C++" and "Should probably just have written it in Go" seems to be getting smaller and not larger.

That might sound as a rant, but IMHO the designers of Go sadly made some odd choices in areas unrelated to memory management, which put me off from Go. Go is not just Rust with borrow checker replaced by tracing GC. It is a completely different language, with a much different "feel":

* some syntax choices that seem to have no justification other than "we wanted to make it look different than other languages" (ok, one can get used to it)

* no sum types / unions / enums

* code generation / copy pasting instead of proper macros

* error handling not really better than in C (caused by no sum types)

* visibility controlled by character case (so when you want to unprivate sth, you have to find-replace all occurrences; I guess this stupid idea originates from Python)

* unused stuff is hard error (terrible for prototyping)

* you don't need generics, but we've just added them anyways ;d

* no tools for controlling mutability/immutability/sharing (which is still useful in GCed languages)

* data races possible, accidental mutable sharing possible

* no RAII for deterministic destruction of non-memory resources (`defer` doesn't even come close)

* package/dependency management IMHO subpar compared to cargo

When trying to learn Go, I had exactly same feeling as when I first learned Java (after C++) - that the authors of the language designed it for people less capable than the creators themselves. So I didn't like it.

survirtual• 4 years ago

The thing is, once you get it right in Rust it just works very, very well — and it generally works multithreaded with little additional effort.

The language causes you to rethink datastructures that were largely created in a single-core context. You can think up equivalent functionality that satisfies the Rust borrow checker but then also lets you trivially parallelize via something like Rayon.

Rc or Arc work for a double LL if you insist on pointers, or a wrapped owned vector with integer based references if you don’t want the overhead of reference counting. But to say “Rust doesn’t offer X” is just not true; you can build anything but it just takes more work and thought, and it is always worth it given the performance and bug classes automatically eliminated by that extra effort. And with unsafe code, you get bare metal access without the rules.

UncleMeat3• 4 years ago

Modern C++ happily introduces nightmare bugs. Banning "new" from your codebase does not prevent problems.

You can still happily have UAF through references. The adoption of string_view has made this super clear. Arithmetic is still very error prone, with confusing promotion rules and little protection for overflows. Pointer arithmetic is still common - yes even if are using typical containers. What do you think is happening underneath the hood when you increment an iterator? Oh, and iterator invalidation remains a fun way of ending up with unsafe code even if everything looks totally fine.

stouset18• 4 years ago

Seriously, just use unsafe.

“Welp, can’t write a doubly-linked list in safe Rust so I might as well use C” is throwing the baby, the bathtub, and the rest of the greater metro area out with the bathwater.

chongli2• 4 years ago

Sorry to stretch the analogy beyond recognition but a lot of people who would prefer C over Rust want to build a bathtub for the baby without dragging the rest of the greater metro area into the picture.

archi422• 4 years ago

Not a rust dev, but shouldn't this be solvable using generics? At least I'm pretty sure I could construct a double linked list with a sane API using only references in C++ with templates.

I would have used inheritance to create a "ListBaseType" with a "ListElementType" specialization (with all the data required to wrap some element) and an empty "ListNullType" to use as begin/end elements. A quick Google search results in a implementation using "None" instead: https://gist.github.com/matey-jack/3e19b6370c6f7036a9119b79a... (I don't vouch for it!)

In the end the correctness boils down to correctly handling the beginning/end. It does matter little if that's a NULL, None, nullptr or ListNullType.

The real difficulty would be adding thread safety with minimal performance loss.

throwaway20375• 4 years ago

Yes, I felt the same when I read the grandparent post! I am not a Rust nut (nor expert!), but the improvements offered seem very impressive. After reading your post, I immediately went to Google this phrase: "doubly-linked list in safe Rust". Plenty of good and interesting results!

pizza2345• 4 years ago

There are convenient libraries for working with such data structures. Unsafe should be relegated for highly specific us cases.

gpm8• 4 years ago

The borrow checker has become smarter, but not at handling cyclic data structures.

The problem you're describing still exists, though I'd say the advice isn't quite right.

Generally the better advice is to use a graph library, or something like slotmap [1] if you're rolling your own, than to use a Vec or HashMap. That's superior to a vec/hashmap for a few reasons. It handles keeping indicies stable/writing your own index allocator. It also makes it possible with a feature flag to detect all use after frees at low-ish cost (instead of only detecting them if no-one is re-using the slot). It makes it convenient to use typed keys instead of integers. The underlying datastructure is basically the same though.

You can also use Rc/Weak for cyclic data, for ref counting "GC", it's an approach I have less experience with so I can't speak towards it as well.

In the end not that much data is cyclic (especially in idiomatic rust), and this is trading off a small amount of debugging convenience on cyclic data, for guarantees of memory handling correctness in the rest of your code, and for guarantees about the amount of damage that mistakes can do in the code that does need to handle cyclic data (which in turn is a debugging win on cyclic data, so...).

I agree it's a bit of a rough edge, but it's a case where rust solved the easy 95% of the problem with only slightly questionable tradeoffs on the remaining 5%, and that's a win in my book.

[1] https://crates.io/crates/slotmap

lenkite4• 4 years ago

Stuff like Slotmap should be part of the standard library instead of some github project with open issues that isn't updated for over a year.

fulafel2• 4 years ago

What is the advantage of a slotmap style approach vs references? It seems a bit manual and error prone, and the errors risk being silent references to wrong objects that may result in security vulnerabilities or data corruption.

dusklight• 4 years ago

what do most people use for a generic graph / tree library in rust?

adamnemecek2• 4 years ago

Use generational arenas.

jupp0r2• 4 years ago

It's intentionally limiting. If you need an owner, create one (call it a graph struct that holds all you nodes for example). Make lifetime management an explicit and separate concern and unit test it independently. If this is too slow for your performance needs use a library that probably uses unsafe Rust to optimize the parts that matter and that offers safe abstractions for you to interact with. If there's none, roll your own. Be happy that not everybody is slinging dangling pointers all over the place in code where it's really unnecessary.

Noe2097• 4 years ago

Was about to write this exactly. Keep the lifecycle management in a dedicated component. Unsafe seems vastly overkill for dealing with this use case.

I'm even having a hard time seeing how this could be slower than any other alternative. Yes, in the places where creating / deleting is necessary, the "root" structure will have to be passed around, but in the worst case that has the cost of adding one argument to a function (which has the nice side effect of making the lifecycle _visible_).

laserbeam• 4 years ago

Using integers instead of pointers is a cool optimization outside of Rust as well. It lets you serialize data easier (indices are the same when you load data on a different machine, pointers will change) and can use less memory (common choices: 8, 16 or 32 bits per int; 32 or 64 bits per pointer).

This is, however, an optimization. I rarely write my code like that on the first pass. It's something I always have in mind that at some point it's worth replacing the pointers.

(This is not specific to rust, or any other language)

alpaca1282• 4 years ago

While that is true, using integers as pointers in Rust just makes them invisible to the borrow checker. It's a useful trick but one should be aware this is basically unmarked unsafe code.

Though in Rust it has another advantage over pointers: it doesn't force you to suddenly annotate every single type that touches your data structure in any way.

jandrewrogers• 4 years ago

In fairness, using integer handles instead of pointers is pretty idiomatic in high-performance C++ too. I've never found it to be onerous or complicated.

fsloth3• 4 years ago

Yes, using integers is not a handicap in many cases but default way of addressing.

cygx• 4 years ago

Sure. But the selling point of Rust is that the compiler will check ownership and lifetimes for you. That goes away if you use integer handles, in which case I might as well use another language.

ohgodplsno• 4 years ago

Unsafe is literally made for that. For cases when your wants can only be checked by your brain saying "I did the logic and it's all good". Ten lines of unsafe does not mean your program will blow up. If anything, it's here to encourage you to just be much more careful here.

resonious2• 4 years ago

Right, you don't have to be a purist to get safety benefits from Rust. If a Rust program is 1% "unsafe" code, it still has a far lower vulnerable surface area than an equivalent C program.

gernb• 4 years ago

That's a very good point. A pointer dereferences its object, an index does not. So arguably having to switch from pointers to integers is going be a net drag on debugging since it will be no trivial to see what objects are being referenced.

worik• 4 years ago

I had trouble expressing cyclic data structures

You cannot do cyclic data structures in Rust because every thing must have one owner, so no cycles.

You can do cyclic data structures in Rust with unsafe code or doing your own memory management (e.g. an arena data structure).

The borrow checker worked fine when all I needed to do was pass data up and down the callstack, but anything beyond that was difficult or impossible to express

That is not true. It is true at the start of the learning curve, but you get used to it. Cyclic data structures are very far from simple.

bobbylarrybobby• 4 years ago

The data held by an Rc doesn't have one owner. It would probably be pretty painstaking to do cyclic data structures with them correctly, differentiating between strong and weak Rc as appropriate, but probably doable. If you don't care about leaking memory, or if the graph is static, you don't even need to worry about that.

baq7• 4 years ago

Cyclical data structures are difficult to reason about, full stop - not only for the borrow checker.

Unsafe is there if you need it. It gives you C pointers for everyone and their debugger to blow up on. The difference is Rust makes you painfully aware that CS 101 is actually hardcore engineering.

3836293648• 4 years ago

The answer today is to use a GhostCell

pizza2345• 4 years ago

The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap

This is not correct advice; not sure why you've been given this answer.

There are a couple of solutions.

1. you use a data structure (library) that returns you a handler, which can be an int, but it's not an int as in "position inside a vec" (index), but a symbolic reference, whose management is deferred to the library.

You can't use an index directly because if a position is freed, then taken, you will hold an invalid reference (int).

This is a handy solution, convenient to work with; if you do something wrong, you'll get an error from the library.

2. the manual solution is to use strong/weak references, which are quite ugly to use :)

eliben• 4 years ago

I ran into the exact same problem and wrote up some potential solutions at https://eli.thegreenplace.net/2021/rust-data-structures-with...

Narann• 4 years ago

unsafe is the feature you need.

bsg75• 4 years ago

Then Azure should probably get some Rust SDKs: https://azure.microsoft.com/en-us/downloads/

ninefathom4• 4 years ago

There are new programs being written daily in COBOL and Fortran, and I'm fairly certain that I see new PL/I floating around occasionally.

C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time.

Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything is x86, and one of five operating systems" issues as recently as late 2021. Rusties of the world: your language might be ready to take up the mantle of C- it's you and your ecosystem that I question.

If Rusties want Rust to displace C... simplify your dependency chains. Get a build system that's easily workable without an Internet connection and recent TLS support. Make it easy for beginners to build out Rust infrastructure for OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU. Make it feasible to get Rust everywhere that C currently is... then we'll discuss getting rid of C. Until then it's just wind.

humanrebar4• 4 years ago

The fact that Rust has a whole other ecosystem is the main thing that gives me pause. For all their faults, C and C++ targets the ecosystem you have: gems, pip, Conan, Nix, ...doesn't matter. They don't expect you to port to a new ecosystem. They can contort to meet your needs.

Herb Sutter's latest proposal and, to a slightly lesser degree, Carbon are more interesting in that respect.

Ar-Curunir5• 4 years ago

What? You can totally compile Rust for compatibility with python libraries or Ruby libraries or whatever you want. Rust can offer the same API that C/C++ offer, so it can be a drop-in replacement.

pornel6• 4 years ago

C/C++ target a fragmented mess that's different on every platform and inconsistent across projects. Technically you can invoke rustc the same way you invoke cc, and craft makefiles and handle all your dependencies the old way, but it's so tedious and fragile compared to Cargo that nobody wants to.

nicoburns3• 4 years ago

Nope, C and C++ target the C and C++ ecosystem. If that’s the ecosystem you have then presumably that’s because your a C or C++ developer and that’s what you’re used to. Personally I find installing C and especially C++ libraries a massive pain.

lmm4• 4 years ago

If Rusties want Rust to displace C... simplify your dependency chains. Get a build system that's easily workable without an Internet connection and recent TLS support. Make it easy for beginners to build out Rust infrastructure for OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU.

C is welcome to that niche IMO. The priority is getting people to stop using C or C++ for regular applications that are exposed to the internet; if Rust can replace those use cases then it'll be job done.

notacoward• 4 years ago

Most of those applications would probably be just fine with a GC language, so the cognitive load of doing things safely in any non-GC language is probably a waste.

markus_zhang2• 4 years ago

The priority is getting people to stop using C or C++ for regular applications that are exposed to the internet;

But I think this is already been taken care of by Java and others?

WiSaGaN3• 4 years ago

Get a build system that's easily workable without an Internet connection and recent TLS support.

I'll say typing `cargo build --offline` can qualify as "easily workable".

shakna2• 4 years ago

How do you vendor to local, without the recent TLS support?

pitaj4• 4 years ago

C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time.

Nobody denies this, which is why one of Rust's main goals was supporting the C ABI, so Rust can use existing C libraries, or an application written in C can use Rust libraries.

Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything is x86, and one of five operating systems" issues as recently as late 2021.

I am curious. Could you give some more context?

Get a build system that's easily workable without an Internet connection and recent TLS support.

Cargo supports vendoring dependencies and local dependencies.

Make it easy for beginners to build out Rust infrastructure for OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU.

When has it even been easy for beginners to build out systems infrastructure?

Progress is being made on allowing Rust to target more platforms, including `rustc_codegen_gcc` and `gcc-rs`.

imron10• 4 years ago

I am curious. Could you give some more context?

Probably talking about this: https://github.com/pyca/cryptography/issues/5771

spoiler3• 4 years ago

Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything is x86

Anecdotally, I had the same issue recently with a C++ tool I wanted to tun on arm linux (forgot what it was; but it was a WASM tool. I ended up using a Rust alternative that was less mature, but did all I needed anyway)

Lastly, the issue you're describing is more of a DevOps one. C++ has a longer history, and one would hope it has accumulated more DevOps wisdom over that period of time.

ninefathom4• 4 years ago

"one would hope it has accumulated more DevOps wisdom over that period of time"

Yep. My thoughts exactly.

baq7• 4 years ago

beginners
OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU

what?

pie_flavor2• 4 years ago

It's not like it's any different for C. Rust gives you a choice of five operating systems? A given C library gives you a choice of one, on a good day. And if you've got your favorite C library already then binding to it is a breeze. I don't understand the mindset that because Rust and its entire ecosystem is less than perfect it should be junked for C which never even cracked a quarter of the distance.

svnpenn4• 4 years ago

Rusties

please don't

kweingar• 4 years ago

Isn’t the whole shtick with programming language devotees that they have names for themselves like Rusties and Gophers and whatnot

Zanneth• 4 years ago

Can’t be worse than “Rustaceans.”

ninefathom4• 4 years ago

Update:

Based on the comments here, I see that I need to clarify two things, as edits are locked.

First, I actually happen to rather appreciate the Rust language itself. It is both powerful and pragmatic, and has quite a bit to recommend it. Even in situations where its addition has been personally very problematic for me (e.g. Firefox), I can still tip my hat to the added value. What I take strong exception to is Rust evangelism, i.e. the idea that Rust and its ecosystem are clearly superior to all other options in a given use case, and any person using other options must be either insane or uninformed. This represents, at best, a very narrow view of the computing ecosystem in the 21st century. My comment is a rebuke of the evangelism, not the language.

Second, the term "rusties" might have (reasonably) seemed like a label that I applied to any Rust developer. This is not the case, and the perception is a result of my failure to clarify. There is a particular class of person whom one meets, with whom any discussion of any technology project inevitably leads to "well you really should write that in Rust." Such folks- overzealous Rust evangelists- are "rusties" in my vocabulary. If that describes you, feel free to take insult if you like. If that doesn't describe you, then my apologies for any misunderstanding.

snickerbockers4• 4 years ago

Speaking of Microsoft, it's time to halt starting any new projects in Windows and use Linux for those scenarios where an OS kernel is required. For the sake of security and reliability. the industry should declare that OS as deprecated.

tsujamin• 4 years ago

get back to me when there's equivalents of KPP/Credential Guard/a stable driver API/etc

LunaSea• 4 years ago

Do we still have ads in the operating system?

snickerbockers4• 4 years ago

tbh i was mostly being facetious and I don't actually think everybody needs to immediately drop Windows (although i do actually hate it). The OP has the exact same problem that you highlighted with my post, which is the assumption that since rust is a viable replacement for C in his line of work, C must be obsolete across the board for everyone, which is a ridiculously arrogant statement.

Rust's tier 1 platform support is woefully inadequate (https://doc.rust-lang.org/beta/rustc/platform-support.html), and even the tier 3 platform list is missing some important targets. And even the platforms that it works on aren't necessarily platforms where it works well enough to be a viable alternative to C. But this guy from Microsoft's Azure who probably only ever writes software for x86 and ARM says C should be considered deprecated because Rust works really well in his specific domain.

vasama2• 4 years ago

If only Linux offered a half decent kernel API instead of that dumpster fire that is POSIX. Even so, for anything not involving graphical user interfaces I somewhat agree with you.

mempko• 4 years ago

Compare Stepanov's brilliant design of the STL to Rust's current reworking of their 'binary search api'. https://github.com/rust-lang/libs-team/issues/81

Maybe 'memory safety' isn't the most important thing in this world. To me, writing software that does useful things in the simplest and most correct way is what matters. I get the feeling it's harder to understand my program's correctness with Rust (I mean algorithmic correctness). The C++ standard library has time and space complexity for every algorithm. I'm not seeing that's the case with Rust (correct me if I'm wrong).

mustache_kimono5• 4 years ago

To me, writing software that does useful things in the simplest and most correct way is what matters.

Seems like a Rust sweet spot. Could you give another example? Here, it would seem this API proposal wasn't adopted because it wasn't fully baked. Isn't that a good thing?

Discussion re: Rust collections: https://doc.rust-lang.org/std/collections/index.html

virgulino• 4 years ago

You could say that Mark Russinovich is a hacker's hacker, the foremost Windows hacker, and a reverse engineering wizard. It was he who discovered and blew the whistle on the Sony rootkit scandal, for example, after finding and reverse engineering it on his machine.

https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...

He extensively reverse engineered and documented "Windows Internals" details before joining Microsoft (and before being "encouraged" to change the name of his business to Sysinternals).

His writings and talks on "The case of..." are master classes on reverse engineering.

https://youtu.be/GQ1EDqsA1yk

https://techcommunity.microsoft.com/t5/windows-blog-archive/...

I'm paying attention to him.

kramerger2• 4 years ago

Well... He is also written some horrible fiction novels, so the guys is not perfect.

imagine99• 4 years ago

Why would you say that? They are all rated 4+ stars on Amazon (at first glance), so the general consensus is that they are probably not that "horrible".

Personally, I enjoyed them a lot and I am actually a bit bummed that he stopped publishing new ones...

Granted, I probably would not have read them had I not recognised his name on the cover (there is too much cookie-cutter stuff out there). But I did not regret buying them and I remember being impressed by the fact that this guy wrote Syinternals AND engaging fiction...

Ygg28• 4 years ago

Why are fiction novels relevant to field of computer languages? This seems like ad hominem.

blub3• 4 years ago

You seem to be quite well versed in the persona of Mark Russinovich.

Does he still develop the sysinternals tools? Does he program any more or has he settled into the life of an xTO? Rust, C++, what is he using? Did he port all his tools to Rust?

Given that his reputation is in other areas I don’t immediately see what makes his proclamation noteworthy. As someone that read his book and used his tools I’m more puzzled by his statement than motivated to spring into action :-)

cvccvroomvroom• 4 years ago

Almost 15-20 yrs ago, before I deleted my LI profile, he was kind enough to have a look at some random malware at (big name) caught in the wild (because the org dragged its heels into any measurable security) doing actually weird and clever things to hide itself from all manner of scanning tools, including that 4 letter acronym collection package MSFT gave to customers to grab forensics. Back then, they also taught MSFT NT kernel devs for a time how their own stuff worked.

Satya Narayana and company out of Azure are a tribe of forward thinkers who rescued MSFT in the long-term by adapting and embracing without as much extinguishing.

PS: Unnamed yours truly is now around the corner from where Winternals was. Small world.

zerr• 4 years ago

With all due respect, this is coming from a Win32 API C programmer who happens to save the code in files with .cpp extension. In other words, not familiar with modern C++.

aspyct• 4 years ago

What's wrong with .cpp extension?

adrift• 4 years ago

Modern C++ is a scam.

chriswarbo4• 4 years ago

Irrelevant. All the old, problematic approaches are still valid code, and hence from a security perspective they are vulnerabilities. Whether or not you, personally, trigger those vulnerabilities or not doesn't matter: the stack is vulnerable.

Note that you might choose to forbid anything that doesn't count as "modern C++", e.g. by enforced linting. Equivalently, you could instead have your compiler reject such programs (perhaps deciding to rip out various features and modules from the compiler, to avoid them being used). Either way, you're no longer writing C++: you're writing some other language (say, "C+++"), which is a sub-set of C++. In which case, you've done what the author suggested: deprecating C/C++ in favour of something safer!

ygra• 4 years ago

This may be a habit picked up by people writing more-modern-than-C89 C code that also has to be compiled by MSVC. Since MSVC is foremost a C++ compiler it was stuck in C89 for a very long time (I think it's better now, but old habits probably die hard).

user8501• 4 years ago

Seems like kind of a crazy thing to say. The first thing to note, is that we should obviously be free to write software like games and other utilities in whatever language we want, especially if they’re not connected to the internet. Second, why exactly are we demonizing people now? Suddenly declaring a language deprecated not only doesn’t actually make any sense, but also seems like a great way to influence people’s personal opinions about others. I can tell you from experience that sentiments like this breed hostility in the workplace. And finally, this is pretty short-sighted, considering the supply chain attack is clearly the attack of the coming age.

JCWasmx86• 4 years ago

Agreed. And while rust has fantastic ideas, those are frankly often badly executed:

- Static linking of everything

- Big dependency trees that somehow remind me of npm

- Slow compilation, it should reach at least the average speed of C compilation

- Big binaries because of static linking

Before this is solved, I frankly wouldn't even consider touching rust again for personal projects, did it once, and it was an awful experience with too long compile times, as my style of development depends on fast compile-run-test cycles and having to wait around a minute to recompile for a small program is just too much.

jillesvangurp• 4 years ago

Well, he's the CTO at Azure and apparently he's telling his people to avoid using C/C++ for new projects. They no longer have that freedom there because he just told them so. What people do in their spare time is of course their own business.

I believe other big companies have similar reservations about using C/C++ on new projects. And given the cost of cleaning up the security mess that using C/C++ has caused these companies, I can see where they are coming from.

It's not about demonizing people but just a simple, rational business decision to not use C/C++ for new things anymore. We have Rust now and it's capable of delivering the same level of performance as C/C++ but without all the memory leaks, buffer overflows and other costly headaches that a CTO of Azure needs to worry about messing up his business. Not worth it anymore.

People taking things like this personally is unfortunate but more a problem these people have than anything else. I get it, it's not fun having your favorite language - and by extension you - labelled obsolete. Not a nice message to receive.

tekknik• 4 years ago

I work in games for a very large studio, C++ is not going anywhere anytime soon (see Unreal Engine). The vast majority of experience is in C++ and no other language.

Server side services (read outside of Unreal Engine Server) are not written in C++ however.

hackerlight2• 4 years ago

Would Rust be able to replace C++ in HFT?

WiSaGaN3• 4 years ago

If you want the lowest software latency as in "latency arbitrage", then probably not. However, even in HFT industry, there are a lot of software that you want very low latency but would still trade a bit latency in exchange for much better productivity, maintainability, and especially robustness provided by the type system of Rust. You want to be fast, and also want to reduce the possibility of hitting a company-breaking bug in your billion turnover trading system.

hackerlight2• 4 years ago

How much slower would Rust be? If C++ delivers 4us and Java delivers 25us tick to trade for a particular strategy (say, book building, some calculations, then order sending), what could Rust get?

DrBazza• 4 years ago

Not much would have saved Knight Capital and powerpeg. You can write company bankrupting code in any language.

bane• 4 years ago

I just wanted to say how much I love that this community values Mark as a "hacker" above being the CTO of Azure, and then goes on to lists his technical hacking credits.

Hacking is still alive even if we all need paychecks.

stoeckley• 4 years ago

It would seem to me that as long at C++ is the primary language to write for a GPU, it will be a necessary language for new projects for a long time.

up2isomorphism• 4 years ago

I believe sysinternal tool are handy, but it not more useful than core utilities on Linux. Even that doesn’t not give him to ask everyone not to use certain languages.

Obviously geek’s rant is still a rant.

physicsguy• 4 years ago

Blanket statements like this just show that people don’t understand why people stuck with a language.

I worked in C/C++ for a long time, though it’s been a while now. I just went to look at whether Rust had any bindings for MPI. It does - rsmpi. But they’re not fully implemented, and only support a restricted subset of MPI implementations which are pretty much the latest versions. Some others might work, but it is not explicitly tested against them. Without that, there’s a whole class of distributed applications that you’d be ill advised to write in Rust using that library, because it’s such a fundamentally core library for distributed applications, which needs to be compiled differently and with specific versions to handle the specialist interconnects on HPC systems. If you only support the latest versions, your code is not very portable to other machines.

fsloth3• 4 years ago

Generally - yes. But in this case, if you happen to be the CTO of Azure I imagine funds would be available to implement the missing components in Rust ecosystem for projects you lobby to be critical.

resonious2• 4 years ago

Calling C code from Rust directly is not too hard. Yes, you will have to write some unsafe code, but it's better than 100% of your codebase being unsafe (assuming you buy into the idea that Rust's safety features help).

IshKebab2• 4 years ago

I don't think anyone's saying there aren't specific areas where you might need to use another language. You pretty much have to use Python if you want to use ML, or Typescript if you want to do web stuff.

But if you do have the freedom to choose, then I don't see why anyone would really pick C++ over Rust at this point.

lbriner3• 4 years ago

I agree. It's like when MS tell everyone just to "upgrade to dotnet 6" or 7 or whatever!

Most of us don't have the funding, skills, time, priority to rewrite all of our old web forms apps even if we wanted to. Who is going to pay to rewrite the app that only earns us $10K a year?

Even if we did decide that Rust is great, do we immediately expect our C++ senior devs to produce the same quality code in a language they have only just learned? Are we going to recruit some confident youngsters who possibly know Rust but haven't been burned enough times to be pragmatic when implementing it in the wild. Do we want to rely on a new language that ticks lots of boxes but also lacks the understanding/support and battle-testedness of C++?

dan_mctree2• 4 years ago

I agree. It's like when MS tell everyone just to "upgrade to dotnet 6" or 7 or whatever!

The amount of global manhours MS is throwing down the drain by constantly ending support for their versions must be absolutely staggering. Updates are often far from trivial, and they expect everyone to keep up with their fast upgrades and tiny support windows? Long term support is only 3 years, are you kidding me?

M2Ys4U• 4 years ago

Most of us don't have the funding, skills, time, priority to rewrite all of our old web forms apps even if we wanted to. Who is going to pay to rewrite the app that only earns us $10K a year?

He's not suggesting rewriting anything. He explicitly said "it's time to halt starting any new projects in C/C++" (emphasis mine)

C/C++ isn't going away, old C/C++ things can remain as old C/C++ things.

heeen2• 4 years ago

https://www.areweguiyet.com/

Until rust catches up with some meaningful feature set that Qt provides starting a GUI project in rust is probably going to be painful.

pas3• 4 years ago

Most GUI apps don't need what Qt provides though. They mostly need stability and cross-platform support, so ... they should start with something like Tauri or Sciter, and if there is something they need natively they will be in a much better situation to pick their poison.

https://github.com/tauri-apps/tauri uses OS provided WebView

https://github.com/sciter-sdk/rust-sciter uses Sciter

zoomablemind3• 4 years ago

Moreover, when stating about "new projects", it's too easy to forget that these new projects often start in an existing environment which includes in-house and external libs to integrate with and likely some in-house expertise and engineering skill that goes with it.

So offering these shops to consider Rust or any other "it's better" language is similar to Enterprise Java push back in time, which simply turned local weed gardens into weed prairies with even wilder variety.

Meanwhile considering safe practices and features of whatever modern C++ is a normal and indeed organic process for such organizations, be it for new or supporting the existing projects.

As for starting an "independent" new project, well, that's a whole new story. I guess the choice would still rely on the need and availability of external components for it. Ah, least we forget about the costs!

Shorel3• 4 years ago

I would have complied if he said D lang.

Tried Rust, did not like it that much, compared to D.

29athrowaway4• 4 years ago

Herb Sutter, who also works for Microsoft and has dedicated his entire life to advancing C++, may be really sad right now.

ncmncm25• 4 years ago

He knows it is just hot air.

He has been at Microsoft forever. He really knows hot air.

29athrowaway4• 4 years ago

cppfront seems like a good idea.

fxtentacle2• 4 years ago

I get that it makes sense at his level, but my impression is that mistakes in the business logic are both more common and more financially painful for the company than the memory safety issues that Rust solves when compared to C++.

Unsafe binary? Run it in docker.

Crashes? Run two and monit.

RAM leak? Restart with cron.

Now I'm not saying that these are good solutions, but they are good enough so that plenty of companies get away just fine with running buggy c++ software in production. So in my opinion, the biggest improvements come from better abstractions and good libraries. And c++ still has the lead there.

howinteresting6• 4 years ago

Rust also solves many classes of logical issues through ADTs and pattern matching. And many classes of thread safety issues. Memory safety is an important part of Rust but not all of it.

spacechild14• 4 years ago

I don't know much about ADTs, but I'm skeptical they would help me for my own programs since most of my logic errors boil down to wrong math...

unnouinceput• 4 years ago

If you think that an unsafe binary is safe if you run it in docker then I challenge you to run, on your personal computer, this program in docker:

https://arstechnica.com/information-technology/2022/09/new-l...

use this picture in a hexeditor:

https://cdn.arstechnica.net/wp-content/uploads/2022/09/shiki...

fxtentacle2• 4 years ago

I feel like this is very much outside the scope of "Rust is more safe than C++". I was talking about shielding from accidental bugs in an otherwise well-designed server where Rust would reduce the severity of one error class (out of many).

hoseja• 4 years ago

I can see how somebody familiar with windows internals would like to burn it all down asap.

evouga• 4 years ago

C sits at a sweet spot of performance vs. expressiveness vs. portability whose Pareto-optimality has withstood a half-century test of time. It’s not going anywhere.

The case for replacing C++ is a lot stronger but I don’t see game engines, for instance, switching to Rust (or using garbage collection) any time soon.

prabhu-yu2• 4 years ago

In C++, there is Move semantic. If we use "Move semantic" in C++ code, could it match the memory safety of the Rust?

pornel6• 4 years ago

Rust has move semantics too (it's automatic and there are no moved-from leftover objects), but it adds borrow checking on top of that, which C++ doesn't have.

prabhu-yu2• 4 years ago

Thank you, I will study more.

phantom_of_cato• 4 years ago

This is a stupid "hot take", no matter the stature of the person who said it. They may have a point, but they aren't making much of an argument with a single tweet.

Shorel3• 4 years ago

He has a vested interest in renting hardware, so resource efficiency is opposite to his goals.

It would not surprise me he praises Python =)

Gordonjcp• 4 years ago

Why is Rust supposed to be good?

alexeiz• 4 years ago

The Azure CTO knows as much about C++ as to easily confuse it with C. Anybody who say C/C++ is not aware that C++ is vastly different from C and it can't be combined into a single "language" like this. Mark Russinovich puts his ignorance on full display here.

pjmlp4• 4 years ago

On the contrary, this kind of critic only reveals the ignorance of English grammar rules regarding the use of /.

bruce343434• 4 years ago

I like memory safety as much as the next guy but an unelaborated opinion tweet is not hacker news.

blub3• 4 years ago

It’s jarring to see how somebody’s fame in a specific domain makes them believe they can dictate what other companies and entire industries can use.

Read his internals book - much appreciated back when I was doing Windows programming. Used his tools - very nice while I was still using Windows.

But I never looked to Mark Russinovich or any Microsoft guys to advice on what programming language to use. What’s the point of making such an arrogant proclamation?

dxuh• 4 years ago

When people use "C/C++" as a single language I usually know right away don't know much about C++. The distance between C and modern idiomatic C++ is many times larger than the distance between C++ and Rust. C++ looks like an ancient juvenile dialect of Rust compared to C and C++ looking almost nothing alike. You can write shit C++ that looks like C and breaks like C or you can write good C++ instead and end up with less (almost none in practice) memory problems also. This discussion comes up multiple times a week and almost never do the people having it actually know what they are talking about. I am aware this person is a big shot that has done great things, but it's still impossible he has seen actually good C++ written in the last 5 years. Not because it doesn't have memory bugs, because they are much harder to make. Language landscapes change and old languages die and new languages get popular, but it seems this whole thing is based on a giant strawman (that C++ is the same as C). It's very frustrating.

ncmncm25• 4 years ago

Yes. Use of the "C/C++" construction is a marker for one or more of ignorance, dishonesty, or laziness. Usually it doesn't matter which: into the round file it goes.

nspattak• 4 years ago

The problem with "c/c++" is not that the people using this notation are ignorant of their difference. the problem is that there is nothing preventing someone writing c in a cpp file. what is more, it is up to every one/every project to choose the cpp subset to use.

That is why i think the criticism is very very valid

kosolam2• 4 years ago

Mark is not the subject. He is speaking of Rust and memory safety. I agree with him in general, that if a project requires C/c++ kind of capabilities then better to use Rust. But, if one doesn’t require Rust then I think one must avoid it by all means, because it’s such an investment into such a huge learning curve and such deep levels of complexity and mental burden.

rob74• 4 years ago

Well, he wrote "use Rust for those scenarios where a non-GC language is required", so I guess his opinion is similar to yours. But, judging by the "using Rust for web dev" articles that keep popping up here, there are people with other opinions too...

kosolam2• 4 years ago

Looks like the rust web devs are downvoting my comment. Oh well

dynamite-ready2• 4 years ago

I think this is a silly idea. There are still loads of questions surrounding Rust. Especially about it's practicality... There are articles denigrating the likes of the trait and async systems on HN almost every day. And even ignoring that argument, any language is viable, so long as it can be used to build what you want to build.

the__alchemist• 4 years ago

The nice thing about the trait and async problems are you can ignore them if you minimize and/or are selective with dependencies.

pornel6• 4 years ago

There's very little overlap between HN commenters lamenting about colors of async functions, and actual Rust programmers writing async software.

Rust's crates.io has over 15000 packages using async. Cloudflare has just replaced their nginx with a Rust proxy that uses Rust's async. Apple has hired Rust programmers for their storage and networking teams.

Rust has been out for 7 years now, and detractors on HN still treat it as an unproven novelty that's going to collapse any day now.

scoutt5• 4 years ago

But don’t you think if Rust meant to be so popular and successful wouldn’t be it already, in this time and age? Like other languages since 2000? (Rails, typescript comes to my mind)

Rust has given all its arguments. Has proven its goodness. What do you think it is stopping the world from adopting it?

Another year is passing. The biggest news is that it might be included in the kernel. But it just requires a bad Linus Torvalds morning to become “Rust, the language that wanted but couldn’t“.

ugh123• 4 years ago

I think you're forgetting the security issues surrounding C. Also, I could build a lot of stuff in PHP. But in 2022, is that wise?

dynamite-ready2• 4 years ago

That's not quite equivalent, but I will indulge you. The truth is, there are many tools and libraries written in CPP, with many years of accumulated knowledge implicitly embedded in their codebases, that will take a very long time to replace, if some of them can be replaced at all.

It's fitting that you mention PHP, because while the ecosystem isn't quite the same, for all it's problems (especially security), WordPress is still viable for a bunch new projects, and things may remain that way for many years to come.

matt3210• 4 years ago

Fortran is still in use so im not worried that i use c++

jeff-davis3• 4 years ago

As much as I like rust, I feel the statement is a bit premature.

Rust has only one real compiler and no independent language standard.

Rust is also the only alternative that is really being discussed most places. For an idea as major as "deprecate C/C++" you really want a couple solid alternatives. Rust is not perfect for everything, and so its easy to pick on the weaknesses and say "that's why we're sticking with C/C++".

I guess Ada or D are viable alternatives, too, and maybe need more attention. But the tweet only mentions rust.

bowlerman5• 4 years ago

Having a standard is overrated. What you usually want is clearly defined behavior and a good backwards compat story.

Standards only make sense to me in the presence of multiple compilers or formal verification. There is ongoing work on supporting the second use case. I don't understand why people want multiple compilers.

jeff-davis3• 4 years ago

"I don't understand why people want multiple compilers."

Most people don't. But most development moved away from C/C++ before rust.

If you want to call C & C++ "deprecated" you can't ignore the margins, which is exactly where those languages thrive.

Maybe there needs to be a tiny (incomplete?) rust compiler. Or maybe there should be an interpreter.

Jataman606• 4 years ago

Rust has only one real compiler

I never understood why it is a problem for some people. Single compiler means more people working on it instead of recreating same work multiple times (modules and coroutines are still not fully supported across all 3 biggest compilers).

0x4573• 4 years ago

What they're really saying is, "I can't build it with GCC", but that would sound too evangelical. Why they need GCC is another question.

Note to whoever I've angered: Please, don't reply with your reasoning why you need GCC. I don't care about your reasoning and that GCC unlike LLVM supports this platform that only used on calculators made by defunct company and sold whole 3 of them.

zppln• 4 years ago

Getting kind of tired of these idea that people should apologize for writing in C or C++. I'd much rather have people build useful stuff in whatever languages they're comfortable with, than having them not doing so. Security isn't everything in every application. The usefulness of unsafe code continues to vastly outweigh the costs of the associated CVEs.

kleiba• 4 years ago

Casey Muratori's opinion on Rust: https://twitter.com/cmuratori/status/1367627549816152064?lan...

spacechild14• 4 years ago

Thanks for that link, that's hilarious!

nickdothutton• 4 years ago

He is probably right but then that doesn’t mean it will happen. Having worked in Ada 25 years ago, and made the argument (which largely fell on deaf ears for reasons that most of us this old understand), I think his statement is less controvesial than you might imagine. These changes take a long time, but I’m already encouraged by what I’m seeing, especially with companies like Cloudflare adopting a rust proxy in place of nginx.

Xcelerate• 4 years ago

I’ll controversially go a step further and say we need to even begin requiring this via regulation for certain applications, at least for those that involve the personal or financial data of customers. From working with security at a large tech company, it’s abundantly clear that C/C++ should not ever be used for processing sensitive information (it’s fine to keep around for high performance computing or processing non-sensitive data). There are just too many people involved in making codebase changes and too many potential errors to be made. Not every company has the resources to devote to an in-house static analysis team.

We have all sorts of regulation in other industries to protect consumers, and with so much of our economic infrastructure dependent on the security and integrity of information processing, it’s bizarre to me that we’re still using programming languages with severe deficiencies for these purposes.

Will there be performance hits, cost hits, and inefficiencies introduced by requiring safer languages? Of course. But I see that as vastly preferable to the dangerous state of cybersecurity at almost all companies.

kevincox• 4 years ago

In not sure we need to regulate for or against specific languages but we absolutely need to hold companies more accountable for their cybersecurity. Once meaningful fines for data leaks and compromises start raining down the market will quickly shift to safer technologies.

jcelerier6• 4 years ago

If society did care in any meaningful way, Equifax wouldn't be valuated more today than before the leaks, no?

svnpenn4• 4 years ago

we need to even begin requiring this via regulation for certain applications, at least for those that involve the personal or financial data of customers

wow that is an awful idea

userbinator• 4 years ago

Hell no! Have you read Stallman's Right To Read? Because that's exactly the dystopian vision it talks about.

otabdeveloper4• 4 years ago

"C/C++"

Opinion discarded. Sorry.

butterisgood2• 4 years ago

I don’t disagree overall. We can do a lot better these days but Rust just doesn’t do it for me.

That language makes a train take a dirt road. It’s big, complex, and I have to believe “not what we are actually looking for”.

Haskell promised all kinds of safety too and has back doors to hide “unsafety” that are basically “game over”. Rust doesn’t seem to do much better in this regard. Maybe I’ve not written enough of it. (I’ve written far more Haskell)

How bad is GC really? Has Go shown it to be manageable and not an issue yet?

Seriously spending all my time in C and C++ due to the nature of my job, I can’t say I’m convinced we’d ever start using Rust.

butterisgood2• 4 years ago

For example why not Ada/Spark? People hate the Wirthian syntax?

I mean it’d be nice to be able to write M1/M2 Mac OS native Ada code but no one offers that it seems.

dvh• 4 years ago

What should I use for stm8 on Linux then? The only thing available is assembler and C.

bullen• 4 years ago

The management ecochamber will push rust until their faces turn blue.

Until they rewrite mrustc in rust everyone using rust is one dependency up.

The truth is we don't need rust, either you are making a server and then Java is the language to use.

On the client where rust has a good chance to compete with C we're looking at electricity cost problems and then C is an easy choice.

You need to compile things to be productive.

slashdev3• 4 years ago

I'm just a programmer who's been doing this for 20 years. I don't have the credentials of Mark, who is a legend. But I fully agree with him. There will be specific exceptions, but if you have the choice between Rust and C++ you would be making a big mistake to not choose Rust. The language is simpler, cleaner, safer, and more enjoyable to work with. The build tools are far more pleasant. The IDE experience is comparable. The hiring market is way better for Rust because it's not mainstream. Programmers currently using Rust are superior to programmers using C++, statistically speaking. There's a vast difference between individuals, but with only that one data point you can tell quite a lot. People learn C++ in college. People learn Rust because they love their craft. I stopped using C++ after I learned Rust. I still use Go sometimes, when appropriate, and I use other languages in my day job. I have a lot of experience in C++, much more than with Rust. The borrow checker still drives me mad. I've worked in over twenty languages over the years. Languages are tools, try to be impartial and pick the best tool for the job. Your personal tastes don't matter unless it's your personal project.

krona• 4 years ago

The language is simpler, cleaner, safer, and more enjoyable to work with.

I was a Rust v1 contributor. I have great hopes for the language as a replacement for c in systems engineering. However, I much prefer C++ 20 for the kind of work I do (scientific computing). Rust isn't a competitor to C++ in that arena, in my humble opinion.

Programmers currently using Rust are superior to programmers using C++, statistically speaking

The phrase 'statistically speaking' suggests the collection of empirical data. Could you elaborate?

People learn Rust because they love their craft.

If Rust becomes popular enough, this will no longer be any truer than for people who learn c++.

auggierose• 4 years ago

Very interesting. I am working on something that I hope will also appeal to people doing scientific computing. Could you say a few words about why you prefer C++20 over Rust for scientific computing?

slashdev3• 4 years ago

I was a Rust v1 contributor. I have great hopes for the language as a replacement for c in systems engineering. However, I much prefer C++ 20 for the kind of work I do (scientific computing). Rust isn't a competitor to C++ in that arena, in my humble opinion.

There's a lot of domains where Rust isn't an appropriate replacement. Notice I phrased it as "if you have the choice between Rust and C++". Often times because of libraries/frameworks you need, that may not really be a choice.

The phrase 'statistically speaking' suggests the collection of empirical data. Could you elaborate?

I don't have data apart from two decades of screening candidates and conducting interviews. I've heard this from other people, including Paul Graham, and I've seen it in my personal experience. I probably should have chosen different wording to not mislead people that this is backed by hard data.

If Rust becomes popular enough, this will no longer be any truer than for people who learn c++.

That's how it goes. Python was once a signal for finding better developers. That's no longer true.

thisiswrongggg• 4 years ago

> The hiring market is way better for Rust because it's not mainstream.

The ratio of C++/rust jobs where I am (EU country) is 5564/54. And these 54 jobs are mostly in cryptocurrencies.

Cthulhu_2• 4 years ago

I mean the argument is made that Rust is not mainstream, but if you were to pull in e.g. Java or Javascript apps in that comparison I'm confident it would make C++ look like a non-mainstream language too.

edit: numbers say I'm wrong, C++ is more mainstream than C#, C is more mainstream than Java: https://www.tiobe.com/tiobe-index/. I mean I doubt this source (it seems to indicate objective-C, which is all but superseded by swift, is on the rise) but it's at least one datapoint.

_gabe_3• 4 years ago

Programmers currently using Rust are superior to programmers using C++
People learn C++ in college. People learn Rust because they love their craft

Wow... and rust programmers wonder why rust has a stigma? So I guess John Carmack is inferior and is not an ultimate craftsman.

umanwizard7• 4 years ago

You cut out the words “statistically speaking”, which entirely change the meaning.

slashdev3• 4 years ago

I think I hit a nerve with this one. If you put out a job ad for any mainstream language (Java, JavaScript, C++, among others) you're inundated by applicants who have no business even working in this industry. If you put an esoteric language like Elixir or Rust, you get a smaller but much higher quality pool of applicants. That's my personal experience, I don't have hard data to back it up. Paul Graham once wrote about this effect in his Great Hackers essay [1].

Of course, the flip side of that is with a smaller pool of applicants, filling the position may not be any easier. It is harder to hire a poor candidate though.

John Carmack has actually played around with Rust. But I would like to reiterate that when generalizing about a population based on statistics, you might be correct more often than you'd be wrong (.e.g. men are more aggressive than women) but you can still easily find individuals who are exceptions. That you can find an exception doesn't disprove the rule. You still have to treat people as individuals, and not as a population. That should go without saying.

[1] http://www.paulgraham.com/gh.html

grog454• 4 years ago

Why do you think Rust isn't used more widely?

alkonaut4• 4 years ago

Because total greenfield projects in systems languages is still a pretty rare thing. Writing a new game with a C++ game engine isn't going to count, for example, and that means quite few things will.

I actually think it is quite widely used in this small niche. Don't have any data to back it up and my newsfeed is probably biased.

pwpw2• 4 years ago

As someone that is looking to learn one or the other (and hopefully be able to utilize it to land a job too), is the recommendation to skip learning C++ at this point and learn Rust instead? I was going to learn how to write a game boy emulator, which could be written in either, but I’d also like the language to help me in the professional world as someone getting ready to enter the field.

eloff2• 4 years ago

You'll have a harder time finding work, as there aren't a lot of Rust jobs. That's why it's a signal that a person loves their craft - there's little financial incentive in learning it. When it comes to finding work, pick a mainstream language. This will change over time as Rust becomes mainstream, which I think is likely.

klibertp• 4 years ago

People learn Rust because they love their craft.

We're exchanging opinions here without any kind of data to back either claim, but let me offer a contrarian view: people who learn niche-language-X because they love their craft are mostly younger folk with little experience in programming. My reasoning for this is that you get less and less time to pursue your love for a programming language when said love competes with love for your SO, your kids, and all the other things that happen to most people later in life.

It's anecdotal, but in my experience people who learn niche languages because of love or fashion are not the kind of people who will help write high-quality libraries for the ecosystem. For that, you need a stable, sizeable "middle class" - people who already know what their doing, who were able to evaluate the tool objectively, and who found a real value in it. Such people are not easy to come by: IME by the time they have enough experience, they mostly lost the eagerness to evaluate every shiny new thing that comes along.

The hiring market is way better for Rust because it's not mainstream.

I would like to see the statistics you base this opinion on. In my experience (also 20+ years of programming here) this effect is more than offset by the small pool of applicants.

Languages are tools, try to be impartial and pick the best tool for the job.

Yes. But you need to account for more than just technical features of a tool, like hiring or the opposition from the existing team to learning the tool. Choosing Rust when you have 20 seasoned, experienced C++ devs just because cargo is better than CMake... might not be the greatest of ideas.

scottLobster• 4 years ago

And sometimes people who love their craft pick the wrong tool (their favorite) for the job, write really shitty code and are hyper-defensive about it, regardless of the language.

I want people who have a history of picking the right tool for the job, and see their job as a team sport instead of a personal art project. Not a hiring manager, but I'd be more interested why someone with knowledge of Rust picked Rust over other options. Mere knowledge of it implies nothing of substance, and I've cleaned up too many mistakes in my career written by people who put their craft ahead of their mission.

fortran77• 4 years ago

People learn C++ in college. People learn Rust because they love their craft.

I learned Fortran, PL/I and IBM 370 Assembly Language in College. I learned C and then C++ because I loved my craft.

jcdentonunatco• 4 years ago

"the hiring market is way better for rust"

Lmao. Not even close.

"Programmers currently using Rust are superior to programmers using C++"

Hahahah that's cute.

phkahler• 4 years ago

This makes more sense to me than trying to bring memory safety to C++. C is mostly frozen, do that with C++ and deprecate both. 50 years from now they will still be around but compatibility will be good due to the freeze. Everything new will be much safer and maintainable.

This is a very long term strategy but it makes sense viewed that way.

retrocryptid• 4 years ago

There are C programs I wrote in 1982 that still compile and run (and do still do what they were intended to do.) There are rust programs from 5 years ago that don't compile. I have rust programs from 2 years ago that compile but silently fail because semantics of the language have changed.

Before we say C must die, let's think of the modern marvel of reverse compatibility.

But sure, C++ should die. Having to look at several files to figure out how a statement works is annoying.

markus_zhang2• 4 years ago

I wonder what triggered this tweet? Does Azure use a lot of C/C++?

sylware6• 4 years ago

I am still ok with plain and simple C for cross-CPU code, for now. c++ is lost in grotesque and absurd complexity (that's why gcc move to c++ was one of the biggest mistake in software, ever).

I am one of the guys who would like RISC-V to be successful, then "port" everything to RISC-V assembly, without excessive usage of the macro pre-processor, then forget about compilers.

Linus T. (more likely the guys pulling the strings of the linux fondation financing) green lighted rust in the kernel, I bet this is some horrible gcc extended rust, not core and simple rust (hope they have the decency to compile linux rust code with the rust compiler written in rust). A long time ago, I had a look at rust syntax and was disappointed by the strings hardcoded in the syntax and all that "package" management system hardcoded in the syntax, but most syntax looked like a re-arranged C. Were they able to keep it that simple? (no grotesque objet orientation or those horrible templates or garbage collector or hardcoded weird and expansive memory allocation model).

The pb is C syntax is too already too complex. I wonder if rust suffers from the same issue, hope they "fixed" C: only sized types, no integer promotion, no implicit cast (except for void*), compile-time/runtime casts (without that horrible c++ syntax), only 1 loop keyword, no enum/typedef/_generic/etc, etc.

umanwizard7• 4 years ago

I don’t know what you mean by strings embedded in Rust syntax nor package management (unless you mean crates and modules, which are basically just namespaces; the only “package management” is done by higher-level tools like Cargo).

To answer your other questions: no, Rust has neither garbage collection, nor templates. I don’t know what you mean by hardcoded weird and expansive memory allocation model; Rust’s is basically the same as C++’s.

sylware6• 4 years ago

It was crates and modules, ok then it was weird namespace system. But I clearly remember "strings" being hardcoded in the syntax.

So you mean rust has grotesque and absurd object orientation like c++ (or java)? Please, say no.

cesaref• 4 years ago

I've just trying to remember all the times i've heard this in relation to other languages replacing C/C++. I'd say java and C# are definitely in this category, but also python, go and probably swift too.

So I can now add rust to this list.

It's also interesting to see this as a tweet, avoiding any worry about the nuance of the problem domain, the experience of the developers, or what problems they encounter. Sure, rust is safer than C++, but is this important to the project you work on? What sort of problems do you encounter? Would rust help? What problems would it introduce?

Anyhow, 'rust is the new C++'. I wonder what the calling cry will be in 5 years time.

clarge1120• 4 years ago

According to Joel Spolski, of Microsoft Excel fame, he left Microsoft because of the company’s policy of encouraging the developer community to waste time and energy chasing new software technologies rather than shipping great software.

In other words, Msft has a long history of suppressing competition by steering the industry away from doing things that could threaten Msft’s dominance: like moving your company from the C++ language you’ve mastered to a new modern language you don’t know well.

aaron_h• 4 years ago

How good is rust at using existing C/C++ libraries? There’s so many of them for very useful low-level functionality, especially when programming against the Win32 API (which is written in C/C++ itself). Could I write a Windows kernel driver in rust?

I also can’t ignore the fact that Mozilla has been in serious decline as an organization in recent years. I worry about rust’s long-term trajectory as their support of the language wanes. It’s one of the reasons I feel so positive about the future of go, as they have a lot of dedicated people on it from google (an organization that in all likelihood won’t be going anywhere anytime soon).

bugmen0t• 4 years ago

Rust has very strong backing at Meta, Microsoft, Google, AWS and others. I wouldn't worry about corporate backing.

You can call into the Windows APIs (there's a windows crate) and if you want to call into something that isn't there, `cbindgen` and friends are amazing.

zozbot2342• 4 years ago

How good is rust at using existing C/C++ libraries? There’s so many of them for very useful low-level functionality, especially when programming against the Win32 API (which is written in C/C++ itself).

About as good as any other language with a C FFI (which is most of them).

... I worry about rust’s long-term trajectory as [Mozilla's] support of the language wanes.

I thought that was the whole point of having a Rust Foundation as separate from Mozilla itself.

NoGravitas• 4 years ago

Surprised he didn't get ratio'ed.

I'm glad I don't have a Twitter account. I'd have spent the whole day arguing with stupid replies (both for AND against OP's point).

kimixa2• 4 years ago

Lumping C and C++ together implies much about the use of the language - "modern" C++ features go out of their way to avoid memory unsafe and bug-prone operations (avoiding raw pointer arithmetic, no manual new/delete memory management etc). Comparing Rust against the overlapping subset of "C" and "C++" is rather disingenuous. It's like writing /everything/ in Rust in an unsafe block and avoiding all the tools that actually make it a more productive language.

I'd agree today you totally shouldn't be starting new projects in C-with-classes style C++, and take advantage of all the newer tools available in newer versions instead. Sure, Rust and similar may have even better tools to help the programmer, but talking about raw productivity, especially in shorter projects, learning a new language and all the fumbling and mistakes and anti-patterns that can hurt the result, as well as longer-term maintainability, may be worth consideration. Especially, as even if the core project is brand new code, the library ecosystem it's working in may still be more mature around other languages.

It totally makes sense to me relegating C and older-style C++ to systems where it's really the only choice (platforms with older/poor tooling, places where the resulting code requires more massaging than usual like resource-limited embedded situations and the developer is already skilled in this with their current toolchain, other situations that no doubt some people will find etc etc.)

nicoburns3• 4 years ago

How short is your project? I learnt Rust to a productive level in 6 weeks. So I guess if your project lifetime is shorter than ~6 month then sure.

The library ecosystem in Rust is less mature (there isn’t a library for absolutely everything), but where a library does exist it tends to be much more robust than the C++ equivalent. A library in Rust will not have UB (however you call it). It won’t throw exceptions. It won’t return null without warning you, etc.

chriswarbo4• 4 years ago

"Modern C++" versus "older-style C++" is a meaningless, hand-wavey distinction: if your toolchain accepts "older-style C++" then you're using a vulnerable language; if your toolchain rejects "older-style C++" (e.g. using lint rules) then you're not programming in C++, you're using a safer language which just-so-happens to be a subset of C++. That doesn't affect how vulnerable the C++ language is.

kimixa2• 4 years ago

If you're not using every possible construct in unsafe rust blocks, then you're not using rust - just a safer language that just-so-happens to be a subset of rust.

The difference is that "discouragement" is in the compiler itself not external lint tools (though many of those "lint tools" are just optional arguments to the compiler). The big difference is the general community having less of a spread of opinions on what the recommended subset is, not helped by that changing over the age of the language, and not being clear about what the general epoch of the language are to highlight things that may be generally replaces by a better construct. Honestly, I'd say the biggest failing of the C++ updates today are lacking some similar epoch system - where older constructs can actually be deprecated from the language.

It would be interesting to see if rust gets exactly the same thing as the community expands, and accumulating language updates affect the generally accepted best practices. It's clear Rust doesn't intend to be completely static, with significant language features being added every version. I wonder if one day we'll look at today's rust in the same way as someone focused on "modern" c++ looks at c++98 C-with-classes style code.

Everyone uses a subset of any language, that's what coding styles and common patterns are. A definition of this subset is a really useful thing you can do for any non-trivial project IMHO, for any language.

the_arcadian4• 4 years ago

This sort of reminds me of the 1994 essay "Why you should not use Tcl" by Richard Stallman. Then, if memory serves me, we all switched to scheme and lived happily ever after.

neverartful• 4 years ago

It's a good thing I got my latest one started before this was announced!

All kidding aside, as others have pointed out this is coming from someone with tremendous credibility and it is worth giving some consideration. I have a lot of respect for Rust although I've only toyed with it for personal projects. The compiler provides very helpful messages (vast majority of the time), but even so, for complex applications it can still be very difficult to reason about.

As has already been mentioned, it doesn't seem to be anywhere near prime time for GUI applications (such as those built with Qt, Gtk, Win32, etc.). I don't think it's fair to say that ALL GUI apps should be built with a managed language.

Like with go, one of the nice things is that there's just one provider of the compiler. At least you don't have to contend with different levels of support and different compiler options.

alkonaut4• 4 years ago

Completely agree. And this isn't even controversial. The controversy is about whether to make rewrites, including it in the Linux Kernel and so forth.

But for greenfield projects in systems languages? First of all, that niche is tiny. There may be sub-niches where availability of some specialist library makes it harder to use Rust than C++, but I'd argue that if some library or ecosystem is that important, your project isn't completely green field. An Unreal game isn't a greenfield project even if I start now because the Engine is a massive piece of C++ you have to live with.

For anything this niche of "green field enough", I'd go with Rust even if I had a whole team consisting to 100% of experienced C++ developers. And I wouldn't even sweat the decision.

mikewarot• 4 years ago

I still use Lazarus/Pascal, not as clumsy or random as pointer math, an elegant language, for a more civilized age.

Wirth was wise to do everything possible to discourage pointer use, and make it obvious. Hejlsberg and company gave Pascal a worthy library and IDE. Then the language florished under the Turbo Pascal, and later Delphi banner.

But then Hejlsberg turned to the dark side, and joined with the MicroSith. They bought forth Sith.NET, Sith# and all other manner of evil.

pier25• 4 years ago

There are a couple of industries were C++ is king and I seriously doubt Rust will be adopted en masse for the foreseeable future: game dev and audio dev.

cjk• 4 years ago

Meh. I agree with the sentiment, but in practice, I’m not sure we’re there yet. Maybe once Rust has a more robust standard library and less language-level churn we’ll be there.

If you’re writing something safety-critical, sure, use a memory-safe language like Rust/Go/etc. Otherwise, I think C++ is still plenty viable.

randomcarbloke• 4 years ago

Another one lost to the cult.

benibela2• 4 years ago

I stopped doing new projects in C++ years ago, and now I only code in Pascal

taylodl• 4 years ago

Uh-huh. Meanwhile we're still launching new projects in Cobol, a language that's been "dead" for the past 40 years!

jokoon• 4 years ago

I highly doubt that it's easy to hire rust developers.

Maybe it's possible to hire c++ dev and make them work on a rust project?

Anyhow, is there a qt equivalent for rust? Can rust really compete with c++?

I've read rust code and I'm sorry but it seems like the steep learning curve is just not worth it, even if the benefits are big.

I still believe rust fills the same niche of ada, meaning tight requirements. Most c++ projects don't care that much. It's cheaper to test things or rewrite than betting on a new difficult language.

professoretc• 4 years ago

Maybe it's possible to hire c++ dev and make them work on a rust project?

Maybe, but not after proclaiming to the internet "your job is obsolete".

shmerl2• 4 years ago

Hiring C++ developers isn't easy either. Same for reading C++. So learning curve isn't an argument if you compare Rust to it.

phendrenad2• 4 years ago

Right, because I'm going to take advice on writing programs that need to not have a GC from someone who has never written any program that needs to not have a GC.

throwaw32823• 4 years ago

Great. When I thought I just became expert level in C++, this? Hmm.. fine time to learn Rust.

mbrodersen2• 4 years ago

New C++ projects will continue to be started every day for a loooooong time. There are millions of C++ programmers out there and most of them have zero interest in switching to another language.

kevlar700• 4 years ago

Ada offers security and simplicity and is already part of GCC but also has llvm now. Linux kernel drivers have also been demonstrated.

Perhaps it would be healthier for Rust to have competition?

https://www.linux.com/audience/developers/hacking-the-linux-...

https://github.com/alkhimey/Ada_Kernel_Module_Framework

https://alire.ada.dev/

Nvidia also chose Spark; a built in subset of Ada as being more cost effective for secure code than C++.

https://youtu.be/2YoPoNx3L5E

Assembly is also supported by Ada and I found it far easier to add than with C even.

C interface support is also excellent.

It's time to halt starting any new projects in C/C++

Related Stories