Rust is not a good C replacement - <AUTHOR> https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html <comment><USER3> There's a lot of stuff I could say here, but I'll stick to

> Attempts to integrate it with other build systems have been met with > hostility from the Rust & Cargo teams.

This is _very_ much not true. We've put in a ton of work to support this. Arguably, we've put in too much design work and not enough implementation work; we've had a few different attempts at making this work even better than it does today, and we haven't finished them up. But this is very much something that is cared about and desired by the team.

It was literally on the 2017 roadmap: [https://blog.rust- lang.org/2017/02/06/roadmap.html](https://blog.rust- lang.org/2017/02/06/roadmap.html)

> Rust should integrate easily into large build systems. Plans include working > with large companies incorporating Rust to understand how best to equip > Cargo to smooth the process.

I don't know how this is framed as "hostility".

As one example of the work done here: [https://github.com/rust- lang/cargo/issues/5579](https://github.com/rust-lang/cargo/issues/5579)

<comment><AUTHOR> Thanks for sharing your perspective. My comment was largely based on this discussion:

[https://github.com/mesonbuild/meson/issues/2173](https://github.com/mesonbuild/meson/issues/2173)

If you'd like to share a short summary of your thoughts, I'll update the article with your commentary.

<comment><USER4> I didn't read the entire thread, but if I understood the gist of it, it seems like an anti-pattern is being asked for, and it would be an anti-pattern when mixing any languages. What it seems they want is the ability to mix Rust and C in the same build chain, not treat each as a separate build artifact and link at the end.

I've never had a problem modeling things with Makefiles, having the Rust artifact target be built by Cargo and then linking with the standard toolchain for C in the Makefile.

I'm clearly missing some context, as this works really well.

<comment><USER3> Yes, there's a ton of ways that you can do this. Most successful integrations thus far have done exactly that: you have a target for your Rust code, it calls out to Cargo and does its thing, and then links it in. I believe that you're right that the Meson folks want to use rustc like they use cc, and use Meson for all of the stuff that's not "compile this, please."

This can work well as long as you're writing all of your own code. The issue is that most people like Cargo, and like using Cargo, and so virtually all open-source projects are built around Cargo. This is not unlike if you're a Meson fan, but you want to use an open source project that uses CMake for its build, and so it's only really set up to use CMake. (At least, in my understanding.)

<comment><USER4> Well, then the comment they made about essentially rewriting Cargo is probably accurate.

Doesn't seem like it's a valuable contribution to their end goal though.

I do want to point out (for others, you know this) that Cargo has a lot of environment variables that can be used to improve its usage inside other build systems, e.g. using a shared target directory for reusing compilation of dependencies: [https://doc.rust-lang.org/cargo/reference/environment- variab...](https://doc.rust-lang.org/cargo/reference/environment- variables.html)

<comment><USER3> Right, that's why we introduced the build plan feature, so that you don't have to re-implement Cargo, you can use Cargo to spit out the stuff you need instead. :)

</comment></comment></comment></comment></comment></comment><comment><USER5> > Safety. Yes, Rust is more safe. I don't really care. In light of all of > these problems, I'll take my segfaults and buffer overflows. I especially > refuse to "rewrite it in Rust" - because no matter what, rewriting an entire > program from scratch is always going to introduce more bugs than maintaining > the C program ever would.

And that is why we can't have nice things.

"I don't really care" if someone overflows my buffer to execute code...

And: "going to introduce more bugs" \- false. Empirically complete bollocks...

<comment><USER6> I would say if you rewrite it and have _more_ bugs, you must have no understanding of the existing codebase, or understand so little of it you shouldn't be the one rewriting it regardless.

All the rewrites I have done have resulted in leaner codebases with fewer potentials for bugs. I think people take some article one software developer wrote almost two decades ago as gospel, but "second system syndrome" doesn't have to be a syndrome.

This "rewrite" fear is exactly why our banks are stuck on 1970s and 80s code with an almost 60 year old programming language and no one left to take over maintenance. Eventually we need to get over this fear.

<comment><USER7> I guess you disagree with the likes of [1] then. Presumably it depends on the age and complexity of your project.

[1] [https://www.joelonsoftware.com/2000/04/06/things-you- should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never- do-part-i/)

</comment></comment></comment><comment><USER8> > C is the most portable programming language.

This is a function of popularity and time.

> C has a spec. No spec means there's nothing keeping rustc honest.

Agreed, language specification is critical. The language reference [1] is very detailed, though. I'm not sure what it would take to promote this to a "specification."

> That really cool feature $other_language has? Not interested. It'll be more > trouble than it's worth

Binding to "editions" is a reasonable way to get stability, IMO. It's a shame that this wasn't adopted earlier.

> Concurrency is generally a bad thing.

So don't leverage it. Don't use fork() or clone() either and we'll all agree to ignore this point.

> Safety. Yes, Rust is more safe. I don't really care. In light of all of > these problems, I'll take my segfaults and buffer overflows.

Here underlies the crux, you should have led with this. This is a sizable portion of rust's value proposition. If you don't value it then it's likely not to measure up well.

> Rust will eventually fail to the "jack of all trades, master of none" > problem that C++ has.

We have to take the good with the bad in everything, right? If Rust's future is "spectacular failure like C++" then it's probably going to be a wild success.

[1] [https://doc.rust-lang.org/1.0.0/reference.html](https://doc.rust- lang.org/1.0.0/reference.html)

<comment><AUTHOR> >This is a function of popularity and time.

Correct, both of which you have to take into account when picking a programming language _today_.

>We have to take the good with the bad in everything, right? If Rust's future is "spectacular failure like C++" then it's probably going to be a wild success.

I wouldn't call C++ a wild success. It's failed to supplant C for its entire life, and thrives only in a few niches.

<comment><USER9> > I wouldn't call C++ a wild success. It's failed to supplant C for its entire > life, and thrives only in a few niches.

Aren't web browsers one of the most used consumer software today? I wouldn't call them niche.

<comment><AUTHOR> I was measuring by number of projects. Consider that most web browsers also depend on a dozen or more C libraries.

<comment><USER9> > I was measuring by number of projects.

I think even going by that metric C++ does pretty good.

Not exactly "number of projects", but here are some numbers:

GitHub statistic: [https://octoverse.github.com/projects.html](https://octoverse.github.com/projects.html) C++: 5th place C: 9th place

StackOverflow survey: [https://insights.stackoverflow.com/survey/2018/](https://insights.stackoverflow.com/survey/2018/) C++: 10th place C: 11th place

> Consider that most web browsers also depend on a dozen or more C libraries.

That just shows that C is a wild success, too ;)

<comment><USER10> I don't think that metric is fair, either. A large number of C users don't use Github nor SO.

<comment><USER9> True. Still it's enough data to show that C++ is a wild success and is used more than just in a few niches.

Has it supplanted C? Definitely not. But in some areas it did (e.g. game development).

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> > _But now you know why we are still writing C, and hopefully you'll stop > bloody bothering us about it._

I don't think anyone will stop bothering them about it until C software security improves. Microsoft found that 70% of security bugs in their software were memory safety issues:

[https://www.zdnet.com/article/microsoft-70-percent-of-all- se...](https://www.zdnet.com/article/microsoft-70-percent-of-all-security- bugs-are-memory-safety-issues/)

Languages like Rust are making an effort to address these issues. What's the roadmap for reducing the number of security flaws in C software?

<comment><USER12> > What's the roadmap for reducing the number of security flaws in C software?

Thoughts and prayers.

<comment><USER13> A little controversial, but I would have liked the larger programming community to address this rather than write completely new languages.

Think of all the effort that has gone into rust. Compilers, package managers, libraries, etc. What would have happened if that same effort went into better analyzers, linters, compilers, etc, for C/C++? Rather than rewriting everything to be made "perfect" (which will never happen), this would be applied to the metric shit ton of existing code, making it better. Not perfect, but better.

Of course that work is dirty and necessarily political, and making a new language is sexy...

<comment><USER3> The reason that this wasn't done is that we believed (and it still seems to be true) that you cannot make C or C++ be memory safe at compile time. Or rather, you cannot do it without introducing backwards incompatibility, which means you're effectively making a new language anyway, and something that's a non- starter for those languages. (as it should be, IMHO.)

It had nothing to do with "sexy" and everything to do with engineering goals. I assure you, a lot of work in Rust is dirty, political, and not sexy too :)

</comment></comment></comment></comment><comment><USER14> The main fallacy of this blog post is that he wants it to be one single programming language that replaces C.

C has actually been already replaced mostly. C++, Java, C#, Python, Ruby, Go, Rust, etc. have been chipping away for more than 20 years now at C's market share.

What kind of project can you seriously start today in C because there are no better options available?

My guess is embedded programming and kernel programming and for both of these usecases we feel the pain and would actually want something else.

> _Yes, Rust is more safe. I don't really care. In light of all of these > problems, I'll take my segfaults and buffer overflows._

Old C programmer yelling at clouds?

> _Consider Go, which has had a lot of success in supplanting C for many > problems. It does this by specializing on certain classes of programs and > addressing them with the simplest solution possible. It hasn't completely > replaced C, but it has made a substantial dent in its problem space - <USER2> > than I can really say for Rust_

Go is IMHO a nice language and I would have been delighted to have it in the 90s. But nowadays it already feels outdated on arrival.

Lately I've been noticing more and more tools being developed with Rust. Some things take time, I wouldn't already write off Rust yet.

<comment><USER10> Author here.

>The main fallacy of this blog post is that he wants it to be one single programming language that replaces C.

That's not at all what I'm suggesting. In fact I thought this part of the article makes it clear that I feel the opposite way:

>C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex. Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible. It hasn't completely replaced C, but it has made a substantial dent in its problem space - more than I can really say for Rust (which has made similar strides for C++, but definitely not for C).

<comment><USER14> > _It hasn't completely replaced C_

The keyword here is _completely_. Rust doesn't need to completely replace C, it only needs to cover those usecases other languages haven't already covered. Or maybe just some and a completely different language takes what is left.

You don't care that Rust is much more safe than C due to all the features it has that are unlike C. But the safety aspect is Rust's main raison d'être.

If you dismiss this outright, you could have written a much shorter article or at least written a much more interesting article by starting with this admission and from that working your way through Rust's feature and explaining how this doesn't alleviate the warts of Rust.

> _But now you know why we are still writing C_

I wonder who this "we" is?

I'm also still writing C but for quite different reasons. Mostly because of legacy code and to some degree even just to be able to claim that I'm working on 35 year old code.

<comment><USER15> > You don't care that Rust is much more safe than C due to all the features it > has that are unlike C. But the safety aspect is Rust's main raison d'être.

Rust is still young. I think it's a bit naive to proclaim the language of the future is here. Why?

That was also the point of Ada until people realized that unhandled Constraint Errors could still crash missiles.

[https://itsfoss.com/a-floating-point-error-that-caused-a- dam...](https://itsfoss.com/a-floating-point-error-that-caused-a-damage-worth- half-a-billion/)

That was the point of Java until people realized that JRE's were full of security holes.

[https://www.cvedetails.com/vulnerability- list/vendor_id-93/p...](https://www.cvedetails.com/vulnerability- list/vendor_id-93/product_id-19117/Oracle-JRE.html)

So, what's the point of Rust again? To protect us from all these security holes? Wasn't that also the goal of other languages?

> I wonder who this "we" is?

TIOBE says C is second most popular language after Java even with all the security holes. So there's a lot of "we" (though I don't code in C).

[https://www.tiobe.com/tiobe-index/](https://www.tiobe.com/tiobe-index/)

<comment><USER14> > _Rust is still young. I think it 's a bit naive to proclaim the language of > the future is here._

I never claimed that Rust is the language of the future. I didn't say it directly but I think you can deduce it from my comments that I consider a multi language approach more sensible than using the same programming language for everything.

Using Rust is more safe than using C. That's valuable.

> _So, what 's the point of Rust again? To protect us from all these security > holes? Wasn't that also the goal of other languages?_

Are you saying that just because Rust doesn't solve all problems it isn't worth having? You're also conflating stuff.

The Ariane 5 explosion was not a programming error, it was a testing and specification error. The code worked exactly to the spec but the spec was for another piece of hardware. You can't use a fork and complain that it's not a good spoon.

How about quantifying the bugs in the JRE against all the buffer overflows in similar C code? 600 CVE worthy bugs in 10 years doesn't sound like that much if you put it that way.

[https://www.cvedetails.com/product/19117/Oracle- JRE.html?ven...](https://www.cvedetails.com/product/19117/Oracle- JRE.html?vendor_id=93)

> _TIOBE says C is second most popular language after Java even with all the > security holes. So there 's a lot of "we" (though I don't code in C)._

The TIOBE index has some issues. It is essentially counting hits for a search engine query for a specific language. I would rephrase it as "C has the second most webpages on the internet."

On PYPL it is only the 6th popular language, although coupled with C++.

Nevertheless there is still demand for C. Otherwise we wouldn't even have this discussion at all. But most people would rather see this demand decrease as we haven't been able to fix the language in the last 30 years.

<comment><USER15> > The Ariane 5 explosion was not a programming error, it was a testing and > specification error.

What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.

It's worth noting that this was one of the primary reasons that Ada got less and less traction in the US government, as Ada was supposed to prevent things like this from ever happening.

<comment><USER16> > What happens when you stick a 32bit float into a 16bit float type in Ada? > CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was > Ada's inability to deal with unknown/incorrect inputs and deal with them in > an effective way without crashing. This is not that much different than > buffer overflows from unknown inputs in C, btw.

That's immensely different actually ... One is undefined behavior, the other is defined but crash. In the first case the problem can stay unnoticed almost forever until somebody exploits it. In the second case, if you actually test and _cover_ your code, you will catch the problem.

Short for using a proof technology (which Ada enables and makes easy because of the large palette of constraints you can add on types), there is NO language that can statically guarantee that your program won't crash at runtime. Yes, Ada is not special in that regard. What Ada guarantees is that it will crash, so you can actually catch those kind of bugs in testing. Also nowadays you can use SPARK Ada to formally prove your code correct. [https://en.wikipedia.org/wiki/SPARK_(programming_language)](https://en.wikipedia.org/wiki/SPARK_\(programming_language\))

Blaming on the language what is actually bad testing/architecture is pretty unfair.

> It's worth noting that this was one of the primary reasons that Ada got less > and less traction in the US government, as Ada was supposed to prevent > things like this from ever happening.

Do you have any source for that ? From my sources, Ada got less and less traction because of various reasons, one of them being the price of compilers at the time. I have never seen anybody saying that it was because Ada was "not safe enough", and even today it stays one of the safest languages out there in many aspects.

<comment><USER15> > Blaming on the language what is actually bad testing/architecture is pretty > unfair.

I think we can both agree that a SEGFAULT and an unhandled CONSTRAINT_ERROR lead to program termination.

Your right in that at least Ada raised a CONSTRAINT_ERROR. But -- the cause for a CONSTRAINT_ERROR and a SEGFAULT in this case are the same: bad handling of inputs to a function.

So in this case the results would have been the same as well. In either case it comes down to design and proper handling of inputs.

So I don't buy your argument that it is different because of undefined behavior vs. defined behavior. Ada 83 had undefined behavior, too. It's just that Ada coders (well the good ones) knew to avoid it.

> Do you have any source for that ? From my sources, Ada got less and less > traction because of various reasons, one of them being the price of > compilers at the time.

Having worked in a Large Defense Corp(TM) during the height of the Ada popularity, it became pretty clear that the cost of a compiler for a $100mm program wasn't really the issue.

The GNAT Ada compiler came out in 1995, and I know smaller defense contracts used that as a viable solution to write software.

The primary issues with Ada were:

1\. Ada was oversold and underperformed. The Arianne-5 was the kind of tragedy that Ada was supposed to prevent. Interfacing with external systems was a pain. Tooling was a pain. The resulting executables were HUGE at the time.

And then the development itself was expensive. Towards the end of my time writing Ada, our group was coding at the rate of 2 lines of Ada code / developer hour. Compiling took hours, running and testing took hours, etc. So a 20 line code change might easily result in 10 hours of a compiling/testing cycle.

2\. No code reuse across defense contractors. Ada didn't have a package manager at the time, and while there were software libraries, there weren't a lot of them. Not like the C/C++ or later the Java world would have. So if you needed something, most likely you had to write it from scratch.

3\. Java got popular around 2000ish and showed what a great software ecosystem looked like. Around 2005ish most new successful defense development was on java.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> I agree with the overall conclusion. Zig is aiming at being a C replacement. Rust is very much more in the C++ space. But a lot of the individual points seem off the mark.

> Concurrency is generally a bad thing. A program which uses poll effectively > is going to be simpler, reasonably performant, and have orders of magnitude > fewer bugs.

One of the benefits of Rust is that provides a lot of checks on concurrent code to prevent you doing stupid things, so you get the benefits without these costs. It's not perfect, but I've personally had zero issues with concurrent code in Rust. This is actually a benefit Rust provides even over other memory safe languages like Java.

> C has a spec.

Yes, C has a spec. But a ridiculous number of things (in a modern context) are left as undefined behaviour in that spec, meaning that it is very easy to accidentally violate the spec. Rust doesn't have a spec yet, but it has far more safeguards which make it much easier to avoid weird unexpected behaviours in practice. A full spec will come eventually.

<comment><USER18> > One of the benefits of Rust is that provides a lot of checks on concurrent > code to prevent you doing stupid things

Well, here's the kicker. Nothing about rust forces you to use concurrency. Saying "Concurrency is bad, therefore rust is bad" makes no sense. There is nothing that forces you to spin off new threads in rust, just as there is nothing that forces you to spin off new threads in C.

In fact, it is pretty rich complaining about Rust's concurrency story while praising Go. A HUGE selling point to go was/is goroutines! The language was even given keywords for making concurrent actions!

</comment></comment><comment><USER19> Most of the author's points here derive from the fact that C has been around for nearly 50 years and Rust a mere 8. This post should really be titled "Rust is not a good C replacement _right now_".

Yes, Rust still has a long way to go to be the right tool for all the things you can do with C today, but that doesn't make it less. It clearly has benefits when writing concurrent and safe code. You pay for this with a learning curve, but the Rust team has been shaving this curve down through better tooling and documentation for the past few years.

> Yes, Rust is more safe. I don't really care. In light of all of these > problems, I'll take my segfaults and buffer overflows.

I suspect that for the author's work, these things may not matter much. But to a programmer working on any software where security is paramount (many web infrastructure pieces), this feature is golden.

I expect that as Rust matures, we'll see a solidified spec, competing implementations, and expanded build tooling. C has a long head-start, not to acknowledge that is just wrong.

<comment><USER20> On the other hand, Go has a very readable specification that was written early and is maintained to always be up to date.

Why couldn't the Rust team maintain a spec and keep it up to date by changing it in the same pull request that changes a language feature in the compiler? This seems like mostly a matter of discipline.

<comment><USER3> > Why couldn't the Rust team maintain a spec and keep it up to date by > changing it in the same pull request that changes a language feature in the > compiler? This seems like mostly a matter of discipline.

It's not that, it's that we take the idea of a spec very seriously. We want to have a spec that's extremely solid, and so there's a lot of foundational work that needs to be done first. That work has been ongoing. Not all specs are created equal, and good ones take a lot of time.

For comparison, C was created in 1972, and the first specification happened in 1989.

<comment><USER20> Okay, but this seems like letting the perfect get in the way of the good? A maintained, readable, informal spec should be quite useful as a starting point for writing a more formal spec later.

It need not be definitive. It would be quite reasonable to point out areas that aren't nailed down yet - this is also useful for the reader.

<comment><USER21> What do you want out of an informal spec that isn't provided by "The Rust Reference"[1]?

[1] [https://doc.rust-lang.org/reference/index.html](https://doc.rust- lang.org/reference/index.html)

<comment><USER20> It's useful but I'd like to see a bit more top-level completeness. Every feature should be listed and have at least a cursory description, even if it's not entirely nailed down.

(Maybe it already is like that, but the disclaimers say it's not.)

<comment><USER3> The vast, vast majority does, but there may be some missing bits. Printed out, it's about 170 sheets of paper, so there's a _lot_ there.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> I read through the article and I recognized the pattern of an old C cave bear that refuses to learn new things and understand why safety and type theory matters. Lots of arguments made in that post are either unfair (i.e. the Cargo team stuff) or completely wrong.

Also, if you think Go is a replacement of C, I think you are not a real systems programmer. Go has a GC, in the first place: how can you seriously state it's a replacement of C? Also, you didn't mention it (voluntary I guess), but Rust does have a community-based mechanism to make the language evolve (RFCs).

About the number of features, those are mostly non-breaking changes additions. Rust has editions now. Just… do your homework?

C++ is mostly used as a OOPL. Rust has no concept of OOP.

> Yes, Rust is more safe. I don't really care. In light of all of these > problems, I'll take my segfaults and buffer overflows.

Sorry For Your Loss.

</comment><comment><USER23> ,,Concurrency is generally a bad thing''

Easy speedup of processors ended. Not using system resources efficiently is not sustainable long term. Mozilla created Rust to be able to use the multi- core hardware (especially on mobile phones), thereby improving battery usage as well for rendering web pages.

Rust has it's C++ style problems (compiling time, not good enough IDE support), but the dev team knows about them, and hopefully improve them in the next years.

<comment><USER9> > Rust has it's C++ style problems (compiling time, not good enough IDE > support), [...]

Actually, since language servers like clangd, cquery and ccls, IDE support is not a C++ style problem anymore.

<comment><USER24> There have been improvements for sure, but have you used a good Java or C# IDE? C++ support is still far behind in terms of performance and accuracy.

(I work on a C++ IDE.)

<comment><USER9> Yes, I have used Eclipse and IntelliJ.

Have you used cquery for example ([https://github.com/cquery- project/cquery](https://github.com/cquery-project/cquery))? In my experience performance is excellent and it can even be used with large code bases like Chromium. Accuracy is perfect since it uses the same information the compiler has.

<comment><USER24> Yes, as cquery's README states it has a huge memory overhead because it basically just builds the project and keeps the info around. This is rather like how Visual Studio's C++ IDE support _used_ to work, and it was not fun to wait for re-indexing after making edits.

Alternative Clang-based solutions reduce the memory overhead by doing more on- demand computation, more in line with how C# or Java IDEs work, at the cost of much higher latency because Clang is not designed for anything but batch compilation.

This also isn't a complete solution for accuracy, as it only really works if you're also building with Clang (or something close enough that Clang can emulate it).

Like I said, things have improved for C++, but it's nowhere near what other, more IDE-friendly, languages can do.

<comment><USER9> My guess would be that in C# and Java, re-indexing is faster, because those languages have faster compile times in general. Therefore I would put this as a compile time problem.

> This also isn't a complete solution for accuracy, as it only really works if > you're also building with Clang (or something close enough that Clang can > emulate it).

Well that's a bit unfair, because we're talking about C++, not a GCC or MSVC extension to the language. And if there's some other compiler that isn't standard comformant, I wouldn't put this as a IDE support problem.

Of course there are cases were Clang fails to compile standard C++ code, but those are very rare.

<comment><USER24> Yes- but not only are C# and Java faster to compile in general, they're easier to process small pieces of in isolation. C++ requires everything referenced to be declared previously even just to _parse_. (Modules should help here, at least, eventually.)

But even then, parsing is often required to do complex Turing-complete processing of templates and constexpr, since that determines something's role in the grammar. This forces an accuracy vs performance tradeoff that modules don't help with at all.

So it's not just a compile time problem that _happens_ to affect IDEs, but also an IDE problem, because they can't take nearly as much advantage of the fact that they're only trying to analyze the code, not build it.

And language extensions are hardly unfair. In practice they're used all over the place, and people expect them to work in their IDEs, especially when they're off in some header they didn't write. (Attributes help here, somewhat, when compiler vendors can move extensions into them.)

<comment><USER9> Makes sense, thanks for the explanation.

> And language extensions are hardly unfair. In practice they're used all over > the place, and people expect them to work in their IDEs, especially when > they're off in some header they didn't write. (Attributes help here, > somewhat, when compiler vendors can move extensions into them.)

It's a C++-as-it-is-used-in-the-wild problem then, not a (ISO) C++ one ;)

Anyway: I myself never had any problems, but all my programs build fine with Clang (as all C++ programs should IMHO).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> >Rust will eventually fail to the "jack of all trades, master of none" problem that C++ has.

He's talking about C++ like it's some kind of failure and not one of the most widely used languages in the world. Sounds like the author just doesn't like C++, so it's no surprise he doesn't like Rust either.

>Yes, Rust is more safe. I don't really care. In light of all of these problems, I'll take my segfaults and buffer overflows.

"I don't really care" isn't a good reason for ignoring one of Rust's strongest points. If you're not an expert in C like the author, then this would be one of the biggest reasons for choosing Rust over C.

That being said, I agree than Rust isn't a good C replacement, mainly because it's more similar to C++.

</comment><comment><USER26> This reads like a rant about screwdrivers being terrible hammers.

By the way, there is a lot of polyglot library code out there that is both valid C and C++, which is the reason for using "C/C++" much of the time.

</comment><comment><USER27> I think a better title for this post would be "Rust is not C".

I'm also not sure how stating the number of features recently added to a 47yo language is very small and the number of features added to a 8yo language is very large proves any point.

That you don't care about safety or concurrency has nothing to do with the title, and frankly betrays that this article is more about Rust not being last decade's systems language as opposed to Rust being a good candidate for future projects that would otherwise have chosen C.

</comment><comment><USER28> I've been waiting so much for a way to use rustup (and Cargo, but that's beyond the pull request a bit further down) behind a MITM proxy.

And since Rust has always been Windows-friendly, I had high hopes when someone actually started to implement this support (basically pass "-k" to curl).

Because I had fought with all kinds of git and curl configuration files, until I realized that those don't mean anything to rustup.

The implementation was critiqued in a very civil way. The author fixed the issues. Everything was ready to merge and... in walk some busybodies who under the pretense of caring about security (having no clue about the issue or modern Windows workplaces, and despite clear refutations of their concerns) have seemingly been able to kill this patch: [https://github.com/rust- lang/rustup.rs/pull/1624/](https://github.com/rust-lang/rustup.rs/pull/1624/)

"We need to discuss this with experts". I don't know where, I briefly searched for any such discussion. I guess there was none.

So a drive-by shooting killed a very useful feature. The saboteurs can revel in the knowledge that they drove away a new contributor (I haben't seen any more activity on that GitHub issue). And users suffer.

Thanks a lot! Sabotaging corporate users must feel very good.

<comment><USER3> Part of the issue here is that rustup has not had a dedicated maintainer in a while; we're working on it.

<comment><USER29> Is there a link to the maintainer discussion?

<comment><USER3> I am not 100% sure; I'm not on the tools team, but it's undergoing a big re- org at the moment. I'd get in touch with them: [https://www.rust- lang.org/governance/teams/dev-tools](https://www.rust- lang.org/governance/teams/dev-tools)

</comment></comment></comment></comment><comment><USER30> > A program which uses poll effectively is going to be simpler, reasonably > performant,

Only for newbie values of "performant". I work on data-storage servers. It has been quite a few years since I've worked on one that didn't absolutely need to take advantage of multiple cores to get competitive performance, and I'm very far from being alone in this need. Splitting one server into many separate processes is _not_ a solution in these cases, as it just moves complexity from the in-process domain to the between-process domain where it's even harder to maintain good performance (or even validate correctness). As soon as I read "concurrency is generally a bad thing" the author lost all credibility.

</comment><comment><USER31> > "measured by the number of bullet points [...] on Wikipedia"

> "measured by the number of headers in the release notes of major [...] > versions"

I don't think it's a fair comparison to pull from these two types of sources, compare the numbers and expect a reasonable result.

The entire rest of this blog reads more like a rant about screws not being nails than an actual complain about the languages itself.

</comment><comment><USER32> > Safety. Yes, Rust is more safe. I don't really care. In light of all of > these problems, I'll take my segfaults and buffer overflows. I especially > refuse to "rewrite it in Rust" - because no matter what, rewriting an entire > program from scratch is always going to introduce more bugs than maintaining > the C program ever would.

Are they advocating for never rewriting anything? Like, programming language advancement should have stopped at C cause someone would have had to rewrite something and that would mean more bugs??

<comment><USER9> Most programming languages can call C code, so you don't have to rewrite something when switching to them.

<comment><USER3> Rust can as well, and it can also expose the C ABI too, so it can work both ways.

</comment></comment></comment><comment><USER33> You don't have to care about memory safety, but if you don't you probably shouldn't speak for "systems programmers" as a whole. Systems need to be safe.

<comment><USER30> Thank you for that. Now that you've stated it so concisely, I can see how this is the thing that bothered me about the post. The author is implicitly trying to represent the C user base but doesn't seem to share that user base's concerns, priorities, or practices.

</comment></comment><comment><USER34> OK looking Just at the number of features seems disingenuous. Cpp features tend to idk, increase the level of complexity as there tends to be quite a bit of friction between them. Rust features definitely "work together".

This post seems to have started with a conclusion and worked backwards.

Rust is such a breath of fresh air. Cargo is nuts. The community is nuts. I've been writing rust full time for a couple of months now and I'm not going back.

<comment><USER23> The main problem with C++ are not the new features, but the old obsolate ones. It's too late to fix the language.

<comment><USER34> Also their development process is too slow. Like it would be impossible for me to pitch a new feature to cpp. I can imagine adding a new feature to rust (not that I would but I like that there's the option).

<comment><USER35> I'm appreciating the irony of you complaining that "C++ features don't work together" but also saying that the process of putting new features into C++ should be _faster_. :-)

<comment><USER34> There's nothing ironic about that. If they had a shorter feedback loop, things could be getting fixed faster.

</comment></comment></comment></comment></comment><comment><USER36> Sir_Cmpwn has lost a bit of credibility in my eyes after this article and their behavior in the comments.

</comment><comment><USER37> The current pace of development of C++ is questionable, but Rust is still a fairly young language, so the comparison to C seems unfair. Presumably, the rate of change in Rust will slow down. Although, if you are looking for stability today, the point does stand.

</comment><comment><USER38> The converse is what I've heard with people at REN-ISAC and whom write and coauthor RFCs. (I'm not one, but trust the comments they've made to me regarding this.)

For a new dev to start writing internet-quality code, with C/C++ takes 10 years before they can make reliable code. The procedure takes what amounts to a journeyman style one-on-one until proficiency, 10k / 10 years later.

With Rust, it takes 2 years for a new developer to attain proficiency.

To me, those numbers are the ones that matter. Rust is stable and good, and gets out of the way of the developer... and gets in the way of the developer when coding anti-patterns.

</comment><comment><USER39> "...I'll take my segfaults and buffer overflows"

Well, this speaks volumes. Nothing more need to be said.

</comment><comment><USER40> Age of the langs absolutely needs to be taken into account if comparing stability and feature addition rate.

According to Wikipedia it's 47 years for C vs 8 years for Rust (as of 2019) - it's not that surprising that a 6x older language is much more stable.

</comment><comment><USER41> > Concurrency is generally a bad thing

Erm...

> Safety. Yes, Rust is more safe. I don't really care. In light of all of > these problems, I'll take my segfaults and buffer overflows.

Ok this is nonsense.

</comment><comment><USER42> Concurrency might be a dangerous thing but in microcontroller land, where I do my C programming, interrupts are a fact of life and just polling really isn't a practical solution.

<comment><USER43> Is that how Rust concurrency works under the hood? Polling?

<comment><USER3> Rust has no particular built-in model for concurrency or threading. The standard library currently exposes system threads, and we're working on providing an API for pluggable concurrency models. The most popular of which is a wrapper around epoll/kqueue/iocp.

<comment><USER43> Rust has no particular built-in model for concurrency, but as soon as you want to do anything important with Rust (given the current ecosystem) you're going to run into Tokio, no? It seems to be the community-agreed-upon way to handle concurrency.

Does Tokio use polling under the hood?

<comment><USER3> There are a number of different options. And today, yes, code is tied to one of them. But, and it's not stable yet, futures and executors, the two traits, are being added to the standard library. This lets your code be generic over executors, and there are already more than just tokio. Including an embedded one, for example.

Tokio wraps epoll/kqueue/iocp.

<comment><USER43> > But, and it's not stable yet, futures and executors, the two traits, are > being added to the standard library.

Is this implementation going to wrap epoll/kqueue/iocp?

Would you say Tokio has any drawbacks/flaws/design choices yo aren't a fan of?

What are the popular choices other than Tokio?

<comment><USER3> Traits are not implementations, just interfaces. There won't be an implementation of one in std, just the interface, so that the ecosystem can interoperate.

At the moment, I think Tokio is pretty great. I wish that there was more development bandwidth to help test out some cutting-edge stuff, but I think the design is sound.

It really depends, Tokio is the most popular at the moment. This is because most of the new ecosystem is built around these new, unstable interfaces. Tokio currently runs on the older, not in the standard library one. It's all a bit confusing at the moment, to be honest.

</comment></comment></comment></comment></comment></comment></comment><comment><USER44> This just reads like the author was told to rewrite his code in rust one too many times, and he felt compelled to justify his own choices by bashing rust. Just say you like the simplicity and subtle bugs of C more than having to deal with the upfront complexity of low-level code at all times

</comment><comment><USER45> Of course C programmers are going to think Rust is a poor C replacement. Rust wasn't made for C programmers -- it was made for their replacements.

<comment><USER46> Zig is a better replacement for C and Rust. C programmers no this, but Rust programmers can't comprehend simplicity. They won't know

</comment></comment><comment><USER47> Why do people up vote your flame war post?

Ah, exploiting the human urge to argue about literally anything. Especially when your argument is full of flaws and straw men statements.

</comment><comment><USER48> My biggest quibble with the article is the idea that C will have a replacement. Many languages have already replaced C, in many domains. And yet C is still with us. I suspect it will remain indefinitely, shrinking in relative popularity but growing in the absolute sense. If for no other reason than that every language benefits from having a way of talking to libraries written in other languages, and the lingua franca is C. Rather than writing N^2 foreign function interfaces for N languages, each language can have one FFI library targeting C interoperability.

</comment><comment><USER49> As long as you don't write software for computers that are connected to a network, it's fine not to care about security. For everybody else though, new software should probably be written in a safer language. That doesn't have to be Rust of course.

</comment><comment><USER50> Personally, I think the C community is deeply infatuated with the idea that "we are in fact simple" mentality even though it's not well justified.

C isn't simple. C isn't simple to use.

On the implementation side, it has a complex calling convention. It relies on a memory management runtime without spec'd behavior. Tons of hardware implementation details leak up to the upper levels. C's error handling schemes are inconsistent, and thus complex to work with and to implement.

Being a C programmer isn't much easier either! C's memory managers tend to blow up if misused, but they don't blow up WHEN they're misused. They always cause problems, but it's not clear how or why. You have a bomb in your code that will go off in a random place. Even good debuggers with great tools can find it challenging to find the source of a double free. And that's alongside managing the weakly typed (not to be confused with static/dynamic) world, the pointer arithmetic, the inconsistent library conventions. Oh yeah, the libraries...

C's libraries aren't simple. They have to protect themselves from double inclusion, they can collide with each other, and have wildly different conventions depending on if they're loaded at runtime or compile time. Despite a constant derision of OO from the community, they often affect an "OO" discipline on methods. In reality this asks developers to create the impression of OO behavior by being very (very!) careful with call sequencing. And of course, the price of failure on most of these tasks is at runtime, on someone else's hardware, often with opportunities for remote execution.

When a C programmer says, "C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex," we have to read it very carefully and ask, "What does simpler mean?" Because despite the complexities of being a C programmer and the unstated complexities of the C runtime (and the large portion of unspec'd behavior so glibly ignored in this article to dunk on Rust), they still say "C is simple."

In this case, evidently it means: "Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible."

Go isn't simpler. Go actually aims for a rather broad category of programs (it goes way up into the world of abstraction Python covers, and stops short of the embedded world where C is firmly entrenched because it's well-understood). Go has a sophisticated (and arguably, hard-to-use) concurrency model (didn't the author just say, "Concurrency is generally a bad thing?") and implementation. It has real garbage collection. Its stdlib is expected to have full SSL and networking support builtin.

But Golang is _familiar_ to C programmers. I think that is why we see all the dunks on C++ and Rust in this artcile. C++ and Rust are weird. They're different. Go feels like C, so it's "simpler to learn" even if it requires a whole lot more core concepts and careful implementation than a C compiler.

Maybe Rust isn't your solution. Okay. Maybe C++ isn't your solution. Okay. There's still lots of other good languages to try. Languages that don't ask users to wade among a field of charged rails that the slightest touch can result in catastrophe. Nim or D maybe? There are others, and you can find them.

But continuing to use C with the attitude that, and I quote, "I don't really care. In light of [the complaints leveled at Rust], I'll take my segfaults and buffer overflows" is dangerous. It's unprofessional. It's reckless. It's also a false dichotomy.

The answer to C's problems is to _stop using C._ Not to start using something else specifically. This article makes it clear that the actual goal of this sentiment in the C camp is to _keep using C_. There isn't even a candid ownership of the problems with that strategy.

</comment><comment><USER51> From performance point of view, Rust is comparable to C++ [https://benchmarksgame- team.pages.debian.net/benchmarksgame/...](https://benchmarksgame- team.pages.debian.net/benchmarksgame/which-programs-are-fast.html)

</comment><comment><USER52> You can't overstate the importance of a specification. It is the most loathed thing to write, like unit tests, but in the end is essential. I think the OP romanticizes a bit: K&R C had a spec, a very very very loose spec. It took ANSI a decade to put some meat on it. Early C compilers weren't much help: Sparc had SystemV and AIX had POSIX which are OS specs but still defined C behavior in their compilers, and it made life so much easier in the early 90's when they converged on Gnu.

My favorite part of the article is the footnote. We really need to stop referring to C/C++ as "roughly the same" because they are so so so radically different.

<comment><USER53> K&R C had no formal spec. It wasn't until 10 years after its invention that it did, and that was after a lot of real-world experience.

I would argue that early specifications don't work out very well. In fact, they are often problematic. One example is that standard ANSI C had a proposal for a while that included an Alias keyword. This was such a bad idea, that Dennis Ritchie showed up to the meeting personally to help kill it.

Standards committees are not usually staffed with practitioners, who are busy developing the language and are quite expert in nuance, feasibility, and utility. Attendees to standards committee meetings are almost always not.

And reality does meet the standardization expectations quite frequently. Look at the number of "undefined" or "implementation choices" in C alone. Therein lie careers for security folks.

</comment></comment><comment><USER54> Should the HN rules be amended to discourage self-authored submissions? They seem to circumvent the natural filter that comes with peer-nomination, and suggests they were written with promotion in mind.

<comment><USER55> I thought you had to write "Show HN:" when you were publishing your own content..

<comment><USER56> > _"Blog posts, sign-up pages, and fundraisers can 't be tried out, so they > can't be Show HNs."_

[https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

</comment></comment></comment><comment><USER57> Lack of a formal specification and/or an international standard is the real bummer. That's the biggest disadvantage in comparison to languages like Ada and C.

<comment><USER58> At this stage I'd settle for an informal language description, as long as it was a serious attempt to be basically complete and correct.

It's nearly four years since Rust 1.0 and the reference manual is still calling itself a best-effort document. It's surprising that a project which generally holds itself to high engineering standards is so sloppy in this one area.

<comment><USER59> _> It's nearly four years since Rust 1.0 and the reference manual is still calling itself a best-effort document._

I'm curious what standard this is holding Rust to; C was 17 years old when a comprehensive reference emerged, and C++ was 13 years old for the same. If Rust manages to have a reference by 2030 (and I certainly hope it does) then it will be on track.

<comment><USER58> I think Go and Swift are natural languages to compare Rust to in this respect. Both of them seem to be doing a much better job of reference-level documentation.

In other circumstances the Rust people generally aim for higher standards than "no worse than C or C++", let alone "no worse than C or C++ in the 1980s".

(I mean, you don't see Rust people saying "It took 30 years for C++ to get any form of type inference, so as long as we have something by 2040 we'll be on track.)

</comment></comment></comment></comment><comment><USER58> I think there is a gap in the market for small language which is just a "better C", but developing a new language is a great deal of work, and it would be hard to compete against the alternative of using a small subset of {Ada, Rust, whatever}.

Maybe the large languages should look at defining official subsets, to make life simpler both for programmers and validation. Ada used to have something of the sort (and still does for all I know).

<comment><USER60> I'm curious if you consider Nim or Golang to be a small language that is a "better C". If not, why?

<comment><USER58> I don't think they count as a "better C" for this purpose. I'm thinking of something aiming at the niche that C currently fills.

Having a garbage collector doesn't fit that, and Nim doesn't look small (anything with both destructors and exceptions is getting into complications rather beyond C).

<comment><USER61> Regardless, I use Nim when I need the performance and memory footprint of C. GC is optional.

<comment><USER62> Can you use the standard library without GC?

<comment><USER61> Most of it.

</comment></comment></comment></comment></comment></comment><comment><USER63> It seems that the Rust community is already slowing down with new features. Have a look at "This Week in Rust" updates: the section "Approved RFCs" has the text "No RFCs were approved this week" almost every week now. There also was a discussion of designing 2019 as the fallow year and going more slow than before.

<comment><USER64> That's true, and personally, I hope it continues. However, there are some significant new features that have already been approved that are being worked on right now. e.g., Specialization, const generics and generic associated types. Each of these is somewhat significant in that they might alter how one might write some kinds of code today. But generally, they open new doors by adding more expressiveness to the type system.

</comment></comment><comment><USER65> from compiler's point of view, C++ doesn't really added that much features, and quite stable. imho i believe the C++ ISO committee does consider the possibilities compiler writers are able to implement these features. e.g lambda expression, there's always operator() overloaded available in C++98; Variable template, only allowed in namespace, aka. static member data member in template type; CTAD, take template function argument deduce mechanism and wrap-up for ya; auto, same as template argument, and C++'s template argument is the same as C's typedef, etc. that is to say, to some extend, C++'s features are also written in C++. The new idea could think of is the r-value type, which invented to trigger move constructor, again, using the existing function overloading mechanism to do the job. This maybe not engineering friendly which the writer has to manually nullify the moved object's internal pointers as for Rust just using type system to prevent you from using it.

</comment><comment><USER60> Sincere question, I didn't realize that Rust didn't have a specification. How can folk say Rust guarantees safety when it doesn't guarantee an implementation? I don't see how you could have one without the other.

Now, admittedly, the lowest level language I've used is Go!, so fairly abstracted (and no memory management), so I might be mistaken, but it doesn't seem like you can have safety without a specification.

<comment><USER3> > How can folk say Rust guarantees safety when it doesn't guarantee an > implementation?

Just because there isn't a formal spec, doesn't mean that the underlying systems aren't built with some rules, grounded in computer science and math. We believe that the systems we've set up do guarantee those properties, even if they haven't yet been formally verified. And a subset of them _have_ been formally verified, which also increases confidence.

Adding to that confidence level is empirical results: while people have found implementation bugs, which will always exist in any implementation, nobody has managed to demonstrate that the model is fundamentally broken. That it's been years, and many people have tried, also leads us to suspect that our conclusions are correct here.

Put another way: not all specs are equal. Some are formal, some are informal. Just having a spec doesn't actually guarantee anything either. Most languages don't have a specification at all.

<comment><USER60> > Put another way: not all specs are equal. Some are formal, some are > informal.

So is the argument that the language reference is as good as many existing language specifications, and my complaint is only one of semantics?

<comment><USER3> Yes, it's basically about what you mean by "guarantee". Very few things are formally guaranteed. People tend to use "guarantee" to mean "I believe this is true with a very high level of confidence."

</comment></comment></comment></comment><comment><USER66> Totally agree with his observations but I disagree with the conclusion. C is a ok programming language. The first language that realises that simplicity above all is the most important feature of any language and uses the same safety measures like Rust is going to win over a huge user base.

<comment><USER67> Low level programming in a safe way is a complicated endaevor. The assembly language with a few instructions can be the ultimately simple language, but it doesn't offer the same features that Rust does.

While I am all for simplicity, I just don't think it's all that obvious that a language could possibly be simple, fast, and safe at the same time.

<comment><USER66> Sorry when I mean simplicity I do not mean it in the ASM sense but more like LISP. Very simple basics, very powerful concepts.

</comment></comment></comment><comment><USER68> If OP thinks Firefox is one of the largest C++ codebases in the world then OP has a very limited worldview.

<comment><USER69> That's true though, as far as the open source projects go.

Only bigger C++ open source codebase I can think of is LLVM. What else did you have in mind?

<comment><USER53> Er, firefox is reported to have 12 million, while llvm has 2 million. gcc is 7 million.

</comment></comment></comment><comment><USER70> I keep trying to make up my mind whether this author is a C programmer. Hmmm.</comment>


Consider applying for grad school - <AUTHOR> https://80000hours.org/2017/11/consider-applying-for-a-phd-program-now/ <comment><USER2> One point jumped out at me, which I haven't seen anyone respond to:

> We are concerned about untrained amateurs going directly into trying to > solve very difficult global problems. They can then cause harm overall, by > lowering the average quality of analysis or launching ill-considered > projects due to a lack of experience or understanding. A PhD reduces the > risk you'll accidentally do this.

This point is operating off of a different fundamental paradigm than the comments here that are talking about opportunity cost. Opportunity cost is looking at personal benefit, while the above is looking at the effectiveness at solving hard, large-scale problems.

Obviously, money is important, but for many (often those who are fortunate enough to have reached a certain income level), it isn't the only thing or even the primary thing.

I don't have much insight into how true the point actually is, but I found it to be interesting.

<comment><USER3> It's not an unreasonable opinion, but I doubt a PhD can make up for lack of real-world experience. Likely, the best way to get better at solving global problems is by doing just that for years, preferably alongside others with more experience.

IMO learn to swim in the pool.

<comment><USER2> I've wondered if working for 10 or so years and then getting a PhD could be a good strategy.

<comment><USER4> I've been in the industry for 12 years and I've been deeply considering going back to school for a PhD. I love working on fundamental CS and I'd greatly enjoy the sort of work that I'd have access to during and after a PhD. The challenge is that, for folks who haven't won the equity lottery or racked up FAANG RSUs, it's a huge financial challenge to consider going from an engineering salary to PhD stipend. Considering I still have student loans from my BS, and a spouse who doesn't work that is also being supported on my salary, it's almost impossible to figure out the logistics of working on a PhD full time.

I've found a few programs that are open to considering part-time candidates, but they are few and far between, and most of the ones who consider it still strongly recommend against it.

<comment><USER5> Have you heard of [http://www.mrmoneymustache.com](http://www.mrmoneymustache.com) ? If you still have student loans after 12 years in the industry, you might want to re- examine your spending/saving patterns

<comment><USER6> Just discovered this website, this philosophy looks really interesting! The ultimate goal of early retirement is appealing, so the discipline has a purpose. This might get me somewhere, instead of saving for the sake of getting richer. Thank you for this discovery!

</comment></comment></comment></comment></comment></comment><comment><USER7> > PhDs are intellectually demanding, and not everyone will be able to finish. > In the US between 41 and 78% of people who start PhDs have finished them > after ten years, depending on their sub field. Computer and Information > Science has the lowest graduation rates (41%)

Right...

I've met a good number of PhD dropouts - I am one myself. None of them dropped out because it was too "intellectually demanding." They all dropped out because the work was unrewarding, the odds of employment in academia were poor, and the work in academia was unappealing.

Looking at Computer and Information Science in particular, I might suggest that high availability of high paying jobs in the private sector is worth looking at rather than the "intellectually demanding" academic program.

<comment><USER8> While I suspect you're right, anecdotal evidence must be fairly weak here. Not many people would admit to themselves that they weren't up to the intellectual challenge -- let alone admit it to other people.

<comment><USER9> I guess I'll admit I wasn't up to the intellectual challenge in that, all else being equal, being smarter might have got me through.

</comment></comment></comment><comment><USER10> I think the context that most commenters are missing here is that this is not an argument that you will make more money with a PhD.

The focus of 80,000 hours is on "effective altruism" where the goal is to have the greatest positive impact on the world.

And it's not super hard to believe that there are quite a few jobs that require a PhD, often due to plain credentialism, that have significantly more impact than your average software developer at a well paying company.

I'm still not going to do a PhD, but I'm really not the target audience here, and it's sort of not surprising since 80,000 hours is an outgrowth of academia itself.

</comment><comment><USER11> I was expecting reasons why now is a better climate to apply then in previous years. That would be interesting, but instead it's a list of generic reasons to apply for a phd. Yes, I know that phd's can open doors.

<comment><USER12> I read the whole article, including the "why not to get a PhD part." I still thought it was way too kind to the "get a PhD" side of the equation. PhDs represent a tremendous opportunity cost, and I have not seen good evidence that they _causally_ improve outcomes in the vast majority of cases.

<comment><USER13> This may shock you, but some people prefer doing research to working a normal job and earning lots of money. Those are the types of people that should and will do PhDs (there are unfortunately a lot who think like you and still try and do a PhD for god knows what reason).

<comment><USER14> You don't need a PhD to do research. All information is free now. It's fully possible for individuals to self teach in a working environment and be capable of performing effective research with 2-4 years of good experience after undergrad. To assume that the only way to accomplish this is via PhD is silly. This is especially the case when talking about computer science fields, where the barrier to entry is basically owning a cell phone.

<comment><USER15> Not everyone is a certified genius like Grigori Perelman who can do great research while living in a vacuum. You need great advisors who will guide you, and fellow grad students who you can ask for help and bounce ideas off. The academic enviroment is invaluable for someone doing their PhD, and it's pretty much impossible for someone with somewhat above average intelligence (and let's face it, most PhD's are not geniuses) to do good research with just a computer.

The "all information is free and you can study anything using just a computer" is a stupid meme that doesn't work for the vast majority of people.

<comment><USER14> My statement is not that people can't benefit from a PhD, but that it is not a strict requirement. You are presenting a strawman.

<comment><USER15> What is that strawman exactly? You are saying that anyone can do PhD level research with just a laptop and the internet. I am saying that that is extremely difficult and impossible for the vast majority of people.

<comment><USER16> Maybe I'm misreading, but the strawman seems to be that research can be done in a vacuum without collaborating.

The parent commenter seems to be suggesting that a PhD isn't a requirement to work successfully on interesting research problems. It's possible to go online and read the same papers everyone's reading. You can still talk to people to get guidance and find out known things that are not published.

<comment><USER15> Ya I guess it was something of a strawman. But it's pretty close to the truth since it's very hard to get good guidance outside academia or places like google with lots of phds around.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Nothing in the article about what one really learns in a Ph.D. program. Here are the things you only learn in a Ph.D. program, more or less in chronological order:

1\. What kind of information you will find in each section of a research paper in your field.

2\. What are the major research programs in your field and where they disagree.

3\. How to identify where a paper's author stands with respect to the major disagreements in your field.

4\. How to decide that a paper isn't worth your time without reading all of it.

5\. How do you write a research paper?

6\. How do you decide what research to do? (This decision will often be made for you for the first couple of years.)

7\. Where you stand with respect to the major disagreements in your field.

8\. How to synthesize half a decade's work into a realtively brief document.

Notably, these skills don't help you do any of the following:

1\. Manage a research group in an academic setting.

2\. Teach undergraduates.

3\. Manage people in industry.

You might pick up applicable skills along the way, but these are incidental. Any specific skill, any particular knowledge, can be obtained without getting a Ph.D. The Ph.D. teaches what you need to know to advance the field.

I'd like to return for a second to talk about teaching undergraduates. It's a very important thing to do. Ph.D. training _ought_ to include pedagogy. Standards for university instruction are shockingly low, and professors are rarely held to account for failing to teach the material well, especially at R1 institutions. However this comment is not about what you should learn, but about what you'll actually learn in a Ph.D. program if you decide to enroll tomorrow.

<comment><USER18> I agree with your main point here, but I think you're trying to paint and overly broad claim about PhD programs, which are extremely different between institutions. It's like saying "working at a company is like this... you learn this but not that."

Specifically,

1\. Senior PhD students in many research groups can become de facto managers of the group, especially when the professor is on sabbatical. PhD students are often involved in the funding, presentations, recruitment, and represent the group. Some PIs/professors empower their PhD students to run a mini research group within their group.

2\. I've seen some PhD programs have a strong emphasis on teaching undergraduates, both as in teaching undergraduate courses directly (which many PhD students in the humanities and social science already do), serving as teaching assistants with a substantive educational role (not just grading), and mentoring them in research or more general advising. For example, Brown University and Princeton are known to have a good research-teaching balance for PhD students. Brown has a large number of programs that help PhD students get more involved in undergraduate teaching [[https://www.brown.edu/sheridan/programs- services/certificate...](https://www.brown.edu/sheridan/programs- services/certificates)]

</comment></comment><comment><USER19> Huge opportunity cost for 5-8 years, think carefully. Also, very very few jobs in academia so don't plan on those. Was interesting and learned a lot, not sure the most useful use of those years.

<comment><USER20> indeed. a few folks in the FIRE (financial independence / retire early) space talk about being able to save enough money to be retired or semi-retired from 7-8 years of full-time work (this doesn't require FAANG scale salaries, just a combination of working somewhere that pays pretty well, not spending much money, building up investments, and luck to avoid getting clobbered with huge medical expenses. and the luck to start from a context where this might be an option for you at all)

edit: adding a few links to reading material

One of the main things is to focus on maximising your savings rate, i.e. your amount of savings divided by your revenue (for most people this would be their income from their job, minus income tax). You can increase this by making lifestyle changes that let you sustainably decrease your expenses, and by getting a job that pays you more, or other sources of income.

William Bernstein has written a bit about investment and asset allocation. He has a free publication titled "If You Can" geared at young people to help them plan for retirement: [http://efficientfrontier.com/ef/0adhoc/2books.htm](http://efficientfrontier.com/ef/0adhoc/2books.htm) One of his general pieces of advice is to invest 15% of income every year into low-fee investment funds, i.e. to achieve a savings rate of 15%. If you do this consistently for around 30 or 40 years, you can retire.

Things get much more extreme for higher savings rates. For example, if you hit a savings rate of around 75% year after year (saving three quarters of what you earn after tax) and invest this, then with some assumptions about rates of return on investment, after about 8 years there should be enough income from investments to cover your expenses:

[https://networthify.com/calculator/earlyretirement](https://networthify.com/calculator/earlyretirement)

[https://www.mrmoneymustache.com/2012/01/13/the-shockingly- si...](https://www.mrmoneymustache.com/2012/01/13/the-shockingly-simple-math- behind-early-retirement/)

You need to be a bit careful re: assumptions about stock market returns over the next few years or decades, some markets (e.g. the US stock market) are priced very highly compared to historical prices, so assumptions about rates of return from investment that seemed reasonable a decade ago are probably over-estimates now.

<comment><USER21> Interesting, where does one learn more about that?

<comment><USER22> [http://reddit.com/r/financialindependence](http://reddit.com/r/financialindependence)

</comment></comment></comment></comment><comment><USER23> Looks like author is focusing on grad school as in PhD only. PhD highly depends on the field. For example in hardcore sciences, to accelerate career PhD is often helpful. However, in applied fields it depends on industry to industry.

I was doing my masters with focus on Human-Computer Interaction (HCI). I was considering PhD but after talking with academic advisor, I realized having PhD will limit my options to either research labs or academia, for which jobs are few and far between. For industry jobs, I felt I didn't need PhD. Yes, you might be few steps below in the ladder but you can quickly catch-up as you climb.

So everyone should seriously consider where they want to end up. If research is something they fancy and their field has ample research opportunities or can be leg up in the industry with PhD then PhD is a great option given the opportunity costs.

</comment><comment><USER24> I'm very interested in (applied) AI research positions but wasn't quite prepared to commit 5-8 years to a PhD program. In order to validate my interest in research, I've enrolled in a two year Computer Science Master's program at Tsinghua University. This program has a thesis component, allowing me to participate in research and potentially get a publication. Depending on how much I enjoy the content, I plan on applying to AI fellowships, a PhD program, or Machine Learning Engineering positions after graduation.

Thought the program hasn't started yet, I hope that this is an alternative path for those interested in research but not quite ready for a full PhD.

</comment><comment><USER25> If anyone wants a PhD by studying how to make software engineers more productive, my website is in my profile.

<comment><USER26> To increase productivity of engineers include the following in all employment contracts:

"All engineers will become as rich as the founders and investors if this company succeeds."

Instant productivity increase.

<comment><USER27> This is a tautology. The more you are paid, the more productive you are by definition.

<comment><USER25> This morning I listened to the Freakonomics podcast from July 18th about "Why we choke".

About 22 minutes in, a researcher is discussing a study he did where they paid participants a months wage for a single task to see if they would perform better. They didn't. They actually performed worse! A follow up study at MIT found this to be particularly true for cognitive tasks.

Would this apply to a job over time instead of a single task? Probably not, but I'm also not convinced that salary will increase productivity after some relatively low amount.

<comment><USER27> I think there's "productivity" from two standpoints. In the worker's eyes, she's more productive if she's paid more, by definition. In the employer's eyes, she's more productive if she produces more for the company, by definition.

A classic "efficient" market should close any gaps between these two definition, but it doesn't work perfectly in practice.

</comment></comment></comment></comment></comment><comment><USER28> I assume this refers to a PHD. The masters degree I got is also post-grad.

I'm not sure if anyone else covered it but you have to have a certain amount of money to get a PHD. I was approved to enter a doctorate program at Stanford. I couldn't afford it so I went to HP to earn some money. After the five-year approval expired I was disappointed that I could never afford it. (We're talking astronomical numbers here).

<comment><USER27> When I was a student 30 years ago, the rule of thumb was: Don't get a graduate degree unless someone else is paying for it. In my field (physics), a first or second tier school would provide free tuition plus a stipend if they expected to get any students.

Don't know how things are now, or how they are in other fields.

Now, of course free wasn't exactly free, because studying in grad school was potentially at the expense of working a regular job. That's another topic.

<comment><USER29> Yep. If they're not funding you, it's both _a bad idea_ and a soft reject.

Hell, last I looked, Standford won't even _let_ you self-fund all the way through, at least in my field.

</comment></comment></comment><comment><USER30> Getting a Ph.D. for career reasons is like taking up drug addiction for creative writing reasons. Source: I have a Ph.D.

</comment><comment><USER31> I'm a MechE so this is probably different compared to software. A masters is far better in terms of ROI compared to PhD. I seriously contemplated to complete my PhD after my masters but an additional ~4 years of school was not worth it financially. Your wage is not much different (though the type of work and responsibility might be different) and sometimes masters + 4-5 years actually make more than a PhD grad. Also, you make a full wage 4-5 year earlier. That meant a lot for me in terms of starting my own family and such.

</comment><comment><USER32> I can't wait until you can make new strains of E. coli on your desktop/iPad. Time in grad school is often spent cloning. It would be really great if there were more community-accessible Core facilities available on a subscription service.

<comment><USER33> I remember specifically looking at cloud labs because of your sentiment above. Unfortunately, they aren't that advanced yet.

</comment></comment><comment><USER34> I know this isn't popular. But I will say it - since I know it goes unspoken in the industry. When I see a CS MS degree I assume the person is terrible. I am _always_ proved correct. I can count on one hand resumes of people that gets a CS BS degree _THEN_ a MS degree in CS [15 years of looking at resumes]. In the US, if you get a BS in CS you usually take off doing cool stuff. CS Master degrees are full of people not majoring in CS for the right reason [eg, never played with computers as a kid]. If computers were your passion you would have got a BS in it.

<comment><USER35> My experience is the opposite of yours. Oh look, we cancel out. Hurray for anecdotes and biases!

<comment><USER36> I mean, if they're coming from a different major, it's the equivalent of hiring people after sophomore year. If they haven't been programming outside that, that frankly isn't enough time to be a good programmer.

<comment><USER35> What a weirdly specific statement that has little connection to the parent or reality.

Remember that we're responding to:

> _I can count on one hand resumes of people that gets a CS BS degree THEN a > MS degree in CS [15 years of looking at resumes]._

In fact most people who get an MS in CS got a BS in CS first. And all MS programs have prerequisites.

</comment></comment></comment></comment><comment><USER37> I always wanted to get a PhD, but I don't have a BS.

Is there any way I can skip the BS?

<comment><USER21> Bill Gates did it, so I guess it's possible?

<comment><USER38> Bill Gates didn't do it - he doesn't have a PhD at all. He has honorary doctorates, but that's not really what we're talking about here.

<comment><USER39> I think that's the entire point: Gates has honorary doctorates without ever getting a bachelor's. So, yeah, some people have gotten a doctorate while skipping the BS (if we assume BS means Bachelor of Science).

</comment></comment></comment></comment><comment><USER21> Interesting contrast to the recent wave of posts about how you should absolutely not go for academia in the current market of having 1 job spot for every 3 PhDs. What's one to make of this?

<comment><USER40> 80,000 Hours is a website made by members of a very particular subculture. The "prototypical" PhD they're imagining is in computer science, probably with a focus on machine learning, probably at a highly-ranked school, by someone who went to a highly-ranked undergrad.

Job prospects are relatively good. Pay is bad but industry internships during summer can compensate. Academic jobs are not quite as scarce, and R&D jobs in industry are plentiful. There is not an air of failure or taboo about moving on from academia after the degree.

The calculation on a PhD is very different compared to most other fields, and certainly compared to humanities PhDs (which actually charge money to attend!)

<comment><USER41> This, also their audience is people trying to optimise for improving the world rather than making money.

</comment></comment></comment><comment><USER42> Of course here is a counterpoint from Jonathan Katz , a professor of physics, about doing graduate school.

[http://katz.fastmail.us/scientist.html](http://katz.fastmail.us/scientist.html)

TL;DR. Don't do it!

<comment><USER43> From that article: "Why am I (a tenured professor of physics) trying to discourage you from following a career path which was successful for me? Because times have changed (I received my Ph.D. in 1973, and tenure in 1976). American science no longer offers a reasonable career path. If you go to graduate school in science it is in the expectation of spending your working life doing scientific research, using your ingenuity and curiosity to solve important and interesting problems. You will almost certainly be disappointed, probably when it is too late to choose another career."

People saying related things:

[http://philip.greenspun.com/careers/women-in- science](http://philip.greenspun.com/careers/women-in-science)

[http://disciplinedminds.tripod.com/](http://disciplinedminds.tripod.com/)

[https://www.its.caltech.edu/~dg/crunch_art.html](https://www.its.caltech.edu/~dg/crunch_art.html)

[https://web.archive.org/web/20130115173649/http://www.villag...](https://web.archive.org/web/20130115173649/http://www.villagevoice.com/2004-04-20/news/wanted- really-smart-suckers/1/)

A previous comment I made with quotes from those links four months ago with various replies (then the topics was "Time to talk about why so many postgrads have poor mental health"): [https://news.ycombinator.com/item?id=16725676](https://news.ycombinator.com/item?id=16725676)

For all that, there are many good STEM-related jobs which seem to require a PhD these days, so obviously there are nuances to the topic and whether a PhD is worth it. If you are getting a PhD and someone else is paying for it (current job or a fellowship) and you already know and like the professor who you will be working for, and you already know of a good industry job prospect (in five to seven years, so hard to predict), and you like academic work, then it may not be quite as financially risky as otherwise (although it still may be emotionally draining). Also, if you are independently wealthy and do a PhD for fun, then again a PhD can make sense.

For people in the USA thinking about getting a PhD, consider schools in Western Europe as they tend to be more research-oriented with less-to-no classroom busywork.

It's sad things have come to this in a country with as much wealth as the USA -- especially given how much advanced research can (in theory) potentially improve people's lives if you are allowed to research such things.

Bottom line: as people have said here, a PhD represents a tremendous opportunity cost with a significant risk of having nothing to show for it.

</comment></comment><comment><USER44> I'd like to. Do graduate programs accept devs who have been working the last decade?

There are areas I feel I could be helpful with, e.g. creating reproducible experiments or ensuring a codebase could be open sourced in relation to a paper. It's a lot of grunt work that nobody really has time to do.

If that were possible, I'm not quite sure where to start with executing that plan. (Chicago area, FWIW.)

<comment><USER45> I'm in the same boat - The PhD admissions proces over-indexes on Letters of Recommendation from other academics. I don't think I can get those because I have not actively stayed in touch with my professors.

I went through the existing process once and promised myself I would never waste that much time again. But if there's a program that genuinely values industry experience, and is willing to look past recommendation letters from academics, I'd jump at it.

<comment><USER46> A significant number of PhDs drop out, and likely literally everyone undergoes some sort of huge realization of how doing a PhD is completely and surprisingly unlike what they expected (which is still true even with all the advice telling people that doing a PhD will be surprisingly unlike what you expect). Someone dropping out of a lab is a significant loss in time and resource investment which labs would prefer to avoid, and the biggest predictor for staying in a PhD is substantial experience doing research (to have some sense of what the lifestyle is like) and little experience with higher paying jobs (here at MIT, I see many PhD programs prefer people straight out of undergrad, even though older people are orders of magnitude more productive in the early phase of their PhD).</comment></comment></comment>