3 ms·

Scala has a really steep learning curve when you encounter user libraries. Though I am moderately experienced in functional programming, I still have difficulti

Scala has a really steep learning curve when you encounter user libraries. Though I am moderately experienced in functional programming, I still have difficulties understanding scala libraries from very experienced users. It almost feels as if I didn't understand the language at all. It is true that you can use the JVM ecosystem, but you'll see that your code doesn't look like scala at all. Then you look for scala ported version of java libraries (some essential but boring libraries like xls read/write) that isn't likely to be maintained actively

matthewtovbin 6y ago
I politely disagree. This is no longer true.
mcintyre1994 6y ago
I'd agree with this. I think it's because if you're writing a web server then you're probably settled on one way you're going to deal with say asynchrony - plain futures or cats or whatever. But Scala has this level of abstraction above that where you can write a library that doesn't care which of those you're using and just slot in around your choice. What it can't avoid is that as soon as you jump into the source code of that library you see all these type classes everywhere and have to mentally fit your concrete use case into those complex looking function signatures that probably use concepts you're not using much in your actual application code. For better or worse it's super easy to write application code in Scala without going to a very abstract level, particularly in an ecosystem like Play. And that does make library code feel less familiar because it's using features that you just don't necessarily use very much in your application code.
- totorovirus 6y ago
  Play is very well documented (compared to other libraries) but some of scala libraries are not very well documented that I had to actively dive into source code level. Reading and understanding it wasn't easy at all. Scala seems to have many black magics under the hood and this is one of biggest drawback of using scala

matthewtovbin 6y ago

I politely disagree. This is no longer true.

mcintyre1994 6y ago

I'd agree with this. I think it's because if you're writing a web server then you're probably settled on one way you're going to deal with say asynchrony - plain futures or cats or whatever. But Scala has this level of abstraction above that where you can write a library that doesn't care which of those you're using and just slot in around your choice. What it can't avoid is that as soon as you jump into the source code of that library you see all these type classes everywhere and have to mentally fit your concrete use case into those complex looking function signatures that probably use concepts you're not using much in your actual application code. For better or worse it's super easy to write application code in Scala without going to a very abstract level, particularly in an ecosystem like Play. And that does make library code feel less familiar because it's using features that you just don't necessarily use very much in your application code.

totorovirus 6y ago
Play is very well documented (compared to other libraries) but some of scala libraries are not very well documented that I had to actively dive into source code level. Reading and understanding it wasn't easy at all. Scala seems to have many black magics under the hood and this is one of biggest drawback of using scala