My comment would have been dismissive if I had not provided the rationale which I did and I still stand by my original point. Article provided no or whatsoever evidence why rewriting a vectorized database engine in Rust would solve any problems that could not have been solved with the original implementation language (C++ with Python front-facing API). It reads like a wasted effort providing no strong grounds for doing so.
> This isn't a technical article. This is an article about about an organization making a business decision based on broad goals, not specific tasks. They explained the technical and human requirements they wanted to optimize for and explained the other options they had available to them and why they chose the way they did. Then they explained their experience. This article is for managers, team leads, directors, to help them navigate similar business decisions.
Wow. A text building upon loose arguments around the AVX-512 instruction sets, memory layouts, memory footprint, garbage collection, asynchronous execution, parallel processing and benchmarking is not a technical article but a guide for businesses?
> First of all, Python is a garbage collected language, which means it can be extremely slow for writing anything high performance at scale.
False. Time spent on the frontend API (be it Python connector through JDBC or ODBC) is literally nonexistent to the time spent in the engine actually crunching the analytical workload. Python seems to work just fine for dozens of database engine companies around.
> In addition, it’s challenging to find developers with experience in both Python and C++.
Even if that had been true, which is highly unlikely given the popularity and age of both C++ and Python, finding seasoned Rust developers is easier? C++ and Python is a pretty much regular combination from my experience but even if Python is lacking, devs with C++ background will pick up Python in no time. Anyone basically will.
> we wanted to find some way to unify our code base
I failed to understand the reasons for that unification. However, now that the codebase will be unified, it will be interesting to see in what languages will the ecosystem be developed. Python? Rust?
> while achieving the performance predictability we needed.
If "code unification" had been the only requirement, for which I don't see any strong arguments, there's probably no better language than C or C++ at this point to fit such a task. Rust actually isn't that predictable when it comes to code generation.
> We knew that C++ was harder to scale and maintain high quality as you build a dev team
Again, there's no argument which would support that Rust will somehow excel C++ in this point? Anyway I am pretty much sure that the way of things are quite the opposite. Building a high-performing team in a C++ still at this point is a much better bet.
I could go further and further dissecting the article but I will stop here. Your impression is that they explained all their decisions thoroughly providing a ground for other business decision-makers and I have to disagree with that. Quality of the content is low, arguments are almost non-existent and very loose. All I see is a biased presentation. Or one may say low-quality Rust pitch.
Not to mention how absurd is to _rewrite_ the whole database engine in another language just because. Too bad that the engine isn't open-source so that we can actually see how it goes along the way.
> This isn't a technical article. This is an article about about an organization making a business decision based on broad goals, not specific tasks. They explained the technical and human requirements they wanted to optimize for and explained the other options they had available to them and why they chose the way they did. Then they explained their experience. This article is for managers, team leads, directors, to help them navigate similar business decisions.
Wow. A text building upon loose arguments around the AVX-512 instruction sets, memory layouts, memory footprint, garbage collection, asynchronous execution, parallel processing and benchmarking is not a technical article but a guide for businesses?
> First of all, Python is a garbage collected language, which means it can be extremely slow for writing anything high performance at scale.
False. Time spent on the frontend API (be it Python connector through JDBC or ODBC) is literally nonexistent to the time spent in the engine actually crunching the analytical workload. Python seems to work just fine for dozens of database engine companies around.
> In addition, it’s challenging to find developers with experience in both Python and C++.
Even if that had been true, which is highly unlikely given the popularity and age of both C++ and Python, finding seasoned Rust developers is easier? C++ and Python is a pretty much regular combination from my experience but even if Python is lacking, devs with C++ background will pick up Python in no time. Anyone basically will.
> we wanted to find some way to unify our code base
I failed to understand the reasons for that unification. However, now that the codebase will be unified, it will be interesting to see in what languages will the ecosystem be developed. Python? Rust?
> while achieving the performance predictability we needed.
If "code unification" had been the only requirement, for which I don't see any strong arguments, there's probably no better language than C or C++ at this point to fit such a task. Rust actually isn't that predictable when it comes to code generation.
> We knew that C++ was harder to scale and maintain high quality as you build a dev team
Again, there's no argument which would support that Rust will somehow excel C++ in this point? Anyway I am pretty much sure that the way of things are quite the opposite. Building a high-performing team in a C++ still at this point is a much better bet.
I could go further and further dissecting the article but I will stop here. Your impression is that they explained all their decisions thoroughly providing a ground for other business decision-makers and I have to disagree with that. Quality of the content is low, arguments are almost non-existent and very loose. All I see is a biased presentation. Or one may say low-quality Rust pitch.
Not to mention how absurd is to _rewrite_ the whole database engine in another language just because. Too bad that the engine isn't open-source so that we can actually see how it goes along the way.