6 ms·

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 thi

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?
  - dustingetz 4y ago
    it moves money to the wrong people
- dkarl 4y ago
  Sorry, but those two stories sound like dream outcomes. A more typical outcome is a service that is never quite right, needs bug fixes every release, requires a code change for every minor change in the system around it, and basically serves as a jobs program for engineers. Somebody nails a service so well that it does its job quietly for years with no further work? I don't care your code is written in Aramaic and causes other programmers' heads to bubble and explode, please stay on my team and give me another service just like it.
kosherhurricane 4y ago
When Scala was "hot", it was embraced by very good programmers. The complexity of the language sort of demanded it. Thus, the stuff they wrote were well written. After they leave, nobody can improve it or change it. (See sibling reply). It's the people, not the language, that produces good software.
- xani_ 4y ago
  > When Scala was "hot", it was embraced by very good programmers. The complexity of the language sort of demanded it. And reverse of that worked for Perl, then PHP, then JS (and arguably also Python/Ruby)

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?
- dustingetz 4y ago
  it moves money to the wrong people
dkarl 4y ago
Sorry, but those two stories sound like dream outcomes. A more typical outcome is a service that is never quite right, needs bug fixes every release, requires a code change for every minor change in the system around it, and basically serves as a jobs program for engineers. Somebody nails a service so well that it does its job quietly for years with no further work? I don't care your code is written in Aramaic and causes other programmers' heads to bubble and explode, please stay on my team and give me another service just like it.

kosherhurricane 4y ago

When Scala was "hot", it was embraced by very good programmers. The complexity of the language sort of demanded it. Thus, the stuff they wrote were well written. After they leave, nobody can improve it or change it. (See sibling reply). It's the people, not the language, that produces good software.

xani_ 4y ago
> When Scala was "hot", it was embraced by very good programmers. The complexity of the language sort of demanded it. And reverse of that worked for Perl, then PHP, then JS (and arguably also Python/Ruby)