https://kotlinlang.org logo
b

Ben Butterworth

02/02/2021, 10:36 AM
Why is it important that extra programming features (coroutines) are added via libraries instead of the language directly? Ive heard this "benefit" of kotlin stated a few times but never really understood whats so beneficial. I can guess one benefit: a library can evolve faster than a language.
j

Javier

02/02/2021, 10:37 AM
Because coroutines library is an implementation of that feature. Arrow, for example, has its own implementation too.
b

Ben Butterworth

02/02/2021, 10:49 AM
But why is that important? Other languages don't bake it into the language. I guess to make library developers happier and libraries more flexible/powerful.
m

Marc Knaup

02/02/2021, 10:49 AM
Also it makes the standard library smaller if you don’t need coroutines. Library size matters for example when targeting the browser with Kotlin/JS.
j

Javier

02/02/2021, 10:50 AM
Yes, because if I want to use another implementation, what is the reason to pollute all with something I am not going to use and it is so specific? The minimum is
suspend
and it is available without coroutines lib
s

stephanmg

02/02/2021, 10:53 AM
@Ben Butterworth interesting question
probably it depends... baking into the language might have also benefits
🚫 1
m

Marc Knaup

02/02/2021, 10:57 AM
What would “baking it into the language” mean anyway? You’d still have to ship the implementation as a library. Kotlin doesn’t have its own VM. So the implementation would simply move from kotlinx-coroutines to stdlib.
👍 4
s

stephanmg

02/02/2021, 10:58 AM
@Marko Mitic yes I am unsure of the meaning introduced by @Ben Butterworth
not sure if this is a good example but the C++ Concurrency API is "baked into the language" - which actually is a step forward in my opinion
m

Marc Knaup

02/02/2021, 10:59 AM
So it’s likely located in C++’s stdlib
s

stephanmg

02/02/2021, 10:59 AM
I think so
@Ben Butterworth so what do you mean with that expression? I think it's quiet natural to use a modular approach instead of putting everything into one monolith
k

Karlo Lozovina

02/02/2021, 11:27 AM
often, feature X being implemented as a library instead of being built in is used as proof that some language is better because it's more expressive, gives more power and freedom to the users instead of language developers, etc
s

stephanmg

02/02/2021, 11:27 AM
why it is more epressive?
expressive...
k

Karlo Lozovina

02/02/2021, 11:28 AM
why is language more expressive if its users can implement feature X, while in another language they cant?
s

stephanmg

02/02/2021, 11:29 AM
no, why would the language being considered as proof to be more expressive when a feature is implemented as a library or built-in? it should be about the same
k

Karlo Lozovina

02/02/2021, 11:34 AM
oh, I see what you mean, didn't get it the first time: you're asking for expressivity in total, language + feature X, regardless how's the feature implemented... in that case it would be basically the same
ignoring that features that are not built in to the language have less tooling support, worse documentation, can't count on them being present, etc...
still, people prefer features as libraries because it feels like that's a better choice...
and sometimes they need feature Y that's not provided by the language and they can then implement it on their own
b

Ben Butterworth

02/02/2021, 11:59 AM
But they can "implement it on their own" regardless of where the primitives lie. Sure it would reduce the bloat, but i think the main reason is as Marc stated, in Kotlin its not a big difference at all:
So the implementation would simply move from kotlinx-coroutines to stdlib.
s

stephanmg

02/02/2021, 12:07 PM
Yeah and it's way more modular.
One does not have to ship a huuuge standard lib.
I like that actually
k

Karlo Lozovina

02/02/2021, 12:12 PM
btw, I'm not super familiar how Kotlin does coroutines, but I'm guessing there'a s a part built in to the language (some notion of continuation?) and there's library code that builds all the coroutine machinery above that... in the end, where that library code lives (stdlib, some other official library) is not that important
👍 1
I thought the discussion was more around that lowest level primitives built-in to the language, that enable kotlinx.coroutines library to be built on top of it
n

Nir

02/02/2021, 2:02 PM
Reading this thread I feel like there's two parallel discussions going on
Baked into the language doesn't usually mean "in the standard library"
It means "in the compiler"
g

gildor

02/02/2021, 2:04 PM
It makes evolution of both stdlib/language and library faster and easier. For example to remove anything from stdlib you need at least 2 major releases (1 release for depreciation and 1 for removal), add or remove something from the language is a lot harder than from library Everything what can be library better to keep in library
A library can evolve faster
And it happening, kotlinx.coroutines have much more releases I think your question should be inverted, why add something to stdlib if it works fine in a library
mind blown 1
5
😍 1
n

Nir

02/02/2021, 2:04 PM
I don't know if that's what Ben meant or not but there seems to be comments interpreting it either way
s

stephanmg

02/02/2021, 2:04 PM
ahh, so my C++ threading example might be then correct. because it’s mainly compiler constraints
n

Nir

02/02/2021, 2:05 PM
C++ multithreading is standard library
Not core language
s

stephanmg

02/02/2021, 2:05 PM
ok, sorry i meant Concurrency API
n

Nir

02/02/2021, 2:06 PM
What do you mean by that?
s

stephanmg

02/02/2021, 2:06 PM
but anyway you are right I guess
n

Nir

02/02/2021, 2:07 PM
Yeah it's all stdlib
s

stephanmg

02/02/2021, 2:08 PM
I’m still a little unclear, so baked into language means into the compiler?
seems still like a vague term
n

Nir

02/02/2021, 2:09 PM
i don't know if there's an official definition but that's usually what I see
Like suspend is baked into the language
1
You can't implement suspend yourself, period
☝️ 2
s

stephanmg

02/02/2021, 2:09 PM
that makes sense
n

Nir

02/02/2021, 2:10 PM
Core language vs library is much more important than whether that library happens to be standard or third party
👍 1
s

stephanmg

02/02/2021, 2:10 PM
so what are pros of pulling code into the core language?
n

Nir

02/02/2021, 2:11 PM
Well you can of course do things that are totally impossible in libraries
s

stephanmg

02/02/2021, 2:11 PM
@Nir could you give an example?
other than suspend
n

Nir

02/02/2021, 2:12 PM
Like defining a class? :-)
Lambdas, extension functions, reflections
Etc
s

stephanmg

02/02/2021, 2:15 PM
OK thanks @Nir
n

Nir

02/02/2021, 2:15 PM
A better example is something like string formatting
You could do string formatting as a library
s

stephanmg

02/02/2021, 2:16 PM
Btw.: The matters you discussed do not only apply to Kotlin exclusively, right?
n

Nir

02/02/2021, 2:16 PM
E.g you could have syntax like "{}".format(x)
But you can't do string interpolation as a library
The downside is that because it's done in the compiler, we can't easily extend or develop another library with the same syntax
The upside is we get really really nice syntax
Yeah it applies to all languages
k

Karlo Lozovina

02/02/2021, 2:18 PM
if you want to check how are things done outside of kotlin, maybe see Clojure with it's macro capabilities
n

Nir

02/02/2021, 2:18 PM
Although for some languages the distinction is more blurry e.g. lisps
Yeah, it's a good example but very much the exception not the rule
Most languages are much more like Kotlin then lisp
s

stephanmg

02/02/2021, 2:21 PM
@Karlo Lozovina that’s interesting. I remember I used Clojure way back but didn’t come to use macro capabilities.
k

Karlo Lozovina

02/02/2021, 2:23 PM
macros are interesting, they allow us regular programmers to be more like language designers... with all that it entails 🙂
s

stephanmg

02/02/2021, 2:27 PM
yeah, that’s true from what I read about macros in Clojure. still I not yet felt the urge to add features to a language frankly. but that use-case might appear.
anyway good talk in this thread.
b

Ben Butterworth

02/02/2021, 5:13 PM
Thanks for everyone’s responses, it was very interesting. If I were to summarize, theres not that many places it can go: stdlib or a separate library. Its cleaner to put in a separate library to modularize it, which allows development to take place faster than if it were following the language release cycle since its decoupled. I think fewer people need to get involved since its modularized. I really like what Andrey explained.
n

Nir

02/02/2021, 7:32 PM
@Ben Butterworth What Andrey says are of course a good set of considerations but there are opposite considerations as well that aren't mentioned
one big one is that putting things in the standard library helps standardize it, and helps assure people of quality, and it can help with productivity. In python, I don't need to spend time googling "json parser" or "csv parser", I just use the ones in the standard library, and it's good for 99% of people and use cases. A semi related point is that third party libraries do not work for anything that you want to make a "vocabulary" type. For example, durations (time duraitons) come up in a lot of contexts. If the standard library does not provide a duration type, there is no guarantee that two third party libraries will use the same third party library for their duration type. They may use their own type, or different third party libraries. And if you use two of these libraries, you are now converting between different durations; pretty annoying. This is particularly applicable to error handling which is very universal; it's one of the main reasons why some people (self included) want Kotlin to standardize some kind of non-exception based error handling like Result/Outcome.
In the end you really have to consider each use case on its own, and decide, there is no obviously correct default here. FWIW, I have seen many people make many "doom and gloom" predictions about putting too much in the standard library. And yet, python has been doing this for many many years, and it's just not a problem, at all. In some cases, something goes in the standard library that has shortcomings, and people just eventually stop using it in favor of a third party library, or a new standard library, I can give many examples. And everything in python remains just fine, and I have many issues with python but the large standard library remains a huge pro.
b

Ben Butterworth

02/03/2021, 7:33 AM
Thanks 🙂, thats a clear perspective from the other side as well. Lots of trade offs
g

gildor

02/03/2021, 8:42 AM
I don’t think it’s good solution in case of kotlinx.coroutines, especially showing python as an example The only real thing which probably should be added from kotlinx.coroutines to stdlib is cancellable coroutines, but it’s great that we have it in a separate library to try and make it clear how to add it to stdlib (because now it’s quite complicated)
3 Views