5 ms·
As the Scala tech lead, I'm glad to learn we've finally adopted "almost every new PL concept!" I guess by now everyone will recognize your username and adjust f
by adriaanm 11y ago
As the Scala tech lead, I'm glad to learn we've finally adopted "almost every new PL concept!" I guess by now everyone will recognize your username and adjust for bias accordingly, but still, how about sticking to the facts?
- rattray 11y agoAs someone who doesn't follow such things (eg; I don't recognize the "pron" or "adriaanm" usernames, and haven't used Scala or any other JVM language), I found your comment to be a turn-off towards using Scala. That's not the kind of mature tone I'd look for from the tech lead of an open-source language. That said, it is good to know that "pron" was incorrect/exaggerating when they said Scala adopts a lot of PL concepts; thanks for setting the record straight (though I'm still just not sure where Scala stands on that after reading this).
- virtualwhys 11y agoFYI, pron's the author of a would be competing project to Scala's Akka (i.e. competing for share of distributed computing market on the JVM), and takes every opportunity to danger-danger-dragons-be-there on Scala related threads/comments. Saying that, there is always some truth in what pron brings to the table, it's sort of a higher kinded trolling ;-) As for Scala and PL concepts, sure, plenty on offer if that's of interest, but not at all a requirement in using the language. A great example of a highly successful project based on the non-FP-centric aspects of Scala is Spark. See their high performance computing style guide [1], no monad transformers there... [1] https://github.com/databricks/scala-style-guide https://github.com/databricks/scala-style-guide
- ninjakeyboard 11y agoWhat is a pron? That's like a shrimp?
- saryant 11y agopron is the author of the GGGP post to the one you replied to.
- pron 11y agoFYI, I had taken "every opportunity to danger-danger-dragons-be-there" Scala — on record — years before I even dreamed of the database company that would one day have an open-source project which would end up competing with Akka (I'm talking 2009/10, while Quasar was first conceived in mid 2013). It was after leading an attempt to adopt Scala at a large organization, which failed because of what I saw as Scala's bait-and-switch marketing: it presented itself as "a better Java" while it really was (and is) a strict-Haskell-with-OOP-and-macros-and-more. We needed a car and got a helicopter. While some would consider a helicopter superior to a car, I think everyone would agree it imposes a completely different set of tradeoffs. So yeah, for a good while I was telling people, listen, it's a helicopter, so make sure a helicopter is what you want (the Scala community’s response was, what is this FUD? Can’t you see it's got wheels?! You can drive it on the ground if you want; you don’t have to take off! To which I responded, but you still can’t take it to a car garage for maintenance, to which their response was, you’re a stupid biased troll!). I don't remember when was the last time I participated in a Scala thread, but that community doesn’t forget. So if I'm damned if I don't, I might as well do: Spark is a good example for a project that would have been better off using Kotlin. They wouldn't have missed any Scala features, would have had better build times, better IDE support and better Java interop (of course, Kotlin wasn’t mature enough to even be considered when that project started). In fact, using Kotlin would have saved them writing 95% of that style-guide[1], which reads like instructions on how to drive a helicopter on the ground without accidentally taking off (Perhaps ironically, that style guide drew derision from the Scala community, who said, you're in a helicopter for fuck's sake! Why won't you take off?!) [1]: No implicits, no multiple argument lists, no Try, no infix notation, no non-math operators, no recursion, no being-fancy-with-monads, no Scala concurrent collections, no Scala collections, no for loops. They don't mention dynamics and structural types, but I think it goes without saying that they're off-limits, too.
- virtualwhys 11y agoInteresting analogy, incredible how Spark drives the Scala helicopter like a car; they seem to have nailed parallel parking ;-) Seriously though, I doubt Kotlin would ever be the first choice for a project like Spark since Scala excels in the DSL department (really without rival on the JVM, and off, only Haskell comes close). Look through Spark source code [1] and you'll see: operator overloading, (sealed) ADTs, exhaustive pattern matching, etc. functionality that you can't even think the thought in in a language like Kotlin. This has nothing to do with monad transformers and other FPisms, just straight DSL power. Finally, to put things in perspective in terms of the mindhsare that Scala and its ecosystem are drawing, IBM is investing over 100 million dollars per year in Spark research and development [2]. Sorry, but that's absolutely massive, maybe there are no dragons? Or if there are, the big players don't seem overly bothered. [1] https://github.com/apache/spark/blob/master/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/dsl/package.scala#L59 https://github.com/apache/spark/blob/master/sql/catalyst/src... [2] https://www-03.ibm.com/press/us/en/pressrelease/47107.wss https://www-03.ibm.com/press/us/en/pressrelease/47107.wss
- mahmoudimus 11y agoI very quickly skimmed through that scala style guide and starred it on Github, but having used both Kotlin and Scala, I am of the opinion that Kotlin (once it reaches v1.0) would remove the need for ~50% of the content of this style guide.