4 ms·

Maybe if you're Dropbox, Rust is an option, but Rust is much, much more complicated than Python and not nearly as approachable - especially for beginners.

ajxs 7y ago
I'd argue that how complicated a language is shouldn't be a factor for a company at that scale. If it's the right tool for the job, and I'm not arguing that it is, then they have the ability to hire engineers capable of using it.
- oscargrouch 7y ago
  I dont know the experience of others with this, but in reality is not that easy to have people with enough brain power or compromise for languages like C++ and Rust. Sure theres "enough for the world", if you sum everybody, but i bet that even a company of the size of Dropbox would have a hard time hiring everyone they need if the complexity of the language is the same as Rust or C++. For instance, if you read the Go manifesto to why the language was created, you can read between the lines that C++ getting in the way where enginners were fighting hard to deal with language complexity. So the same way as Java before them, they created a language for the "average programmer". And you can see how the language is very pragmatic and how they fight to no put more complexity on the language. By the way, i know its a personal opinion, but i think Rust will not be a great fit for the cloud backend exactlya because of this kind of thing. It will be hard to create codebase as complex as the ones in Java, because there will be much less man-hours available. Maybe if generations are getting smarter, IDK, but needing to rely on a big head-count of C++ or Rust enginners for any company, i bet they will have a hard time to fill all the positions they need. Theres much more C++ enginners than Rust right now, and companies have a hard time hiring them (and i bet that for Rust it will be no different giving its complexity).
  - speedplane 7y ago
    > if you read the Go manifesto to why the language was created, you can read between the lines that C++ getting in the way where enginners were fighting hard to deal with language complexity. My understanding was that the push from C++ to Go was largely motivated by long C++ compile/linking times. Go is designed to compile large code-bases much faster than C++. I've experienced this myself, it's pretty frustrating to wait 2-5 minutes for a C++ app to compile / link just so you can debug it for 30 seconds and start all over again.
    - oscargrouch 7y ago
      But this is a by-product of their initial motivation. I mean, how could they know their link times would be that much better? I know that Pike et al. worked on compilers for Inferno, and the Ken´s C compiler used some tricks to know beforehand they could make it compile and link very fast, but they couldnt know if the language they were designing would be as fast (to compile) as C or Limbo. They could say confidently: "we could do better", but they would need more pragmatic motives, even to convince Google to support that effort. And i bet Google was struggling with C++ enginnering, specially within the newcomers on the team. I think, both things are true, but developer ergonomics play a very important factor into the why of a language and where it fits in the scheme of things.
    - hermitdev 7y ago
      > I've experienced this myself, it's pretty frustrating to wait 2-5 minutes for a C++ app to compile / link just so you can debug it for 30 seconds and start all over again. That's quaint. When I first started working in C++ professionally, we were at +16 hours for a clean build and link of just one of our systems (circa 2004). Over the years, reduced the amount of code (without sacrificing functionality), shared common code (object model) between client and server (went from about 2M LOC to about 250k LOC), reduced the number of external dependencies, introduced precompiled headers on both windows and Linux, and a clean build was down to about 30 minutes. An incremental build and link could be less than 30 seconds, depending on the scope of the change. But, yeah, C++ leaves a lot to be desired in terms of edit, build, test, repeat cycles.
- vonseel 7y ago
  shouldn't be a factor for a company *at that scale* Exactly.
- speedplane 7y ago
  > I'd argue that how complicated a language is shouldn't be a factor for a company at that scale. I'd agree with you re Dropbox, a relatively "enlightened" modern software company. But they are the exception, not the rule. Most companies, big and small hire the cheapest developers they can find. I'm not talking about silicon valley tech companies, but think e-commerce and corporate sites (Nordstrom, General Motors) and old school companies (e.g., Goldman Sachs, power utilities). These companies don't care about the "right tool for the job", they care about the right people for the job. If the "people" are adept at antiquated technologies, then they'll still pass muster.
- hermitdev 7y ago
  But why rewrite a 4M LOC system that works in a new language, just because of a new shiny? How do you justify that from a business standpoint? Especially when your current engineering staff are already experts in the currently used technology, but likely novices or mediocre in Rust? Do you freeze new features during the rewrite? Do you develop new features in parallel? Rewriting, just because, Rust, is a waste. Sure, you can hire new talent that knows Rust, but how long for them to pick up the relevant domain knowledge? How long for the existing talent that has the domain knowledge to become equivalently proficient in their current tech stack? Plus, with a rewrite, you risk falling ill to second system syndrome. Economically and from a practical engineering standpoint, it seems to me that Dropbox is taking a very pragmatic approach. Gradually make working with the exist code easier rather than throwing the baby out with the bath water. I'm not hating on Rust, but this fervor to rewrite everything in Rust is obnoxious and often short sighted, in my opinion. If you're talking brand new, green field development, by all means, it should be considered.
m0zg 7y ago
I'm fully in support of the beginners near coming anywhere near my data storage and synchronization.
0815test 7y ago
How so? Rust is much, much less complicated than C++, a language that's routinely taught to beginners. Python is far more complex than either of those, especially once you account for the incidental complexity in whatever "packages" you're interfacing with - Rust simplifies a lot of that stuff without giving up on performance.

ajxs 7y ago

I'd argue that how complicated a language is shouldn't be a factor for a company at that scale. If it's the right tool for the job, and I'm not arguing that it is, then they have the ability to hire engineers capable of using it.

oscargrouch 7y ago
I dont know the experience of others with this, but in reality is not that easy to have people with enough brain power or compromise for languages like C++ and Rust. Sure theres "enough for the world", if you sum everybody, but i bet that even a company of the size of Dropbox would have a hard time hiring everyone they need if the complexity of the language is the same as Rust or C++. For instance, if you read the Go manifesto to why the language was created, you can read between the lines that C++ getting in the way where enginners were fighting hard to deal with language complexity. So the same way as Java before them, they created a language for the "average programmer". And you can see how the language is very pragmatic and how they fight to no put more complexity on the language. By the way, i know its a personal opinion, but i think Rust will not be a great fit for the cloud backend exactlya because of this kind of thing. It will be hard to create codebase as complex as the ones in Java, because there will be much less man-hours available. Maybe if generations are getting smarter, IDK, but needing to rely on a big head-count of C++ or Rust enginners for any company, i bet they will have a hard time to fill all the positions they need. Theres much more C++ enginners than Rust right now, and companies have a hard time hiring them (and i bet that for Rust it will be no different giving its complexity).
- speedplane 7y ago
  > if you read the Go manifesto to why the language was created, you can read between the lines that C++ getting in the way where enginners were fighting hard to deal with language complexity. My understanding was that the push from C++ to Go was largely motivated by long C++ compile/linking times. Go is designed to compile large code-bases much faster than C++. I've experienced this myself, it's pretty frustrating to wait 2-5 minutes for a C++ app to compile / link just so you can debug it for 30 seconds and start all over again.
  - oscargrouch 7y ago
    But this is a by-product of their initial motivation. I mean, how could they know their link times would be that much better? I know that Pike et al. worked on compilers for Inferno, and the Ken´s C compiler used some tricks to know beforehand they could make it compile and link very fast, but they couldnt know if the language they were designing would be as fast (to compile) as C or Limbo. They could say confidently: "we could do better", but they would need more pragmatic motives, even to convince Google to support that effort. And i bet Google was struggling with C++ enginnering, specially within the newcomers on the team. I think, both things are true, but developer ergonomics play a very important factor into the why of a language and where it fits in the scheme of things.
  - hermitdev 7y ago
    > I've experienced this myself, it's pretty frustrating to wait 2-5 minutes for a C++ app to compile / link just so you can debug it for 30 seconds and start all over again. That's quaint. When I first started working in C++ professionally, we were at +16 hours for a clean build and link of just one of our systems (circa 2004). Over the years, reduced the amount of code (without sacrificing functionality), shared common code (object model) between client and server (went from about 2M LOC to about 250k LOC), reduced the number of external dependencies, introduced precompiled headers on both windows and Linux, and a clean build was down to about 30 minutes. An incremental build and link could be less than 30 seconds, depending on the scope of the change. But, yeah, C++ leaves a lot to be desired in terms of edit, build, test, repeat cycles.
vonseel 7y ago
shouldn't be a factor for a company *at that scale* Exactly.
speedplane 7y ago
> I'd argue that how complicated a language is shouldn't be a factor for a company at that scale. I'd agree with you re Dropbox, a relatively "enlightened" modern software company. But they are the exception, not the rule. Most companies, big and small hire the cheapest developers they can find. I'm not talking about silicon valley tech companies, but think e-commerce and corporate sites (Nordstrom, General Motors) and old school companies (e.g., Goldman Sachs, power utilities). These companies don't care about the "right tool for the job", they care about the right people for the job. If the "people" are adept at antiquated technologies, then they'll still pass muster.
hermitdev 7y ago
But why rewrite a 4M LOC system that works in a new language, just because of a new shiny? How do you justify that from a business standpoint? Especially when your current engineering staff are already experts in the currently used technology, but likely novices or mediocre in Rust? Do you freeze new features during the rewrite? Do you develop new features in parallel? Rewriting, just because, Rust, is a waste. Sure, you can hire new talent that knows Rust, but how long for them to pick up the relevant domain knowledge? How long for the existing talent that has the domain knowledge to become equivalently proficient in their current tech stack? Plus, with a rewrite, you risk falling ill to second system syndrome. Economically and from a practical engineering standpoint, it seems to me that Dropbox is taking a very pragmatic approach. Gradually make working with the exist code easier rather than throwing the baby out with the bath water. I'm not hating on Rust, but this fervor to rewrite everything in Rust is obnoxious and often short sighted, in my opinion. If you're talking brand new, green field development, by all means, it should be considered.

m0zg 7y ago

I'm fully in support of the beginners near coming anywhere near my data storage and synchronization.

0815test 7y ago

How so? Rust is much, much less complicated than C++, a language that's routinely taught to beginners. Python is far more complex than either of those, especially once you account for the incidental complexity in whatever "packages" you're interfacing with - Rust simplifies a lot of that stuff without giving up on performance.