The groups I worked with made different determinations than your team, but if you guys love it, enjoy. Seriously, if you find a technology your whole team loves, you are KILLING it.
Both companies I worked with have since dropped Scala (after literally hundreds of thousands of dollars spent on the attempts) entirely internally due to maintenance and talent acquisition issues.
In my experience very little Scala code uses DSLs. Learning Scala isn't that tricky for anyone who knows Java, which is a pretty big pool.
Edit: It was two years ago so other than Lift and some SQL DSL I don't recall which libraries we were using. I do recall wishing I hadn't taken that job.
I once read an article about how Java programmers can hold a conversation on the topic of upsides and downsides of multiple dependency injection containers while C# programmers only have one available and have nothing to say on this topic. That article concluded that having one "good enough" solution can often be better than having multiple slightly different and incomplete ones, even if each has its own strenghts, and I'd say the same is true when it comes to the C# LINQ vs. Scala SQL DSLs.
The Scala equivalent is called Slick, and it's the only SQL DSL that approaching anything near widespread use. I fail to see how incomplete projects on GitHub which happen to be written in Scala are relevent to this discussion.
You are probably referring to "LINQ to SQL" which is different and significantly less popular technology than LINQ.
I too suffered a bit from DSL hell, especially some of the more extreme examples like the library "dispatch" where you need a "element lookup table" to figure out which squiggly line to use. But once you have a stable set of dependencies the initial DSL influx subsides and you start to work with a fairly manageable subset of them on a day to day basis.
Hundreds of thousands of dollars is on the order of, what, 1 engineer-year?
For example, Lisp has a simple syntax, but most people would consider infix math notation easier, although more complex.
The main downside of Groovy is: it's not as fast. And of course the programming paradigm is less revolutionary and more pragmatic, though that could also be a big upside.
In fact Kotlin looks mostly like Java with some additions to make everyone's lives easier (closures, extension methods, data classes).
Every language takes influences from others, if that's what you meant. Scala is influenced by Java, C# and Haskell, in that order. Kotlin is influenced by Scala and Java, etc.
The "superset" and "Lisp, Haskell and Javascript in the same compiler" comments are unhinged from the reality of any language I recognise.
For me and I think most other Scala devs Scala is a statically typed FP-OO language. So Haskell doesn't do it justice because Haskells insistence on purity makes it impractical for me in getting stuff done. And Java doesn't do it justice because Java is held back by its history. "Superset of" makes it sounds like a weakness and overwrought. In my experience it offers a sweat spot of the best features of static FP and OO.
So what about your mention of Lisp and Javascript? Unless you're deep in some framework you don't need to know about the support for macros and structural typing. I've ignored those two so far because I haven't needed them (yet?). And I haven't felt they were in my way.
So where you say "a superset of Haskell, Lisp, Javascript and Java" I say "the sweet spot of the best features of static FP and OO for the real world. Leveraging the JVM ecosystem".
I know this will sound snarky, but I have to ask: have you tried haskell before? I only ever hear that line of reasoning from people who have never used it (and I was once one of them, using that very same reasoning to choose a multi-paradigm language). We bailed on scala for haskell precisely because it is pure and has a better type system.
You can't say that Erik Meijer doesn't know Haskell. :-)
From the sound of it this is his first job in the "real world"? If that's the case, perhaps he just hasn't seen patterns of applying his current functional knowledge in a way thats better than the best practices from the imperative realm.
How do we know after a few years he won't switch (provided he was a fundamentalist functional programmer) back to saying "now that I have a better understanding of 'The real world' I can see patterns applied with the functional paradigm are better than the best practices I've been using from the imperative paradigm."?
I believe this is the reason to keep an ear open for authority figures, but not to take everything they say empirically, especially when it's in contradiction with a position they've held much longer.
Apologies for the rambling, I was just typing out what came to mind.
Nor is that even, I think, what I think Meijer favors. Meijir's position, from what I've seen from him in various contexts, seems to be that there are cases in real world software where the most clear expression of intent uses imperative constructs, and its better to use them -- but understand and contain their dangers -- in those cases rather than trying to avoid out of devotion to purity.
> From the sound of it this is his first job in the "real world"?
Well, if you don't count the 13 or so years at Microsoft as being "real world".I don't think he ever was a fundamentalist anything.
> I believe this is the reason to keep an ear open for authority figures, but not to take everything they say empirically
"Empirically"? Are you meaning something like "uncritically"? Because "empirically" doesn't have any meaning that makes sense in this sentence.
That's true. But I can say that he is quite happy to tailor his message to his audience, If you listen to what he is saying, he is making the argument for haskell. He is just wording it for the PHP crowd. Haskell does allow side effects, which is entirely the point. But the "unwashed masses" as it were are under the misconception that it does not. So he has to take the "side effects are awesome" sales pitch, and kinda tosses haskell under the bus in the process. Unfortunate, and ironic given that haskell programmers genuinely feel that side effects are awesome, but what can you do?
If you think scala is a superset of those, then you either really don't know scala at all, or you have an incredibly low opinion of all the languages you listed.