Like many developers I know, I have heavily invested in scala, attending conferences, spending countless hours studying and evangelizing it on every occasion I got.
With time, I got to be one of the lucky few who earn a (good) living building systems in scala.
The one thing that was lacking when I started using scala was tooling, but that was mitigated with the likes of InteliJ and metals.
From my 20+ years of software development, one of the things I’ve come to learn is that companies rarely buy into technology, but rather solutions. There was a time when selling scala to clients was easy, because It combined great language features, a great ecosystem, and tooling that actually worked. I am currently very hesitant to recommend scala 3, it’s luck IDE support is crippling.
I get it, the folks developing scala have a myriad of great ideas and I love that, it keeps the language fresh and exciting, but please remember that there are developers basing their livelihood on scala. When a great language like scala decides that tooling comes second, developers suffer.
We have a great community full of great minds, let’s invest and solve this tooling issue.
We’re the boots on the ground and we’re telling you that poor tooling support is greatly hurting the adoption of scala.
Thank you for feedback on tooling, and your witness from industrial practice. I think this kind of discussion would be excellent for another thread here on Contributors that perhaps could be called e.g. “Most important things to fix with Scala tooling” or similar that provide input and ideas on most pressing issues in tool support. Perhaps you want to open a new thread? @skmuiruri
There are long-term and short-term things when we discuss requirements for further language development and contributors working with tooling only partly overlap contributors looking into language foundations, so I think we can have both in mind on this forum. I think its best to stick to the topic of named tuples in this thread (edit: “that thread” after split).
I’ve split this off into a new thread.
I am sorry to say this, but this was not my experience in the past. Even in the present. For example, everyday I have to switch between files to trigger the intellij compiler mechanism to recheck my code, because it shows me outdated errors (Scala 3). I know there is metals. That has better support for the syntax stuff, but I tried it with vs code and basic things available for any language in intellij were missing.
At the Scala days Madrid I met some intellij guys. I must say, they were very helpful. But errors that I have reported in youtrack over a year ago were unknown to them. Once I showed them there live, they fixed it. But I think there is some kind of communication or organization problem. I also talked to one dev and he told me, that outside of the intellij plugin he basically does not touch Scala. Which I guess is his right, but makes it hard to see things that break in day to day code of a Scala dev.
Another very good example are match types, which, last time I checked, get resolved in metals but not in intellij. Same for transparent inline. Both not experimental features. And that not since yesterday.
I have the feeling intellij (maybe metals too) could use some “devs talk to us” meeting where ppl can talk to them about the daily problems they face. Also someone on the team that goes and compiles big libs or uses them, with the intention of breaking things sounds great. I don’t think this exists.
I must admit, would I have had better experience or see great improvement in this area, I would be less against named tuples.
I understand this and get the usage. I did not read enough of the stuff above to understand that before, my bad. But I still kinda dislike it. Because it is not a macro only feature and will get mixed into non macro code for sure. I’d rather see better support for structural types, then having something new.
My couple of cents here, since tooling was mentioned 
I have the feeling intellij (maybe metals too) could use some “devs talk to us” meeting where ppl can talk to them about the daily problems they face. Also someone on the team that goes and compiles big libs or uses them, with the intention of breaking things sounds great. I don’t think this exists.
I am always open to this 100% when it comes to Metals and if needed we also have direct lines of communication to the Scala plugin people. I am also always trying to convince them to use the default compiler, which would make a lot of things easier, but it’s a more complex matter.
I you have any particular issues with Metals, I have a couple of things that I know require more work and currently trying to change the, but it anyone at all has some particular blocking issues please do report them if you can. We can also sign any NDAs you want to and go over the code with you to see how we can fix things or make them better.
@makingthematrix Perhaps you can say something about what kind of industrial experiecne would be valuable for the IntelliJ Scala plugin devs and your plans for the near future with e.g. match type rendering? (See comment by @987Nabil above)