What can make scala more popular?

Just a remark that implicits are the first thing that throw people off whenever they need to work on the scala codebase at our company. Creates a sense of “this happens automagically” in the language that is a bit of over-engineering in terms of practical programming language usage in a private sector company. And when the necessary implicit isn’t predefined in the context, then it can be pretty confusing for a java dev writing scala (e.g. implicit formats),

To make things clear, there are very big differences between Scala and Kotlin.

Kotlin is a better java, the language is being advertised as such. Its like a much better implementation of project Lombok and JavaFx.

Scala is a fusion of OO and FP, even the new core calculus used in Dotty (Dot calculus) is a mathematical formulation of this concept.

I disagree with this statement (and this is in context of me already teaching Scala to dozens of newcomers of different backgrounds). Lets make things clear here, these are the biggest problem with implicits are

  • Implicit conversions which were designated as an anti-pattern a long time ago and are being removed. Trying to justify removal/changing of implicits on this point is like removing/changing Scala’s type inference completely because there are some off examples
  • The current Scalac compiler is kind of terrible in reporting/diagnosing missing and conflicting implicit searches. This is probably the biggest issue I have seen from newcomers learning Scala. Its not that they don’t understand the concept of implicits (its actually quite an elegant and easy concept to understand), its that when a you compile Scala code and an implicit is missing (or there is a conflict), the compiler will give you a completely different error that is buried 3 times up the implicit chain

This is a problem that an IDE is designed to solve and ironically Intellij (which people historically complained about due to them implementing their own typechecker) is now much better than Scalac in diagnosing missing implicits and tracking them. Heck they just released a new feature where given an implicit definition, you can see everywhere where it is being used. The reason why people complain about implicits being “magic” is the same reason that people would complain about static types if the IDE wouldn’t be able to provide type information about values correctly.


We also use implicits only as context definition (as thread variables). Or it is the thing which every one must know by heart as language grammar.

Depends on the library. Some libraries abuse implicits and other language features (hello, Slick). But usually using help from IDE makes things very clear. Take IntelliJ IDEA for example. If you have an implicit conversion and want to see where is the implicit conversion then use Ctrl+Shift+Q. If you have an implicit parameter and want to see where it comes from then use Ctrl+Shift+P. See here for more info: https://www.jetbrains.com/help/idea/edit-scala-code.html

Sadly, if we are writing new code then IDE often doesn’t help much with finding proper implicit parameters and/ or conversions combination. But for already written and working code, IDE support (i.e. Ctrl+Shift+P and Ctrl+Shift+Q in Intellij) often removes all the magic from implicits. Compare that to annotation driven development or aspects in Java and use of ThreadLocals. These things are actually magic. You cannot even see the code that Spring, Hibernate, Guice, Mockito, etc produces, not to mention analyze, change or debug it. ThreadLocals subvert the ability to do asynchronous programming, because offloading work to another thread means losing ThreadLocal data access (unless we pull the data from ThreadLocal storage and pass it around manually, in which case what’s the point with ThreadLocals?).

I didn’t see @mdedetrich was already talking about implicits, but I’ll leave this post as it presents somewhat different perspective.

By implicit conversion I mean also those kinds of conversions that are used to provide extension methods. Extension methods won’t be removed from future Scala versions, only implemented differently. But currently extension methods are implemented using implicit conversions so proper IDE support for them is very much welcome.

Nevertheless it is more difficult and I agree that in many cases it is too complicated.
We just forbid to create implicits without special approvement

So I do not understand why they recommend to use implicits as builder pattern.
Use implicits to make structure is obvious bad style for me.
And it seems that I am not the only one who think the same.
So I am sure that

Is a bad vision.

I have tried to summarize discussion for our company(we use kotlin,java,scala):
And our checklist is

  • when you need jvm and statically typed language
    1. use java
      • when you write low level decision (application server)
    2. use kotlin
      • when you need high level decision(web app)
      • when there are enough standard arithmetic with java types(int,Bigdecimal,String, etc)
    3. use scala
      • when you need high level decision
      • when you really need custom arithmetic

There are options of course, it is just simple start point.
We specialize on data processing.
So if scala had successful whitebox macros or just external preprocessors I would have arguments against the second option.
It would be also usfull:

  • xml literals is deprecated
    It is useful sometimes
  • delayedinit is deprecated
    It is just argument for kotlin
  • symbol literals is depricated
    We need good dynamic mutable\immutable pojo
  • etc
1 Like

implicit keyword is used for many different purposes. Implicit conversions, extension methods and implicit parameters (inlucing context bounds). What is considered bad practice are implicit conversions per se. Implicit functions are functions with implicit parameter, so that doesn’t make them bad practice.

No, it does not.
I do not know universal rule which do not lead to holywar.
We use principle:
If someone read code in text editor and do not understand what it is going on because of implicits it is a bad practice.

So, we use implicits

  • instead of thread variables(it is evil in any case)
    there are 2 such implicits in our framework
  • to make constants, for exampl 2.nn is equavalent to NNumber(2)
    Everybody know it by heart.
  • context bounds def f[A : B]
    implicit should be in object A

So there are no need for

IMHO If you need IDE help it is a bad practice :wink:

There’s no point in making everyone happy. You can’t satisfy everyone at the same time.

Some Java programmers were scared by var keyword. They say they do not understand code with vars if they are reading it in text editor, so they prefer explicit types.

1 Like

I have said very different thing. All implicits( except context bound) must be known by heart by everyone

it is not like library extension it is more like language extension.

It is very expensive

Either that, or it has to be something that if you need to examine, you use an IDE, and you can understand the code at least superficially, without an IDE.

An example of that is Ordering. You can read xs.sortBy(f) without having to know about implicits, unless you need to examine it more closely. So if you can assume that anyone that needs to examine it more closely has the requisite tooling (such as the latest IntelliJ Scala plugin), then you don’t have to assume memorization.

The other side of that coin is that when designing a library and deciding how implicit-heavy it will be, you are deciding what level of understanding it is possible to get without implicit-examining tools. For example, from just reading code that uses Slick, you don’t know much about the machinery that’s deciding how to work with your types. That machinery plays a pretty significant role in the behavior of the code. At the same time, I’d kind of rather not have that part written out. If it was explicit, it would be much harder to see the more important part of the code, such as the columns or queries I’m defining. (But no question, now that IntelliJ can show the implicit parts as if they were written out, I would sometimes turn that on.)

1 Like

May be it is most undeniable implicit feature.

There is other very important thing, it is the amount of brain to understand it :slight_smile:
There are two important moment in that joke:

  • The less brain is needed by you to read and write, the more brain you can spend on solving business task
  • I think there are mostly very smart people in this forum. But there are many usual people which can not be so smart for scala, but they can be usually much better for business task.

It is very hard to prove, but take into account some practice, for example:

Or let us just look on kotlin :slight_smile:

We are not lazy to think, we just want to think more about business tasks and about people.

I think it is really killer feature.
You just do not need to learn by heart where you need to write import someUnknownWord._ :slight_smile:

see also:

1 Like

Show me code with lots of receiver functions. Will it be only about mutable DSLs?

I have discussed a lot that question in other topics, so I would prefer not to repeat it here.

I have not thought much about it. We need better

  • scope managment
  • builder pattern

So no publicly available code to discuss? Then it doesn’t seem receiver functions are popular.

There are a lot of examples in other topics.

It seems so for scala users :frowning:

But kotlink users sometimes troll me :))

1 Like

All I see is mutable HTML DSLs harassed over and over. HTML is easy. Show me how do you deal with CSS with receiver functions :slight_smile:

Immutable type-safe HTML DSLs should be doable using type unions (available in Dotty), e.g.:

object HtmlDsl {
  type HtmlChild = ElemHead | ElemBody

  type HeadChild = ElemMeta | ElemTitle

  type BodyChild = ElemTable | ElemP

  def html(items: HtmlChild*): ElemHtml = ???

  def head(items: HeadChild*): ElemHead = ???

  def body(items: BodyChild*): ElemBody = ???

IDE should be able to suggest matching methods in auto-complete, i.e. IntelliJ already sorts method in auto-complete putting methods with correct result type first.

Here you have your killer feature :slight_smile: In FP form (immutability oriented) instead of typical OOP form (mutability oriented).

I have never said that it is killer feature for FP. I have thought it is obvious.

I have not seen simple scope management here.

Show me an example where it is not sufficient.