5 ms·

In the end, having a 'more expressive' language isn't the key competitive advantage. At least, I can't recall when a company seems to have significantly outperf

In the end, having a 'more expressive' language isn't the key competitive advantage. At least, I can't recall when a company seems to have significantly outperformed a competitor because they used a 'fancier' programming language. Yes, of course, the blogposts by PaulG and how reddit started, but I'm not sure that reddit is succesful because they programmed it in lisp at first. Twitter specifically was designed in a time when RoR was really popular, but I'm not sure it worked _because_ it was built in RoR, and we all remember how twitter still exists simply by the grace that they managed to rewrite themselves away from the fail whale before competitors woke up to match their feature set. Now it's written in scala and, to me anyway, I see hundreds of developers and I'm not _at all_ impressed by their development momentum, even though it's written in scala. So, if that isn't the competitive advantage, why go for it in the first place? At least blue collar languages have much, much larger pools of competent programmers to select from, which is an objective, convenient upside any manager can understand.

Test0129 4y ago
> So, if that isn't the competitive advantage, why go for it in the first place? At least blue collar languages have much, much larger pools of competent programmers to select from, which is an objective, convenient upside any manager can understand. I think its like Haskell, Rust, Go, Erlang, etc. These languages are extremely useful in the microcosm of places where they excel. Rust when you absolutely need to insure memory safety, Go when you need near-C speeds but a simple to use concurrency system, Haskell for rigid typing, Erlang for high availability, etc. The problem is the dead average developer looks at these, and sees these high flying companies doing cool things in it, and then decides "wow I should write everything in this - it's the future!" Scala is the same way. It's not objectively better than a modern java in any way which might be taken as fighting words. But foregoing a lot of developer history you gain the power to reason about a very, very small subset of programming easier at the cost of speed, time, etc. For a company like a twitter with a very specific use case for this it made sense. Especially since at the time twitter switch from RoR to Scala, Python and it's concurrency platform didn't exist. However, I would speculate if they switched today they would've almost certainly gone to Python which would have been a much less "cool" switch and probably not even made the news cycle.
- whimsicalism 4y ago
  > Python which would have been a much less "cool" switch and probably not even made the news cycle. Very much doubt it re: Python. Performance, difficult to reason about, and lack of static typing all come to mind. I agree that modern Java is competitive now, but it probably wasn't when they picked Scala.
- rich_sasha 4y ago
  I think one issue is use cases that fall in-between. For example I use a lot of Python, but also need statically compiled, safe and solid language, with large ecosystem, with great Python interop. What do I choose? In practice the answer seems to be C++, maybe Rust. I'd happily use a "simpler" language like Go, Java or Nim, but something doesn't quite match the spec. I think, unsurprisingly, languages are designed around common use cases, but the uncommon ones are there too.
- xani_ 4y ago
  I dunno, Haskell, sure, but Rust is just all around better C++... memory safety is just plainly less bugs and that's always desirable
perceptronas 4y ago
In my experience, companies who chose Scala did enjoy a competitive advantage. Almost no bugs in production and predictable velocity. No more "not sure what this will break". In Scala projects I worked I almost never encountered any surprises except on boundaries (Scala<>Message broker) and etc. I saw projects (non-Scala) come to almost a complete stop from velocity perspective, because engineers were afraid to change old code. This resulted in many iterations and a lot of slow testing until changes were delivered. In my opinion, it can easily impact business side of things.
- xtracto 4y ago
  Around 8 years ago we chose Scala for some random microservice, because there was ONE guy in the team that loved Scala and wanted to do something with it. I said, sure go for it, it will be interesting to test the technology. After he implemented the microservice, it was rock solid for like 5 years. Said dev left 3 years later after implementing the service. Two years after he left, we needed to do something to the microservice... but nobody knew Scala in the team, so we have one or two "brave" guys who struggled to modify the Scala code. The same thing happened years later in another startup in Elixir. I arrived to this startup and there was some random microservice that someone had implemented in Elixir because it was "the new cool language that solved all scalability issues". Again, the person that implemented it had left years ago, so nobody knew anything about Elixir or the microservice. Because I've dabbed with Elixir for fun, I volunteered to work on it. In the end we decided to supersede it. I've learned to stay with boring technology. For me the sweet spot of productivity and team versatility is TypeScript and Javascript. Using these two technologies devs can do backend, frontend and mobile. The only thing missing is good bindings for Machine Learning.
  - b3morales 4y ago
    Two services each implemented by a single developer operated without problems for multiple business cycles and this is something to avoid? How does the effort of tweaking them in an unfamiliar language years later stack up against the effort they would have required otherwise?
awinter-py 4y ago
seriously. when they make me twitter cto for a day, my one change would be a public graph of build times (as a proxy for 'how long are backend devs waiting for builds') I suspect this would be deeply embarrassing + would lead to change in my (limited) experience, large scala codebases are not productive scala adoption was all like 12 years ago and driven by bored developers looking for a brain teaser / resume builder. same trend as companies like linkedin / uber, who have no reason to invent infra, contributing a bunch of half-baked java projects to apache
- whimsicalism 4y ago
  > a bunch of half-baked java projects to apache Like Kafka and Samza?
  - awinter-py 4y ago
    fair point there are some good ones

Test0129 4y ago

> So, if that isn't the competitive advantage, why go for it in the first place? At least blue collar languages have much, much larger pools of competent programmers to select from, which is an objective, convenient upside any manager can understand. I think its like Haskell, Rust, Go, Erlang, etc. These languages are extremely useful in the microcosm of places where they excel. Rust when you absolutely need to insure memory safety, Go when you need near-C speeds but a simple to use concurrency system, Haskell for rigid typing, Erlang for high availability, etc. The problem is the dead average developer looks at these, and sees these high flying companies doing cool things in it, and then decides "wow I should write everything in this - it's the future!" Scala is the same way. It's not objectively better than a modern java in any way which might be taken as fighting words. But foregoing a lot of developer history you gain the power to reason about a very, very small subset of programming easier at the cost of speed, time, etc. For a company like a twitter with a very specific use case for this it made sense. Especially since at the time twitter switch from RoR to Scala, Python and it's concurrency platform didn't exist. However, I would speculate if they switched today they would've almost certainly gone to Python which would have been a much less "cool" switch and probably not even made the news cycle.

whimsicalism 4y ago
> Python which would have been a much less "cool" switch and probably not even made the news cycle. Very much doubt it re: Python. Performance, difficult to reason about, and lack of static typing all come to mind. I agree that modern Java is competitive now, but it probably wasn't when they picked Scala.
rich_sasha 4y ago
I think one issue is use cases that fall in-between. For example I use a lot of Python, but also need statically compiled, safe and solid language, with large ecosystem, with great Python interop. What do I choose? In practice the answer seems to be C++, maybe Rust. I'd happily use a "simpler" language like Go, Java or Nim, but something doesn't quite match the spec. I think, unsurprisingly, languages are designed around common use cases, but the uncommon ones are there too.
xani_ 4y ago
I dunno, Haskell, sure, but Rust is just all around better C++... memory safety is just plainly less bugs and that's always desirable

perceptronas 4y ago

In my experience, companies who chose Scala did enjoy a competitive advantage. Almost no bugs in production and predictable velocity. No more "not sure what this will break". In Scala projects I worked I almost never encountered any surprises except on boundaries (Scala<>Message broker) and etc. I saw projects (non-Scala) come to almost a complete stop from velocity perspective, because engineers were afraid to change old code. This resulted in many iterations and a lot of slow testing until changes were delivered. In my opinion, it can easily impact business side of things.

xtracto 4y ago
Around 8 years ago we chose Scala for some random microservice, because there was ONE guy in the team that loved Scala and wanted to do something with it. I said, sure go for it, it will be interesting to test the technology. After he implemented the microservice, it was rock solid for like 5 years. Said dev left 3 years later after implementing the service. Two years after he left, we needed to do something to the microservice... but nobody knew Scala in the team, so we have one or two "brave" guys who struggled to modify the Scala code. The same thing happened years later in another startup in Elixir. I arrived to this startup and there was some random microservice that someone had implemented in Elixir because it was "the new cool language that solved all scalability issues". Again, the person that implemented it had left years ago, so nobody knew anything about Elixir or the microservice. Because I've dabbed with Elixir for fun, I volunteered to work on it. In the end we decided to supersede it. I've learned to stay with boring technology. For me the sweet spot of productivity and team versatility is TypeScript and Javascript. Using these two technologies devs can do backend, frontend and mobile. The only thing missing is good bindings for Machine Learning.
- b3morales 4y ago
  Two services each implemented by a single developer operated without problems for multiple business cycles and this is something to avoid? How does the effort of tweaking them in an unfamiliar language years later stack up against the effort they would have required otherwise?

awinter-py 4y ago

seriously. when they make me twitter cto for a day, my one change would be a public graph of build times (as a proxy for 'how long are backend devs waiting for builds') I suspect this would be deeply embarrassing + would lead to change in my (limited) experience, large scala codebases are not productive scala adoption was all like 12 years ago and driven by bored developers looking for a brain teaser / resume builder. same trend as companies like linkedin / uber, who have no reason to invent infra, contributing a bunch of half-baked java projects to apache

whimsicalism 4y ago
> a bunch of half-baked java projects to apache Like Kafka and Samza?
- awinter-py 4y ago
  fair point there are some good ones