Search your heart, do you think this story ends similarly if they decide to all do "modern C++" instead?
My guess is that even with initial discipline in the form of code review and style enforcement by one or two people, the C++ descends into a riot of different opinions about, as usual, which are the good bits.
A similar piece of software could be written in C++ but I doubt it gets written successfully, in similar time, by this team. I reckon the post mortem of such an attempt would be written off as "Don't do rewrites, duh"
This is an exceedingly silly conclusion. "Similar pieces of software" are coded in C++ and shipped every single day, without anyone saying "and we managed to do it in C++, too!" The emphasis should be on what the software does well, and how, not on what hoops the developers were jumped through on the way.
RocksDB, as I understand it, is a pretty old piece of software, forked from a Google product, which was already a pretty old piece of software, all written in C++. Doesn't seem to have previously been written in Python, doesn't seem to have a team of non-C++ programmers who decided to just learn as they went, and so it's not clear what parallels you expect to draw.
Maybe they're doing a Rust rewrite too? I'd be interested to read about that.
> Search your heart, do you think this story ends similarly if they decide to all do "modern C++" instead?
It sounds to me they already had a good chunk of it written in C++ with python glueing it all together.
From a ‘dev velocity’ standpoint one would think having the senior devs learn a new language and rewrite an entire database wouldn’t make sense when they could just systematically replace the python parts with C++, which they already knew.
Or, who knows, maybe all their initial issues stemmed from the locations of semicolons around the else keyword?
> it seems irresponsible to move your entire team to a programming language none of them knows
Based on my experiences, I would agree. There seems to be a very important difference between my experiences, which probably align with most of the industry, and the Pinecone team. My career has been working with average developers doing ordinary business and internet things. Stuff that takes organization and teamwork, but not necessarily advanced or esoteric knowledge. So the COBOL programmers that went to the "Java in 21 Days" training that I consulted with, or the C# programmers who went with Go, they did poor-to-OK, but that was Good Enough.
The Pinecone team, though. They were already writing C/C++ to solve Hard Problems. As experienced programmers, they probably already understood the landscape of systems languages with pointers and having to manage their own memory. Rust, while imposing, would not be a huge leap for them.
Another aspect worth noting: they did they re-write incrementally, never completely abandoning the existing system. At least it seems so. I'll be interested in seeing the presentation from the upcoming talk about the rewrite that's mentioned in the story.
If you start the article at the top instead of where the hot link points (which is its own discussion) it starts by talking about mathematically proving why this form of database is faster than theory suggests it to be. Definitely not your average boot camp devs working on this one.
Precisely. Also, it wasn't one of those cases where management decides to move people off of the language they know to one they read about in InfoWorld or CIO Magazine. Or worse, had a golf buddy tell him how great it is.
In the words, the team wasn't moved, the team moved itself.
There are better threads to trash C++ hackers on than this one. It’s literally about insanely successful software written in C++, maintained successfully for a decade, that seems to have survived a port to another language.
No, modern C++ is still cobbled together from tools built in a different era. It doesn't even come with a package manager/build system.
Just on the fact that cargo/crates.io exist and it has modules - it would have to be really bad to make me go back to C++ if I ever need to write something at that level.
There are package managers and build systems. MS ships a build system with visual studio and msvc and they have a fairly capable package manager in vcpkg.
I like cargo better than any c++ tooling but those tools don't really make a ton of sense for c++ where every platform has a different compiler.
Ultimately, I agree. I don't think I'll be going back to c++ any time soon, but for me it's more about the tooling fragmentation than the tooling itself. I actually like the language itself.
I mean sure, there are many environments you can use for any particular platform - but that's not how I develop software these days - I need my code to run on my Mac, my coworkers Windows machine and our deployment servers on Linux - with the least ammount of fuss possible.
I wince when I think about how much time I spent dealing with that crap back when I was doing C++.
Yes. This comes across as "we are so smart, this project wasn't hard enough to demand our full attention".
Coding in a manifestly immature language signals that you are not really serious about being used where long-term support across a variety of platforms may be important. The language is still more likely than not to fizzle. If it does, it makes your flagship project a niche player.
Fizzling is the normal fate of any new language, absent a miracle. Only a tiny handful of languages get a miracle.
In any given week, more people pick up C++ or Javascript to use professionally than the total number now employed to code Rust. Not to fizzle, it has to increase its adoption rate by orders of magnitude, but its fans are almost uniformly hostile toward any measure that could make it easier to adopt.
> its fans are almost uniformly hostile toward any measure that could make it easier to adopt.
Do you have an example exhibiting what you mean here?
I would self-describe as a fan of Rust, but I also think I'm pretty realistic about its limitations and that every language has its niche. I will say that as far as miracles go, being the most-loved language on SO for seven years seems like a bit of a (minor) miracle here, and at about 87% loved vs Python's 67%, it's not exactly eking out a win. It'll take time for it to grow in market share, but it seems likely it's on its way, given that it is, for example, breaking into the Linux codebase - something C++ wasn't able to do.
Is Linux really your go-to example? Linus is noted for his irrational hostility to C++. His complaints are proved silly or, at best, obsolete by the example of Serenity OS.
An example of a measure to make the language easier to adopt is to allow borrow violations to be made a warning when building in debug mode. All violations would need to be patched up before release anyway, so it does not change the language any, but the violations might be in code you will delete before that. Forcing borrow cleanliness in dead code before you can work on important code feels just spiteful.
People invent the most ridiculous objections, including that the compiler would not know what code to generate, or that it would split the language into two dialects. My conclusion is that the loudest Rust fans like that they are a select few, and don't want it adopted mainstream. They might win.
It seems like a bad idea to allow what is arguably the main selling point of the language to be turned off by a compiler flag so someone can build the rest of their program on top of that shaky foundation.
You seem quite certain of your opinions, especially that Rust will fizzle out. I'll bet $100 that in 2025
- it's still used at Meta, Google, Amazon and other large companies. Once a language gains critical mass at a large, profitable company it will be maintained one way or another.
- It will be used in the Linux kernel as well.
If you have any other objective measures of usage/popularity/usefulness, I'd like to hear it.
> In any given week, more people pick up C++ or Javascript to use professionally than the total number now employed to code Rust.
If you can tell me how you measure this I'll take a bet that this is wrong as well.
Every language you can think of, and many you can't, are in use somewhere at every large company. That is no distinction at all. So, no bet.
If it gets into the Linux kernel in any capacity, obviously it will still be in there as long as anybody still uses whatever it does. That, also, is no distinction at all. So, no bet.
I am not expressing opinions. I am expressing observations, and expectations that seem to follow. If you have other observations that bear on the question, bring them.
Rust is great, but modern C++ is great too.