I write many mutable code in scala. I had only one problem with immutability it is collection architecture which requires time to accustom.
I can understand your love to immutability. But Language is a tool for me. I have to use many languages. A love to some idea is very big luxury for me (
Is there anything stopping you from e.g. mixing Kotlin with Scala? Take Apache Spark for example: it has APIs for Java, Scala, Python and R. I bet you can use Kotlin with it without pain. Choose the right tool.
It is an interesting topic for me, how to make language X more popular—this case X=Scala. One problem is that beginners find certain things difficult. These beginners either abandon the language or start understanding the things, in which case they cease being difficult. In either case the difficulty of learning is forgotten.
Is a complaint by a novice that “thing Y is difficult to understand” an important comment? I suspect there is underestimated value is such statements.
I keep saying that I want to create an article about things I think are difficult in Scala based on my personal learning curve. But doing this is really hard. And also, I don’t really know how to present or position such an article to maximize its benefit. E.g., I made a proposal for such a talk at a recent Scala conference, and it was sadly 
rejected without any comment.
Of course it is. language injection is very interesting theme.
Thank you. I just believe your words.
@tarsa, I’ve often wondered whether it is valuable to mix Scala and Clojure. As they are both functional, my guess is that parts of your implementation which are easier to write without worrying about types, you could do in Clojure, and parts where you want code to be statically typed, or where you need tail recursion, you could use Scala. My experience, however, is that programmers who have used both languages usually love one using one and hate using the other. Which one is loved and which one is hated depends on the person.
Naively looking at it, it seems the Scala rigid dependence on the maven directory structure for projects makes interfacing with Clojure pretty difficult. Maybe I’m wrong.
The landscape changed quite a bit with Google officially(?) backing Kotlin and Kotlin’s popularity skyrocketing as a result. I think Kotlin is a great “better java”. I think Scala has the potential to be its own thing and a better language instead and that trying to be a better Java in the current landscape is a loosing fight anyway.
Now, I guess these real life concerns have to be contrasted with the fact that a “better Java” will always have an easier time to get Java devs converted. So long as there is a decently sized and preferably growing community of companies and devs using idiomatic Scala I think it’s fine to accept that Scala is never going to be the dominant alternative language on the JVM, given the obvious non-technical advantages of competitors.
If someone would like a “better Java” they’d very likely see a lot of Scala’s distinguishing features as unneeded complexity and would go With Kotlin.
I do not know the aim why you quoted my words. I just add not to abuse context. I disagree that scala should be more worse than java in processing big data or procedural approach.
I think it’s quite important – but also quite easy to misinterpret. Especially when working with novices, how something is taught matters at least as much as the subject itself.
FP is one of the best examples of that. On the one hand, I’ve seen a depressing number of people who tried to start with FPiS and ran screaming, because they tried it out too early. On the other hand, I have yet to encounter anybody who finds Creative Scala difficult. It’s still teaching FP, but is intentionally doing so in a beginner-friendly way.
That isn’t to say that there aren’t just-plain-hard concepts. But in my experience, the fault tends to lie more in the documentation and teaching. (Or lack thereof, when somebody just gets thrown into the deep end with no guidance at all…)
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.
Teaching it at universities.
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.
What makes Scala a better choice than Kotlin in your case?
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.
I want more than a better Java. More expressive power, more safety, more of an ability to reason about code.
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.)
Ok, thanks for the info it’s news to me! Hopefully this thread will help others find it here;
https://marketplace.eclipse.org/content/scala-ide
All of the Scala tutorials I have viewed do start with ‘download IntelliJ’!
I was just relaying hearsay of what I heard, I apologize if I was proliferating misinformation!