> Rust is easy to learn. For seasoned C++ programmers, Rust is easy to learn. When they first start out, Rust learners usually spend most of their time making sense of ownership and lifetime. Even if they don't explicitly express these concepts in code, experienced C++ engineers always keep these two concepts in mind when programming in C++.
I was happy to see this as well. As a 'seasoned' C++ dev myself, when I learned Rust, I was pleasantly surprised to see those implicit concepts made explicit in code.
Hot take, I feel like people that complain Rust is hard typically write bade code in other languages. Rust is just preventing you from making common mistakes or using patterns that make your code hard to reason about and debug later.
> But as more and more engineers joined us, some shortcomings
> of C++ came to bite us: unreadable coding style, memory leak,
> segmentation fault, and more.
* unreadable coding style: This is not a C++ problem.
* memory leak: Memory leak is an old C++ problem, since C++11 there is no reason for not using smart pointers.
The only point that could be attributed to C++ is the segfaults perhaps, due to its lack of safety. But your other two points made me skeptical about Rust bringing you much benefit. I am specially concerned about throwing away months worth of code. Rewriting everything from scratch is what newbies love to do and will most likely get you in the same mess you were in. Try to learn with the error of others [1]. And btw, the problem is usually who writes the code and not which language is used.
What's often neglected is the excellent tooling around Rust, that alone is reason enough to switch from C++, where you have a really fragmented tooling ecosystem and you're often required to deal with complex Makefiles or build config as well as download dependencies manually. Most of that just disappears with Rust, unless you're developing code that interfaces with existing C/C++ libraries.
Fascinating how defensive C++ lifers can be. Rust builds on the knowledge of decades of C++ programming. It’s basically a compiler enforced set of C++ best practices. It’s strange how hostile some in the C++ community are to Rust.
I could be wrong, but I think there's few big camps of people.
The camp that thinks Rust is just unnecessary fuss because "you can do it all" in C++ already. They pride themselves with knowing C++ esoterica, and don't like that Rust lowers the entry barrier to writing similar software. They want an exclusive club. They also see ownership as a nuisance. They know you can be equally reckless in Rust too, but they don't like that Rust is so "in your face" about it, too.
The camp that is afraid Rust will marginalise C++ and hence push them towards undesirable (even if high paying) jobs.
There's the camp that's jaded by seeing too many fads come and go, and probably just burnt out at some point. So, they just want to work with what's there and be left alone. They don't want to learn something that they know (incorrectly or not isn't for me to judge here) will be dead in the water soon. And they'll have wasted their energy on it for naught. Or in short, they see it as an unwelcome distraction. This camp also includes "but it has no ISO specification for aviation/etc" too.
I think all these are wrong.
I don't think C++ will be marginalised, it just won't be the default choice for certain domains.
I don't think the extra tooling is a nuisance, if anything in my experience it unburdens the mind from non-domain concerns.
And I also don't think it's a fad, given how productive the language makes people feel, and the fact the Rust Foundation is very serious about the longevity of the project, and that it has many big-player backers.
There's also obviously others too; people come in about 8 billion flavours.
> It’s basically a compiler enforced set of C++ best practices. It’s strange how hostile some in the C++ community are to Rust.
Well, the syntax is alien and new, it doesn't do OO the way 9 out of 10 working developers expect it to, almost all C++ popular design patterns have to be rejected, many of the claims("fearless concurrency") are exaggerated and the Rust evangelists are really really toxic when referring to C++ or C, often simply claiming that fewer bugs is worth the tradeoff from switching to Rust.
I literally saw a comment on HN this past week complaining that OSes are not switching to Rust, almost completely ignoring the fact that any rewrite of a 3 decades old codebase is going to introduce more bugs than it is going to prevent, even if you have perfect memory safety (which you won't, in an OS).
In all honesty, Rust would have been adopted orders of magnitudes faster had Rust evangelists been welcoming, and not accused of being defensive or hostile.
I mean, look through this very page full of comments, and be honest, how many of the comments talking about C++ developers are welcoming to C++ developers?
You have to remember that we die. So what you learn til 30, say, you capitalise on till 70, and then you retire & die.
There isn't another live to live until 30 "again", and then be within the Rust culture.
Rust has, by analogy, stapled it's "Ninety-five Theses to the door" of C++ and those C++atholics are afraid their way of life is ending before they do.
Well it will suck out a lot of potential jobs from the C++ market, at least in the longer time horizon. And many people invested almost their whole lives into doing C++.
the fact we might have got sick of your evangelism and lies hasn't crossed your mind I guess
>It’s basically a compiler enforced set of C++ best practices
Its not, its a whole different programming paradigm where the compiler dictates how you write your software. You dont let your creative facilities to drive you or whats best for your domain - you just obey the language rules...
> But as more and more engineers joined us, some shortcomings of C++ came to bite us: unreadable coding style, memory leak, segmentation fault, and more.
One advantage of Rust of C/C++ that is underreported is the that Rust makes it easier to operate a team with diverse levels of experience/expertise. One or two senior engineers set up the tone, design and coding standards. Junior folks try to follow but if they screw up Rust offers more checks and guard rails limiting the blast radius. Many bugs simply do not make past the borrow checker and type system. This also helps when churn and attrition happens in the team. I witnessed quite a few horror stories when aspiring but not-yet competent C++ coders wrecked havoc in C++ code-base when seniors were busy with something else.
>But as more and more engineers joined us, some shortcomings of C++ came to bite us: unreadable coding style, memory leak, segmentation fault, and more.
- Seasoned devs but they never heard of clang tidy/format
- Memory leaks on a new db codebase where each component should have clear ownership of data or pass to the next pipeline/stage - you dont even need smart poirters here, just a half decent design.
- I am not even going to mention sanitizers, probably rocket science for them
You can't revert this trend - C++ is a legacy language being depreciated by more and more projects.
C++ and Rust are simply not competing on the same level. You don't need a complicated "enterprise" building farm/cluster to build your project, dependencies are managed by the guys who also write your compiler, there is a growing community that actually listen to your feedback and you don't need to wait 40 years to get networking support into the standard library. What C++ can offer? Languages like Rust, Golang and Zig all want their users to focus on their applications, while C++ just wants you to focus on C++. OO was a cool concept back in the 90s, but that was 30 years ago when you have 8MBytes of RAM if you are lucky - who wants to model every program using OO in 2023?
It has never been a better time to depreciate the C++ language and codebases written in C++. Museum is a much better place for C++.
I really like Rust. I like C, and C++ too. I find a lot of C++ and C detractors are nit-picking and over-promising the-new-shiny-thing, or are probably not great engineers to begin with and are blaming the tool. In this instance, I'm leaning towards the latter.
Although Rust is an improvement in many ways, I actually think it is becoming more C++ like with every release. I think it has a good chance of over-taking C++'s complexity, even if it has a much better user story around build & package/module/library management.
As a guy who is writing Rust and found it a true value-add in his career, I agree with this and it's my #1 worry. Rust can already be very arcane to decipher sometimes, especially when you start getting errors from async libraries.
My entirely egotistical opinion is that the maintainers of the language have to take a very good and critical look of the current status quo and start systematically killing off any complexity they can.
Personally I don't want C++ 2.0. Tire people enough and they'll just move to another language again. I know I have, several times in my career, and will do so again if I have to.
I also really like Rust, and I see it as a good replacement of C++, except for one reason: the monoculture around it.
You are expected to use one specific compiler. And there's very little (apparent) interest in actually writing a spec, so that other people can actually try to implement their own compilers with a working borrow checker, compilers capable of compiling rustc without sacrificing soundness (so far the compilers I've seen are lacking borrow checker, for example).
My only remaining hope rests on the Ferrocene people.
So I can see why Rust is being used for user applications, but until that monoculture issue is fixed, I don't really see it replacing C, C++, much less SPARK, as a language for critical systems.
It is my sincere hope that having Rust in the Linux kernel, and in GCC, results in Rust getting an actual spec, so that we can finally know what is expected compiler behavior and what is a bug in rustc, other than "what the rustc from this specific repository does".
Like, for example, Rust 2018 edition is frozen (AFAIK), so that would be a good target for a baseline spec. Could be a more recent edition, even; it doesn't really matter as long as it's something.
> ...it has a much better user story around build & package/module/library management
Cargo sure does, but support for rust outside of cargo is much, much worse than equivalent support for C and C++. It doesn't matter for self-contained projects like simple Makefile ones, but at large scales, moving everything to cargo doesn't seem reasonable right now. Maybe eventually?
> C/C++ is undoubtedly one of the most popular programming languages for building database systems. Most well-known database systems, including MySQL, PostgreSQL, Oracle, and IBM Db2, are created in C/C++.
Considering C and C++ to be the same language is quite a stretch. They are fundamentally different.
Building a database is brave or stupid or both. Over the last 15 or 20 years I’ve tried lots of databases of all flavors and every time come back to Postgres.
What can’t it do.
And like Linux it’s written in C. Not that means much.
However, you didn't return to postgres:6.0 (first formal release in 1997 [1]), you returned to postgres:latest, which included the lessons learned from lots of other databases, thinking here of postgres:9.2 (in 2012) adding native JSON support making Postgres basically NoSQL with extra steps. Contrary to popular wit, reinventing the wheel is always beneficial, if it will not bring something new to the world, it will at least make you understand and appreciate wheels better.
It depends on your use case. For example, Postgres will hit limitations for large streams of time series data on the ingestion side, and the standard SQL language of Postgres may make it challenging to navigate a dataset by time: sampling the data, time intervals, time-series joins (ASOF join), and these kinds of things are not easy or possible to do on Postgres.
Why not combine Postgres for OLTP workloads alongside another database for fast analytics/time series, optimised to deal with high throughput ingestion and low latency queries?
NB: I am one of the co-founder of an open-source time series database (questdb)
Clustering it is still a pain, certainly if you want a proper autoscaling master-master setup. (Which may not be necessary for performance, but is still what you need for availability/resilience).
And it's still too easy to shoot yourself in the foot, by deadlocking, or using up all the server's resources with a query that looks very similar to one that was fine.
>>Over the last 15 or 20 years I’ve tried lots of databases of all flavors and every time come back to Postgres.
Almost the same here, have tried just about everything that comes along, and sooner or later I end up swapping out the database de jour and go right back to sql server in almost all use cases (for the type of projects I do).
I feel like db's are pretty much a solved problem, and can't imagine trying to build and market a brand new one these days. Almost as hard as trying to come up with a new operating system and convincing people to switch.
I wish good luck to anyone that tries, but talk about pushing a boulder up a mountain; definitely doesn't seem like the easy path to success.
Betting against Postgres all the time, since the .com age I have mostly used Oracle and SQL Server, and Postgrest only in a single projec that was alive during 4 years.
There was also Informix, SYBASE and DB2, but those hardly matter nowadays.
Seems like there are a couple of people with this mindset at every company. “Let’s write X”, “are you crazy, no one writes X! We can use Y!”, “But Y lacks Z”, “No! The thing you want Y to do is bad! You should not want Z! Do W instead - it is the correct way”
Stop larping as graybeards, and try to actually do something instead of endlessly bike shedding your cargo cult.
The more I read the "cons" in this article's C++ section the more I scratch my head. Code style is something that should be uniform and enforced. It's bikeshedding, but unless you're using a language with opinionated formatting (e.g. Go), it's absolutely a must have, and should be one of the first things done even at a startup.
This really looks like a case of not seasoned developers throwing crap at the wall and seeing what sticks. I doubt their Rust implementation will go any better.
Every time I read of memory leaks in C++ codebase, I get no idea why RAII didn't work in those cases. Even if the codebase was huge and complex. Circular references? Some special cases why one can't use RAII?
Forget unique pointer or smart pointers. People had been coding in C++ far before that without fearing memory leaks by following RAII principals.
Unless you are very deep in system / embedded, most of the code that constitutes your program is not your code -- it's various libraries, frameworks, code generated by utilities etc. Often times this is the source of both unsafe interfaces and misunderstanding of the functionality on the part of the developer writing the code.
Second to it is, probably, concurrency. RAII isn't going to save you here either.
Then there's also input processing where you may run into a situation that causes resources not being de-allocated because you never anticipated a particular shape of the input.
RAII works for very local and very well-defined things, it's not a good answer to dynamic situations or resources with complicated ownership.
RAII isn't a perfect safeguard against memory leaks. Rust doesn't provide 100% protection against them, either, especially when `unsafe` gets involved. It's better than C++, though, in this regard. There is no fool-proof way to avoid them, other than by never dynamically allocating memory.
Please do yourself a favor and don’t waste 5m of your life reading this article like I did.
It’s about a team of allegedly experienced C++ developers at a start-up that spent seven months building a project only to spend another two months rewriting it in Rust and then a few more months moving from async to Tokio. But those lost months have not been in vain, because they have 1600 stars on Github. They actually bragged about their Github stars.
It seems the Rust euphoria has reached such levels that people have stopped thinking critically both about the inexplicably bad business decisions and the near-zero technical content described in the article.
Author quoted C/C++, I immediately knew what conclusions I’d find. If on the other hand they had seasoned C++ devs (instead of C/C++), they might have had a different outcome.
That is the current issue with most C++ codebases nowadays, I only see modern C++ on conference slides, when I look into codebases even from ISO C++ members, it is always C++ full of C idioms no matter what.
I bet most candidates to C++ job offers end up discovering the hardly reality of existing code.
What is with the modern C++ community treating "C/C++" as a shibboleth to gatekeep over? I'm a seasoned C++ dev (using it before C++98 was available, kept up with trends) and I've never seen this before until the last year or so. I've never had a problem with it as I see my C++ skills being tranferrable to C.
"The STL library lacks support for some modern programming tools, for example, native co-routine support. As a result, developers must rely on many community projects, and most lack long-term support."
I couldn't agree more with this comment. As great as the community is, there's a lot of projects that are just not maintained. I wish this was different.
Seven months, 10+ team but let’s average that over time to 10. Let‘s take 20 days/month and we arrive at roughly 200LOC per day. C++, database server code. Interesting…
As a hobby software engineer who mostly writes ETL jobs in Python the biggest selling point of Rust is Cargo. I usually use a lot of .clone() in my code and most of my fields are Strings which would make a seasoned Rust/C++ laugh at the code. However, the performance of novice Rust beats 10+ years of experience Python by a factor of 10 (favouring Rust).
With Cargo I can build code that just runs. With Python it is always a gamble. Different arch? You need to install different packages to compile the C/C++/Fortran code if the library author did not care about WHL. Starting up an application always a gamble, do we have all the deps? Did we miss some?
And so on. With Rust + Cargo I have confidence that the executable runs. Yes, the compilation is an extra step, but I would have that trade every single time for extra safety and reliability.
Rust asyncio is still in its minimum-viable-product stage. My impression is that it will no long be considered MVP when it has structured concurrency. It would be great if authors posted honest insights about the limitations and work-arounds, if such exist.
I would like to know what the core authors of Materialize or InfluxDB-IOX have to say about using Rust for building a database. They've found the dead bodies, if there are any.
[+] [-] hdhrufjdi|3 years ago|reply
Finally somebody understands this.
[+] [-] fooker|3 years ago|reply
Rust is not difficult because of lifetimes, it just gets in the way of freely prototyping what you want.
This situation is slowly improving with the compiler getting better and better.
Then there is some annoying macro usage. Some Rust code looks truly alien.
[+] [-] lubesGordi|3 years ago|reply
[+] [-] victorvosk|3 years ago|reply
[+] [-] mzimbres|3 years ago|reply
* unreadable coding style: This is not a C++ problem. * memory leak: Memory leak is an old C++ problem, since C++11 there is no reason for not using smart pointers.
The only point that could be attributed to C++ is the segfaults perhaps, due to its lack of safety. But your other two points made me skeptical about Rust bringing you much benefit. I am specially concerned about throwing away months worth of code. Rewriting everything from scratch is what newbies love to do and will most likely get you in the same mess you were in. Try to learn with the error of others [1]. And btw, the problem is usually who writes the code and not which language is used.
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
[+] [-] ThePhysicist|3 years ago|reply
[+] [-] pharmakom|3 years ago|reply
[+] [-] spoiler|3 years ago|reply
The camp that thinks Rust is just unnecessary fuss because "you can do it all" in C++ already. They pride themselves with knowing C++ esoterica, and don't like that Rust lowers the entry barrier to writing similar software. They want an exclusive club. They also see ownership as a nuisance. They know you can be equally reckless in Rust too, but they don't like that Rust is so "in your face" about it, too.
The camp that is afraid Rust will marginalise C++ and hence push them towards undesirable (even if high paying) jobs.
There's the camp that's jaded by seeing too many fads come and go, and probably just burnt out at some point. So, they just want to work with what's there and be left alone. They don't want to learn something that they know (incorrectly or not isn't for me to judge here) will be dead in the water soon. And they'll have wasted their energy on it for naught. Or in short, they see it as an unwelcome distraction. This camp also includes "but it has no ISO specification for aviation/etc" too.
I think all these are wrong.
I don't think C++ will be marginalised, it just won't be the default choice for certain domains.
I don't think the extra tooling is a nuisance, if anything in my experience it unburdens the mind from non-domain concerns.
And I also don't think it's a fad, given how productive the language makes people feel, and the fact the Rust Foundation is very serious about the longevity of the project, and that it has many big-player backers.
There's also obviously others too; people come in about 8 billion flavours.
[+] [-] lelanthran|3 years ago|reply
Well, the syntax is alien and new, it doesn't do OO the way 9 out of 10 working developers expect it to, almost all C++ popular design patterns have to be rejected, many of the claims("fearless concurrency") are exaggerated and the Rust evangelists are really really toxic when referring to C++ or C, often simply claiming that fewer bugs is worth the tradeoff from switching to Rust.
I literally saw a comment on HN this past week complaining that OSes are not switching to Rust, almost completely ignoring the fact that any rewrite of a 3 decades old codebase is going to introduce more bugs than it is going to prevent, even if you have perfect memory safety (which you won't, in an OS).
In all honesty, Rust would have been adopted orders of magnitudes faster had Rust evangelists been welcoming, and not accused of being defensive or hostile.
I mean, look through this very page full of comments, and be honest, how many of the comments talking about C++ developers are welcoming to C++ developers?
[+] [-] mjburgess|3 years ago|reply
There isn't another live to live until 30 "again", and then be within the Rust culture.
Rust has, by analogy, stapled it's "Ninety-five Theses to the door" of C++ and those C++atholics are afraid their way of life is ending before they do.
[+] [-] margorczynski|3 years ago|reply
[+] [-] yagni_dev|3 years ago|reply
>It’s basically a compiler enforced set of C++ best practices
Its not, its a whole different programming paradigm where the compiler dictates how you write your software. You dont let your creative facilities to drive you or whats best for your domain - you just obey the language rules...
[+] [-] lr1970|3 years ago|reply
> But as more and more engineers joined us, some shortcomings of C++ came to bite us: unreadable coding style, memory leak, segmentation fault, and more.
One advantage of Rust of C/C++ that is underreported is the that Rust makes it easier to operate a team with diverse levels of experience/expertise. One or two senior engineers set up the tone, design and coding standards. Junior folks try to follow but if they screw up Rust offers more checks and guard rails limiting the blast radius. Many bugs simply do not make past the borrow checker and type system. This also helps when churn and attrition happens in the team. I witnessed quite a few horror stories when aspiring but not-yet competent C++ coders wrecked havoc in C++ code-base when seniors were busy with something else.
[+] [-] yagni_dev|3 years ago|reply
- Seasoned devs but they never heard of clang tidy/format - Memory leaks on a new db codebase where each component should have clear ownership of data or pass to the next pipeline/stage - you dont even need smart poirters here, just a half decent design. - I am not even going to mention sanitizers, probably rocket science for them
[+] [-] tw1984|3 years ago|reply
C++ and Rust are simply not competing on the same level. You don't need a complicated "enterprise" building farm/cluster to build your project, dependencies are managed by the guys who also write your compiler, there is a growing community that actually listen to your feedback and you don't need to wait 40 years to get networking support into the standard library. What C++ can offer? Languages like Rust, Golang and Zig all want their users to focus on their applications, while C++ just wants you to focus on C++. OO was a cool concept back in the 90s, but that was 30 years ago when you have 8MBytes of RAM if you are lucky - who wants to model every program using OO in 2023?
It has never been a better time to depreciate the C++ language and codebases written in C++. Museum is a much better place for C++.
[+] [-] flumpcakes|3 years ago|reply
Although Rust is an improvement in many ways, I actually think it is becoming more C++ like with every release. I think it has a good chance of over-taking C++'s complexity, even if it has a much better user story around build & package/module/library management.
[+] [-] pdimitar|3 years ago|reply
My entirely egotistical opinion is that the maintainers of the language have to take a very good and critical look of the current status quo and start systematically killing off any complexity they can.
Personally I don't want C++ 2.0. Tire people enough and they'll just move to another language again. I know I have, several times in my career, and will do so again if I have to.
[+] [-] quectophoton|3 years ago|reply
You are expected to use one specific compiler. And there's very little (apparent) interest in actually writing a spec, so that other people can actually try to implement their own compilers with a working borrow checker, compilers capable of compiling rustc without sacrificing soundness (so far the compilers I've seen are lacking borrow checker, for example).
My only remaining hope rests on the Ferrocene people.
So I can see why Rust is being used for user applications, but until that monoculture issue is fixed, I don't really see it replacing C, C++, much less SPARK, as a language for critical systems.
It is my sincere hope that having Rust in the Linux kernel, and in GCC, results in Rust getting an actual spec, so that we can finally know what is expected compiler behavior and what is a bug in rustc, other than "what the rustc from this specific repository does".
Like, for example, Rust 2018 edition is frozen (AFAIK), so that would be a good target for a baseline spec. Could be a more recent edition, even; it doesn't really matter as long as it's something.
[+] [-] humanrebar|3 years ago|reply
Cargo sure does, but support for rust outside of cargo is much, much worse than equivalent support for C and C++. It doesn't matter for self-contained projects like simple Makefile ones, but at large scales, moving everything to cargo doesn't seem reasonable right now. Maybe eventually?
[+] [-] Shorel|3 years ago|reply
C++ is also becoming better with every release, and C++20 is a huge improvement.
In all honesty, code written in C++20 feels just like code I have written in Python and/or JavaScript. And 20–40 times faster.
[+] [-] ahachete|3 years ago|reply
> C/C++ is undoubtedly one of the most popular programming languages for building database systems. Most well-known database systems, including MySQL, PostgreSQL, Oracle, and IBM Db2, are created in C/C++.
Considering C and C++ to be the same language is quite a stretch. They are fundamentally different.
[+] [-] andrewstuart|3 years ago|reply
What can’t it do.
And like Linux it’s written in C. Not that means much.
“Never bet against Postgres”.
[+] [-] ly3xqhl8g9|3 years ago|reply
[1] https://en.wikipedia.org/wiki/PostgreSQL#Release_history
[+] [-] nhourcard|3 years ago|reply
Why not combine Postgres for OLTP workloads alongside another database for fast analytics/time series, optimised to deal with high throughput ingestion and low latency queries?
NB: I am one of the co-founder of an open-source time series database (questdb)
[+] [-] lmm|3 years ago|reply
And it's still too easy to shoot yourself in the foot, by deadlocking, or using up all the server's resources with a query that looks very similar to one that was fine.
[+] [-] ejb999|3 years ago|reply
Almost the same here, have tried just about everything that comes along, and sooner or later I end up swapping out the database de jour and go right back to sql server in almost all use cases (for the type of projects I do).
I feel like db's are pretty much a solved problem, and can't imagine trying to build and market a brand new one these days. Almost as hard as trying to come up with a new operating system and convincing people to switch.
I wish good luck to anyone that tries, but talk about pushing a boulder up a mountain; definitely doesn't seem like the easy path to success.
[+] [-] pjmlp|3 years ago|reply
There was also Informix, SYBASE and DB2, but those hardly matter nowadays.
[+] [-] jen20|3 years ago|reply
Fail over without downtime or operator intervention.
[+] [-] buremba|3 years ago|reply
[+] [-] crabbone|3 years ago|reply
Async I/O.
[+] [-] newaccount2021|3 years ago|reply
[deleted]
[+] [-] Annatar|3 years ago|reply
[deleted]
[+] [-] dadarecit|3 years ago|reply
Stop larping as graybeards, and try to actually do something instead of endlessly bike shedding your cargo cult.
[+] [-] sidlls|3 years ago|reply
This really looks like a case of not seasoned developers throwing crap at the wall and seeing what sticks. I doubt their Rust implementation will go any better.
[+] [-] Shorel|3 years ago|reply
About Rust... I'm open-minded, let's see what happens.
[+] [-] habibur|3 years ago|reply
Forget unique pointer or smart pointers. People had been coding in C++ far before that without fearing memory leaks by following RAII principals.
[+] [-] crabbone|3 years ago|reply
Second to it is, probably, concurrency. RAII isn't going to save you here either.
Then there's also input processing where you may run into a situation that causes resources not being de-allocated because you never anticipated a particular shape of the input.
RAII works for very local and very well-defined things, it's not a good answer to dynamic situations or resources with complicated ownership.
[+] [-] sidlls|3 years ago|reply
[+] [-] blub|3 years ago|reply
It’s about a team of allegedly experienced C++ developers at a start-up that spent seven months building a project only to spend another two months rewriting it in Rust and then a few more months moving from async to Tokio. But those lost months have not been in vain, because they have 1600 stars on Github. They actually bragged about their Github stars.
It seems the Rust euphoria has reached such levels that people have stopped thinking critically both about the inexplicably bad business decisions and the near-zero technical content described in the article.
[+] [-] devinthenull|3 years ago|reply
[+] [-] smallstepforman|3 years ago|reply
[+] [-] pjmlp|3 years ago|reply
I bet most candidates to C++ job offers end up discovering the hardly reality of existing code.
[+] [-] epage|3 years ago|reply
[+] [-] foxbee|3 years ago|reply
I couldn't agree more with this comment. As great as the community is, there's a lot of projects that are just not maintained. I wish this was different.
[+] [-] heisenbit|3 years ago|reply
Seven months, 10+ team but let’s average that over time to 10. Let‘s take 20 days/month and we arrive at roughly 200LOC per day. C++, database server code. Interesting…
[+] [-] ReflectedImage|3 years ago|reply
[+] [-] StreamBright|3 years ago|reply
With Cargo I can build code that just runs. With Python it is always a gamble. Different arch? You need to install different packages to compile the C/C++/Fortran code if the library author did not care about WHL. Starting up an application always a gamble, do we have all the deps? Did we miss some?
And so on. With Rust + Cargo I have confidence that the executable runs. Yes, the compilation is an extra step, but I would have that trade every single time for extra safety and reliability.
[+] [-] bayesian_horse|3 years ago|reply
[+] [-] dilippkumar|3 years ago|reply
[+] [-] Dowwie|3 years ago|reply
I would like to know what the core authors of Materialize or InfluxDB-IOX have to say about using Rust for building a database. They've found the dead bodies, if there are any.