https://kotlinlang.org logo
Join Slack
Powered by
Why is it important that extra programming feature...
# announcements
b
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
Because coroutines library is an implementation of that feature. Arrow, for example, has its own implementation too.
b
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
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
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
@Ben Butterworth interesting question
probably it depends... baking into the language might have also benefits
🚫 1
m
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
@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
So it’s likely located in C++’s stdlib
s
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
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
why it is more epressive?
expressive...
k
why is language more expressive if its users can implement feature X, while in another language they cant?
s
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
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
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
Yeah and it's way more modular.
One does not have to ship a huuuge standard lib.
I like that actually
k
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
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
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
I don't know if that's what Ben meant or not but there seems to be comments interpreting it either way
s
ahh, so my C++ threading example might be then correct. because it’s mainly compiler constraints
n
C++ multithreading is standard library
Not core language
s
ok, sorry i meant Concurrency API
n
What do you mean by that?
s
but anyway you are right I guess
n
Yeah it's all stdlib
s
I’m still a little unclear, so baked into language means into the compiler?
seems still like a vague term
n
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
that makes sense
n
Core language vs library is much more important than whether that library happens to be standard or third party
👍 1
s
so what are pros of pulling code into the core language?
n
Well you can of course do things that are totally impossible in libraries
s
@Nir could you give an example?
other than suspend
n
Like defining a class? :-)
Lambdas, extension functions, reflections
Etc
s
OK thanks @Nir
n
A better example is something like string formatting
You could do string formatting as a library
s
Btw.: The matters you discussed do not only apply to Kotlin exclusively, right?
n
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
if you want to check how are things done outside of kotlin, maybe see Clojure with it's macro capabilities
n
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
@Karlo Lozovina that’s interesting. I remember I used Clojure way back but didn’t come to use macro capabilities.
k
macros are interesting, they allow us regular programmers to be more like language designers... with all that it entails 🙂
s
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
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
@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
Thanks 🙂, thats a clear perspective from the other side as well. Lots of trade offs
g
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)
6 Views
Open in Slack
PreviousNext
Powered by