Looks well designed, and Li Haoyi generally writes great software. Still, it seems the main use case for this lib is “simple, synchronous API where you don’t care about concurrency.” Personally, I wouldn’t use Scala at all for these problems. I use Scala a tonne in high load services, that make 100s or even 1000s of requests per second - for these, Play WS with it's non-blocking IO works great. For projects where small, simple, and synchronous makes sense, I personally reach for Python, not Scala.
I still think this is a nice library to have, but I don’t see it becoming big. It’s serving a use case that I think most people aren’t trying to satisfy when writing Scala.
In my experience, for most jvm apps non blocking io is a premature optimization that makes little performance difference. I once optimized an app, for instance, by switching to non blocking io, and was only able to go from 1000 rps percore to 1200. I got a better performance improvement by switching out the service's json library for a faster one, and that took far less effort.
For the most part, I see non blocking io as a fad. It can make a noticeable difference in Performance, but in practice most apps are so poorly optimized that there are easier, lower+hanging fruit.
Fair enough, threads are indeed cheaper than many realize, even JVM threads, which are basically OS threads. But projects where I use Scala do tend to include a lot of service calls that are worth making concurrent (for example, hitting 3 services at once for a single request, or looking up 20 entities at once from a service that doesn’t have a bulk endpoint). And if you’re going to wrap this library with future calls, properly configure your threadpool, etc., you may as well have just used the very mature Play WS, and also get better efficiency. The APIs are pretty similar aside from Play WS returning Futures.
This would have been very helpful to me about two to three months ago. I was doing an interview assessment during that period and I was required to do it in Scala, although I had no experience in it. My experience with HTTP requests comes mostly from Ruby, Python, and JavaScript, and when I was looking for analogous solutions in Scala I found the ecosystem lacking. It took me way too long to do something I knew how to do already in multiple languages.
I know people sometimes like to say the JavaScript ecosystem is a mess, but it being popular and having multiple ways to do things was something I learned to appreciate during that assessment.
Reqeusts is a library which offers a drastically simpler API than the built in solution, and as a result the API has been ported to multiple languages. Are there other examples of libraries offering simpler APIs which got heavily cloned?
Off topic: Is Scala still being adopted by new teams? I did couple of Scala dev jobs and later the market kind of died down, want to know if others are witnessing the same.
One of my friends was relocated recently with a very good offer and the only programming language he knows is Delphi. So I’m pretty sure programming languages never “die down”.
Yes. Scala market is smaller than some other programming languages but it is still growing.
For programmers, the important change in the market isn’t programming language adoption. It is expectation to work with multiple programming languages.
Majority of good opportunities in the market are going to ask for programmers that can work with two or three programming languages.
The math doesn’t check out, rankings contradict them (check TIOBE, or google indices, or even StackOverflow rankings). It’s sad to see this kind of conclusions in HN because they are not not only incorrect but dishonest.
I personally love the language, its rare to find a language that supports both object oriented and functional programming styles, while at the same time being able to access all the libraries available for java. Its definitely easy to shoot yourself in the foot given the complexity of the language, but if youre a senior engineer and dont need to worry about poor coding practices on your team, the functional abstractions are very powerful.
It is however the push recently in Spark seems to be for better/faster Python support more than anything else. Probably because Databricks makes it's money from it's hosted notebooks environment which caters more towards non-engineers (who in turn would be more put off by having to learn Scala I'm guessing).
Seen by people who understand nothing about either language then? The vast majority of Scala developers have nothing to do with frameworks that are "adopting" Kotlin. What Google does with Android is completely irrelevant to us. And I'm not sure Google uses Kotlin at all internally.
Kotlin is pretty much irrelevant outside Android, and even there only because Google most likely will never bother to move beyond Java 8 and Kotlin is the Android's Swift, regarding language replacements.
Dart is being positioned as a cross compiling, Android and iOS (but not web) development language with the Flutter platform. It very much seems like a replacement for Kotlin's usage on Android, but only if you are also switching to this UI framework.
It has a very long road to travel regarding OS APIs and the Android team evaded the question at Google IO about what was their opinion regarding Flutter.
Additionally, according to the Chrome team, also at IO, the way to do iOS and Android development is via PWAs, not Flutter.
We're using Kotlin in our backend and pretty happy about it. It has support for co-routines and great syntax, it's lightweight compared to Scala and IntelliJ plays great with Kotlin (no surprise as both of them are from JetBrains).
I won't even mention the learning curve, we started learning Kotlin using IntelliJ's support for converting Java files to Kotlin initially and then it took only one week to learn about the details thanks to its documentation.
I'm not sure how that would work in Scala.js without redesigning the library to have an async API, at which point it's not really the same library anyway. The author said that sync API was a major feature of this lib.
I still think this is a nice library to have, but I don’t see it becoming big. It’s serving a use case that I think most people aren’t trying to satisfy when writing Scala.