I had a startup that went all in on scala. By the time we realized we chose the wrong language it was too late. Complexity is the primary issue with the scala language... when the whole goal is to have a scalable language which in itself is diametrically opposed to simplicity, your language is dead on arrival. After using Scala, Go seemed like a dream come true. We really loved the integration of OO and FP, really mi…
> integration of OO and FP
OO and FP are paradigms. You can use any of them, or both of them, in any language.
I had a startup that went all in on scala. By the time we realized we chose the wrong language it was too late. Complexity is the primary issue with the scala language... when the whole goal is to have a scalable language which in itself is diametrically opposed to simplicity, your language is dead on arrival. After using Scala, Go seemed like a dream come true. We really loved the integration of OO and FP, really mi…
There is a tendency I observed in engineers to not want to appear dumb. This is a recipe for disaster when coupled with a deep language like Scala, because nobody wants to solve problems the simple way, and Scala gives a tremendous amount of rope. That's why I think it's only a suitable choice for very experienced or disciplined teams, with a strong consensus on style or any DSLs. I can see average enterprise shops l…
> to not want to appear dumb
Few production incidents are enough to change this mentality. I'd rather write more verbose but "obvious" code than "clever one liners". I feel sorry for anyone who has to understand someone's DSL on the fly when there's an outage and your business is burning through X$ per minute of downtime.
(On the other hand, you probably want to structure your production changes in the way that they are easy to roll back without understanding everything, but that's other conversation. Either way, the thought that someone may want to chase me after work because my code broke and they can't understand it is enough for me to stop being clever).
I had a startup that went all in on scala. By the time we realized we chose the wrong language it was too late. Complexity is the primary issue with the scala language... when the whole goal is to have a scalable language which in itself is diametrically opposed to simplicity, your language is dead on arrival. After using Scala, Go seemed like a dream come true. We really loved the integration of OO and FP, really mi…
> integration of OO and FP OO and FP are paradigms. You can use any of them, or both of them, in any language.
You can use FP in Java, or OO in Haskell. That doesn't mean that they're equally usable paradigms.
I believe Scala had the goal of offering a high level of usability for both FP and OO. It failed despite an admirable effort, because of an incredible amount of language complexity.
> Publishing open source project to Maven is way more difficult than most language ecosystems. Maybe this is a feature, not a bug. I won't call out the language/repo, but I was able to gain admin access for a library my company published with just an email from my company's domain. There are major security issues with "easy." There are also quality issues. You're more likely to publish something if you think it has v…
Would have to disagree here. Just raising the bar higher for publishing at all doesn't increase quality of libraries available. Consider how open source in general really became much more the norm after Github made it trivially easy to publish and collaborate on code.
In contrast I think that going all in on Java scares away people who like to experiment.
Be honest and give a short list of experimental approaches that you wanted to do and couldn't be done on Java. What did you want to do and couldn't? And, let's ask Rich Hickey. What language was it he used to experiment with a new s-expression language? Why wasn't RH scared away? You want the brutal honest answer? Because he is smart and can grok the complexity of the Java in toto. What sort of experiments can you no…
> I used to do the switch the superclass at loadtime to experiment with adaptable programs.
This probably falls in undefined behavior territory. What kind of errors did you get when something went wrong?
I had a startup that went all in on scala. By the time we realized we chose the wrong language it was too late. Complexity is the primary issue with the scala language... when the whole goal is to have a scalable language which in itself is diametrically opposed to simplicity, your language is dead on arrival. After using Scala, Go seemed like a dream come true. We really loved the integration of OO and FP, really mi…
I only witnessed from the outside, but saw a similar story play out. A client had bet on Scala for a new platform and made it about 6 months in before throwing in the towel and rewriting the whole thing in in Java. It's too hard to recruit and the tooling isn't mature enough.
I thought it was understood that choosing a less popular language meant hiring people for fundamentals and then letting them ramp on on your language. Did the client choose Scala thinking they would just hire "Scala people"?
I wouldn't blame the language, I'd blame the people who chose Scala. The impression I always had was that Scala was a research project into how various programming language features could live together and interact, hence their everything and the kitchen sink approach. From an academic point of view I think Scala was a huge success. That people chose to use Scala in production speaks more to how badly people hate Jav…
Indeed, Scala looks like a language research project, more like Perl and Haskell. You definitely can use all of them in production and benefit from that, but you need both mastery and restraint in using such a language. Golang is the opposite: it takes the ideas from 1980s with some early 1990s (Pascal, Modula-2, Oberon; CSP; garbage collection) and executes them to near perfection. It even ignores some of the obviou…
My issue with Golang is that I find my ability to write code to just takes so much longer (and often with more lines) than other contemporary languages like Swift. The rigidity is a double-edged sword.. it removes potential issues that could cause you to trip on yourself, but at the cost of productivity.
I had a startup that went all in on scala. By the time we realized we chose the wrong language it was too late. Complexity is the primary issue with the scala language... when the whole goal is to have a scalable language which in itself is diametrically opposed to simplicity, your language is dead on arrival. After using Scala, Go seemed like a dream come true. We really loved the integration of OO and FP, really mi…
I may have a contrarian opinion: a new language, beyond certain level, does not increase productivity tangibly for a large enough team. Specifically, Scala does not necessarily offer more productivity than Java. It is a pleasure to write program in a language with more powerful features, for sure. It's just that bottlenecks of project are usually not language features, but core algorithms, system designs, meticulous testing, conflicting requirements that demand careful trade-offs, availability of robust libraries and frameworks, maintainability of the most complex part of the system, and availability of qualified engineers. Few of such bottlenecks can be removed by switching to a language like Scala.
In my experience, it's easier for many developers to blame the tools and language rather than admit the dumpster fire of a codebase was entirely their doing and their responsibility.
fentanyl is 50-100x more potent than morphine. Its still the user's fault for overdosing, but overdosing is easier to do with fent. Pepsi is more potent (sugar) than an apple, easier to get fat. Still the consumer's fault. My point is the choice of language may require more energy to enforce better code practices. Scala is so feature packed that it makes it easy for a developer to... overdose.
Counterpoint. A focus on type-safety makes Scala less likely to suffer from too-clever-by-half solutions. Sometimes a group of developers will be smart enough to create an overly-complicated solution that still type checks and works (see the original Slick library...) but for most normal teams, the compiler is a guard against overly ambitious type magic.
On the other hand, I've seen my fair share of too-clever uses of runtime reflection (Java) or weird metaprogramming (Python/JS) techniques, except they were not only too-clever but actually just didn't work and would fail miserably at inopportune times.
Some of the worst and unmaintainable code I've ever seen was written in Python & Java. While some of the cleanest codebases were written in Scala and Javascript. The problem is not the language, but the team & overall approach to development (rushing to deploy bad code because your manager said so; lack of code review). Tooling can be better, but it was massively improved over last 2 years
I've written a ton of code in a bunch of different languages, and you're exactly on point here.
It's got everything to do with discipline and time spent on creating and keeping a codebase simple and well factored. If you don't have a team doing that, you're going to have problems.
Scala is a sharp tool, in the wrong hands you're gonna slice your toes off. In the right hands, you can create simple, elegant solutions to challenging problems.