One small step I think would be worthwhile would be to rename InlineConversion to something like MacroConversion
Programmers have a tendency to make everything they can inline, since it can only make their code faster at runtime.
We do so even in cases where the optimiser would have inlined anyways, as we don’t necessarily know that would have been the case !
Therefore, I fear people would use InlineConversion instead of Conversion when not using macros.
Furthermore, “macro” has an aura of danger which implicitly means “You better know what you’re doing”
We could also lock MacroConversion/InlineConversion behind an import specifically for it
This would allow us to write a strong and clear warning in the “missing feature import” error message
Since errors can be multiline, we even have the space to propose alternate, non-macro, ways of getting some tasks done
Agreed – the primary complaint I hear in the field is always about Scala being bad about backward compatibility.
Implicit conversions are a super-niche complaint, that a few opinionated hardcore programmers (rarely the ones in charge) care about. I’ve literally never heard this complaint raised at work, across a succession of companies.
The decision-makers care primarily about compatibility (along with difficulty of finding experienced engineers), and the amount of programmer effort needed to maintain their large code bases. Every change that requires rewrites that aren’t 100% reliably automated is a gigantic negative.
Kind of a boost to the importance of tooling: I have heard complaints about this, but the last time I can remember it being an issue was at least 6-7 years ago, and especially since IntelliJ shipped some really nice tooling improvements around implicit conversions and parameters a couple years back (2018?) it’s been a non-issue.
I’m not sure I qualify as “industry” since my company barely touched a dozen scala dev in 15 years but:
implicit conversion never were an issue. I mean, there was a period circa 2012 when their over-use, without community “best practices” in place, was a pain (hard to navigate for ex), but compared to scalac bugs, a non-existing binary compat story, or IDE/build tool extremely poor support at the time, even with dedicated effort to bring eclipse to some kind of reliability, they were a distant concern;
on the other hand, breaking source/binary compat is horrible. The progress here are extremely worthy, but 3 years and counting, and we are still not able to migrate to scala 3, even with a lot of dedicated effort and calling recognized expert on scala 3 migration for help (ie, I stand for Two More Old Cents on Scala 3 Migration // - but hey, progress, we’re almost done). And this is with me directing the project, ie with all the knowledge of the extrem importance of being up to date to be in a sustainable path - in most companies, the challenge we are facing would lead to "scala is crap, we are migrating awayt to [rust|typescript|kotlin|whatever is hype today].
Appart for source/binary breakage with difficult or non applicable workaround and tooling (which are industry killers), the most irritating things are for us are “efficiency”:
the slow feedback loop on complex/big project.
the difficulty to put in place 0 cost abstractions / low vm-churn patterns, esp for super standard FP dessign patterns (like new type, value class, enum) - of course “at the best the underlying platform can do”, I’m no asking to make Vahala live. And here, things are better here with scala 3, and it’s a nice enhancement, a positive dynamic.
I still want to point out that scala remains a super effective language for our case (ie a small team with a long lived, complex multi-maintained branches project), and we wouldn’t have been able to maintain a complex project with super-low operability overhead for on-premise customers without it. But sometime, it’s a calling.
In my small company (IoT platform) we have to develop and maintain a codebase from around 50kLOC in Scala and code in other languages, mainly C.
What does not bother us:
Compile times are completely irrelevant. Probably they feel annoying due to the forced wait, but the real impact on the productivity is zero.
Runtime efficiency is relevant, only sometimes. And not after it was established being a real bottle neck. We try to develop with efficiency in mind, but clear code wins over fast code.
Implicit conversions are not a problem. But we try to keep code as simple as reasonably possible. And since implicit conversions hide the true sequence of events from the visible code, we try to avoid overuse.
So, what are the top three annoyances then:
External libraries not moving along with the Scala versions, or moving to slowly, being stalled, or introducing breaking changes. We had to remove all dependency on Play!, Akka agents, AkkaJS and more. Now we are removing NVD3 and sometime in the future we need to remove dependency on Akka itself. These are the real time burners. Due to these experiences we have become very reluctant to introduce new dependencies.
Compiler errors / new warnings etc due to version increase of Scala / Scala JS etc without a clear and simple migration path. Biggest fear: being dependent on some feature which is not supported any more all of a sudden with no way out other then a rewrite of code. Fortunately, this is seldom. The transition from Scala 2 to 3 was challenging, but doable. Our experience with the automatic rewrite tool was not all that positive though, we did large parts by hand.
Lag of tooling on the Scala versions. For example Metals on Sublime Text. This is no criticism on their fantastic work for this free tool. It is just, we miss out on most of the nice features due to the version mismatch.
But, the bottom line is that we stay on Scala for its unique property that after you have formulated your problem, it gives the most concise code with the least surprises of all languages we have used so far.
Well, if we are collecting comments… I have almost only used scala professionally since 2011 (Twitter, Stripe, and now Netflix). Definitely in 2011 and 2012 there was hand wringing about implicit conversions at Twitter, but we got a handle on what was and was not an acceptable style (virtually never). By the time I left in late 2015 I don’t recall this coming up at all.
However, complaints about compile times and tooling still exist. Metals is a good improvement, but it is not yet nearly as reliable as intellij especially for larger projects. Compilation times improved (also computers got faster), but builds can’t be too fast. I think better compiler error messages to help new-comers is related to tooling. Rust and Elm have really shown the way here IMO.