
Requests-Scala: A Scala Port of the Popular Python Requests HTTP Client - lihaoyi
https://github.com/lihaoyi/requests-scala
======
yashap
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.

~~~
sreque
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.

~~~
yashap
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.

------
bepotts
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.

------
enitihas
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?

~~~
k__
I only know Superagent for Node.js, which is really simple, but I don't know
if it's simpler than Requests.

------
alienallys
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.

~~~
seunosewa
Good question, since Google’s adoption of Kotlin was seen as the death knell
for Scala.

~~~
pjmlp
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.

~~~
dangjc
I wonder if Dart will supersede Kotlin now that Flutter is getting attention
on mobile.

~~~
buremba
Dart is a successor to Javascript, not Kotlin.

~~~
dangjc
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.

[https://medium.com/dartlang/announcing-
dart-2-80ba01f43b6](https://medium.com/dartlang/announcing-dart-2-80ba01f43b6)

~~~
pjmlp
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.

This is just Google playing with their teams.

------
tutanchamun
Nice, would have been exactly what I wanted last year. Ended up discovering
sttp which is also really nice.

btw: since you were one of the early adopters of Scala.js, will/can this be
ported to Scala.js

~~~
raquo
This has a blocking API which is a no go in single threaded Javascript, so my
guess is no

~~~
AzzieElbab
Super easy to wrap into futures or IO to make it asynchronous. It is scala
afterall, not python

~~~
raquo
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.

------
1996
Does it leak memory due to improper CRL handling like the python version?

