4 ms·

I care. Programming languages give us different frameworks and guardrails to express computational tasks similarly to how written and spoken languages give us

I care. Programming languages give us different frameworks and guardrails to express computational tasks similarly to how written and spoken languages give us a different set of concepts with which to express ideas. New languages mean a potentially different way of thinking about a problem. Some ideas which are difficult to express in one language are trivial in another. Discovering these differences is one of the joys of language learning. Language learning requires practice, and rewriting a known work (or translating it you might say) is a great way to deepen your understanding and test which ideas are easier or harder.

menaerus 4y ago
You seem to come from a point as if I don't care about the intricate knowledge of programming languages or as if I don't care about learning how different languages manage to solve the same problem but from a different angle or with a different approach. I really do. What I don't see here in this article is none of that with some very loose arguments around picking Rust vs some other system programming language. Very typical of such type of articles regardless whether they're coming from Rust, C++, Go etc. "I rewrote XYZ in Rust" or "I rewrote XYZ in C++" or "I rewrote XYZ in Go" is basically like saying "I rewrote XYZ in a Turing-complete language". Go figure. How relevant that really is? Any problem can be solved in any programming language but the important distinction which is very often left unspoken and not demonstrated is what is it that you managed to improve? Is it that you managed to improve the code quality, shorten the development cycle, decreased the number of bugs or was it that you managed to improve the performance? In absence of ability to demonstrate the pros and cons of the approach one took, I will keep finding such articles biased with the lack of real content and therefore annoying. Some will call it programming language circle*erking.
- TehCorwiz 4y ago
  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. You original comment was purely dismissive of the entire concept of advocating for and sharing the experience of different languages. You also seem very focused on the technicality that "You can program anything in any language" which while true, you CAN write a Facebook clone in [brainfuck](https://en.wikipedia.org/wiki/Brainfuck https://en.wikipedia.org/wiki/Brainfuck), you wouldn't want to for many reasons. For real(tm) languages the decision is harder.
  - menaerus 4y ago
    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.

menaerus 4y ago

You seem to come from a point as if I don't care about the intricate knowledge of programming languages or as if I don't care about learning how different languages manage to solve the same problem but from a different angle or with a different approach. I really do. What I don't see here in this article is none of that with some very loose arguments around picking Rust vs some other system programming language. Very typical of such type of articles regardless whether they're coming from Rust, C++, Go etc. "I rewrote XYZ in Rust" or "I rewrote XYZ in C++" or "I rewrote XYZ in Go" is basically like saying "I rewrote XYZ in a Turing-complete language". Go figure. How relevant that really is? Any problem can be solved in any programming language but the important distinction which is very often left unspoken and not demonstrated is what is it that you managed to improve? Is it that you managed to improve the code quality, shorten the development cycle, decreased the number of bugs or was it that you managed to improve the performance? In absence of ability to demonstrate the pros and cons of the approach one took, I will keep finding such articles biased with the lack of real content and therefore annoying. Some will call it programming language circle*erking.

TehCorwiz 4y ago
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. You original comment was purely dismissive of the entire concept of advocating for and sharing the experience of different languages. You also seem very focused on the technicality that "You can program anything in any language" which while true, you CAN write a Facebook clone in [brainfuck](https://en.wikipedia.org/wiki/Brainfuck https://en.wikipedia.org/wiki/Brainfuck), you wouldn't want to for many reasons. For real(tm) languages the decision is harder.
- menaerus 4y ago
  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.