I think arguing for Scala to have a pronounced “better Java” aspect was reasonable until the aforementioned changes in the JVM ecosystem as it had the potential to drive adoption. Now when you are picking a statically typed JVM language, you have to justify Scala not only against Java but also against Kotlin. Both enjoy wider adoption and bigger names behind it. This on itself makes arguing for Scala a difficult uphill battle. Then you look at the actual languages and see that you have a “better Java” on the one hand and a “better Java with HKT and implicits/givens and a buch of alien-to-Java-devs concepts on the other”. I just don’t see someone who’s after a “better Java” to choose Scala over Kotlin at this point.
At the current climate Scala just has to target a different segment. Offer a better language and a consistent world view of its own, thus differentiating itself from both Java and Kotlin. Does this mean it has to become exclusively a “poor man’s Haskell” on the JVM? I don’t think so, but it is probably benefinial to allow that paradigm to have a substantial influence. Maybe others too, but the kitchen sink syndrome should also be avoided in the process. It does however mean that it needs to be different, better, and better not just from the devs’ but from the business’ point of view.
I replied to what you wrote. Maybe you had more specific concerns in mind than what you expressed, but given the title of the topic and what I quoted from you I find my reply relevant.
The good news is it never will. I would be surprised if anyone with influence over the Scala Improvement Process would ever say “let’s remove support for imperative programming”. I for one wouldn’t mind if in the name of offering a clean and consistent world view / paradigm some “javaisms” would be behind a compiler flag, but even that is more than unlikely to happen and either way, this stuff will stay with the language forever AFAICT.
That’s as far as you mentioning procedural/impreative approach goes. I find your “processing big data” orthogonal to all this, so won’t address it. It does however open a different discussion, the one of the killer app, that is so often seen as a prerequisite for a language to succeed. Scala is loosing on the JVM to Kotlin (and Java), on the Spark and big data front Python is eating up everything…
I personally don’t buy the killer app argument. A language either is a better choice or it is not. But I can see that the world does buy it. Maybe the best would be to pick one or more application(s)/domain(s) where things can be improved at least as much as Ruby/Rails improved web dev compared to J2EE/EJB of the early 2000’s, in addition to providing this unique world view. What these should be though… good question.
By the time I graduated everyone around me thought that software development is writing imperative code in either C# or Java and bundling it up in classes, the more involved ones probably adding “organizing the classes into GoF patterns”.
By the time we had exposure to Haskell and Python(!) as an optional(!) module no one really seen it as more than an unrealistic and unnecessary academic exercise, if they chose the module in the fist place.
Granted, other universities expose students to e.g. functional programming much sooner and make it compulsory, but the “unrealistic academic exercise” feeling is often defining, idk, maybe because the material doesn’t go beyond teaching abstract concepts in isolation.
If you want something better but different to gain popularity, you have to show people before they’ve already formed their opinions, that it can be used more effectively to tackle real world problems.
My understanding is that big companies partner with unis to make sure that their tech is taught. I think it is a very productive strategy.
I don’t think scala and python are direct competitors.
Nevertheless our first choice is hashkey-based access vs index-based access in such terminology.
We just cannot afford the risk to be ten times slower
(Scala programming language is 10 times faster than Python for data analysis )
All other argumentation was nothing against it.(At least for our commercial director )
The next killer feature was language productivity. All our calculations had shown that scala is less risky choice.
I think a Eclipse plugin would help. At the CJUG (Chicago Java Users Group) a few folks have mentioned the IntelliJ plugin lacking good robust maintenance. Since IntelliJ was created by the same people as Kotlin, I think there could be a implicit bias.
I like my project tree
If I were choosing Scala todays, I think my logic would be. There are area in our company were we need custom primitive types. Java types do not fit at all. I should think about Scala from such perspectiv. It can be funny but String interpolation is certainly a killer feature. I just don’t understanow how it is possible to make such comfortable library like anorm in kotlin. there are monoids which is practically killer feature. It may be possible theoretically to make perfect libraries with custom types in kotlin, but it is costly and highly risky. There are nothing in kotlin to force us taking such risks.
If custom pritmitive types mean subclasses of AnyVal then they still can have high cost: Failed Experiments: The High Cost of AnyVal subclasses...
Therefore I rarely use them and instead I use plain case classes which have predictable boxing cost.
Kotlin has string interpolation.
Not sure what exactly are you praising, but there are libraries like https://www.jooq.org/ if you’re into creating SQL queries manually instead of going high-level route like Slick, Quill, Squeryl etc
https://arrow-kt.io/ is the Kotlin scalaz / cats equivalent. Hard to tell how convenient that is 'cause I don’t program in Kotlin. Dotty / Scala 3 probably will be miles ahead, but current encoding of typeclasses in Scala 2 is far from perfect so maybe in simple cases it isn’t substantially better than Kotlin one.
It is very interesting. I just will make conclusion: Scala allows us working more efficient because of stuff which have been said before. I do not think kotlin or java would be better.
Yep, me too. But for that I think we need (and we indeed have) vastly different APIs than typical imperative ones from Java. I rarely interface with Java frameworks nowadays, but when I do I feel they do not want to enrich type system to enhance safety. Instead of e.g. having type safe builders or configurations we have type-unsafe ones. E.g. there are 10 setters on a type (let’s call them setter1, setter2, …, setter10) and a build or start method. I have to use a subset of those setters but types don’t guide me which ones. Therefore I e.g. use setters 1, 2, 3 and 8 and then only after running the code I get an exception which I’m googling and finding out I had to run setter7 not setter8 in this case.
Before improving integration with some Java APIs we should consider whether we want to promote those APIs in Scala. Maybe there already viable alternatives in Scala that are more type-safe, concise and composable.
That exists – I think it predates the IntelliJ one, although I’m not sure. I used it for a good five years, personally.
But having used both, I have to disagree with the premise: the IntelliJ plugin is much better-maintained than the Eclipse one. This isn’t surprising – IntelliJ costs a fortune, whereas Eclipse is free and supported by a few over-worked volunteers. I wound up switching to IntelliJ a year or so ago, after having been one of the few holdouts on Eclipse. So while, yes, I suspect that Kotlin is the higher priority for them, IMO JetBrains does a reasonably good job maintaining its Scala plugin, and I’m surprised by the comments otherwise.
(Mind, I’ll probably switch to Metals/VSCode before long, and I look forward to Scala 3’s built in support for LSP. But IntelliJ’s pretty decent.)
It may have since been superseded by Kotlin, as part of the Android tooling; but last I spoke to the IntelliJ folks, Scala support was their most heavily downloaded plugin by a significant margin.
However much they want to support their own language, I can’t see them ignoring such a large audience of people who are downloading, using, and paying for the product in order to use that plugin.
I’ll also note that I see it regularly updated. Just a few months ago there was a major enhancement to the way it displays inferred type information. So the strong Scala support in IntelliJ won’t be going away any time soon.
For me the answer is obvious - normal (fast and convenient) numeric and dataframes libraries are missing. I constantly have to switch to python because it is impossible to do anything useful numerically in Scala, scala breeze is less flexible than numpy and lacks many features. In terms of dataframes only Spark has some dataframes features but it is too heavy for most of the tasks and fails miserably for many use-cases (like having very wide dataframes or transposing dataframes).
There is intresting statment there, it is somethink like:
Performance does not influence on popularity.
IMHO: It is half of true which can easily lead to leaky abstractions.
Here is an interesting message:Linus Torvalds on C++
The real problem of C++ is not the complexity. It is amount of leaky abstractions.
So it is very important making scala more simple and light, but if it leads to a leaky abstraction it will not be good. For example I do not think that data processing with performance of dynamic languages is good thing. A good dynamic language always has more killer features in such situation.
Most abstractions are not about improving performance. Quoting Wikipedia:
.
A few percent of method calls in Java are megamorphic, thus the HotSpot JIT is not able to devirtualize them, so they more or less have “performance of dynamic languages”. Are Java programmers avoiding megamorphic calls? I think almost none of them even know what it is, let alone care about it (how often do you check if your method calls are megamorphic?). Java is fast enough to not care. JITed pure Java code is orders of magnitude faster than interpreted pure Python code, even with few percent of method calls being slow.
Take for example std::sort from C++ STL. It is generally fast, but it’s not hard to write significantly faster sorting algorithm for your particular use case (I’ve done it many times). Are people doing that? Usually not, because std::sort is fast enough for most people.
You would have to reject most abstractions if the possibility of writing noticeably faster manually optimized code is a reason for abstraction rejection.
A killer feature of dynamic language, besides killing performance is also killing static analysis. With fully dynamic typing you don’t have automated refactoring, navigation, static error checking, auto-completion etc Of course you can add type inference to your tools (and restructure your code to make those tools work well), add type hints to your code, but if you do it seriously then why not to switch to a language that has type inference and static analysis as a first-class features?
I can say more simple if scala had performance of python in practice I would choose python. Static language with practical performance of dynamic one is bad design. I use leaky abstraction for stuff which lead to bad design. I will be glad If you propose me something better
Scala performance is close to Java and will stay that way. OTOH, there are usage scenarios where Python has comparable performance to Java, e.g. parsing text using regular expressions (as they are implemented using C code in Python) or invoking natvie methods and executables (i.e. writing glue code). Does Java need to be multiple times faster than Python in everything to be considered an improvement?
)