Why is it important that extra programming features coroutin

Question

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

Javier · Answer

Because coroutines library is an implementation of that feature Arrow for example has its own implementation too

Ben Butterworth · Answer

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

Marc Knaup · Answer

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

Javier · Answer

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

stephanmg · Answer

< Ben Butterworth> interesting question

stephanmg · Answer

probably it depends baking into the language might have also benefits

Marc Knaup · Answer

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

stephanmg · Answer

< Marko Mitic> yes I am unsure of the meaning introduced by < Ben Butterworth>

stephanmg · Answer

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

Marc Knaup · Answer

So it s likely located in C++ s stdlib

stephanmg · Answer

I think so

stephanmg · Answer

< 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

Karlo Lozovina · Answer

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

stephanmg · Answer

why it is more epressive

stephanmg · Answer

expressive

Karlo Lozovina · Answer

why is language more expressive if its users can implement feature X while in another language they cant

stephanmg · Answer

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

Karlo Lozovina · Answer

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

Karlo Lozovina · Answer

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

Karlo Lozovina · Answer

still people prefer features as libraries because it feels like that s a better choice

Karlo Lozovina · Answer

and sometimes they need feature Y that s not provided by the language and they can then implement it on their own

Ben Butterworth · Answer

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 gt So the implementation would simply move from kotlinx coroutines to stdlib

stephanmg · Answer

Yeah and it s way more modular

stephanmg · Answer

One does not have to ship a huuuge standard lib

stephanmg · Answer

I like that actually

Karlo Lozovina · Answer

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

Karlo Lozovina · Answer

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

Nir · Answer

Reading this thread I feel like there s two parallel discussions going on

Nir · Answer

Baked into the language doesn t usually mean in the standard library

Nir · Answer

It means in the compiler

gildor · Answer

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 gt 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

Nir · Answer

I don t know if that s what Ben meant or not but there seems to be comments interpreting it either way

stephanmg · Answer

ahh so my C++ threading example might be then correct because it s mainly compiler constraints

Nir · Answer

C++ multithreading is standard library

Nir · Answer

Not core language

stephanmg · Answer

ok sorry i meant Concurrency API

Nir · Answer

What do you mean by that

stephanmg · Answer

but anyway you are right I guess

stephanmg · Answer

Nir · Answer

Yeah it s all stdlib

stephanmg · Answer

I m still a little unclear so baked into language means into the compiler

stephanmg · Answer

seems still like a vague term

Nir · Answer

i don t know if there s an official definition but that s usually what I see

Nir · Answer

Like suspend is baked into the language

Nir · Answer

You can t implement suspend yourself period

stephanmg · Answer

that makes sense

Nir · Answer

Core language vs library is much more important than whether that library happens to be standard or third party

stephanmg · Answer

so what are pros of pulling code into the core language

Nir · Answer

Well you can of course do things that are totally impossible in libraries

stephanmg · Answer

< Nir> could you give an example

stephanmg · Answer

other than suspend

Nir · Answer

Like defining a class

Nir · Answer

Lambdas extension functions reflections

Nir · Answer

Etc

stephanmg · Answer

OK thanks < Nir>

Nir · Answer

A better example is something like string formatting

Nir · Answer

You could do string formatting as a library

stephanmg · Answer

Btw The matters you discussed do not only apply to Kotlin exclusively right

Nir · Answer

E g you could have syntax like format x

Nir · Answer

But you can t do string interpolation as a library

Nir · Answer

The downside is that because it s done in the compiler we can t easily extend or develop another library with the same syntax

Nir · Answer

The upside is we get really really nice syntax

Nir · Answer

Yeah it applies to all languages

Karlo Lozovina · Answer

if you want to check how are things done outside of kotlin maybe see Clojure with it s macro capabilities

Nir · Answer

Although for some languages the distinction is more blurry e g lisps

Nir · Answer

Yeah it s a good example but very much the exception not the rule

Nir · Answer

Most languages are much more like Kotlin then lisp

stephanmg · Answer

< Karlo Lozovina> that s interesting I remember I used Clojure way back but didn t come to use macro capabilities

Karlo Lozovina · Answer

macros are interesting they allow us regular programmers to be more like language designers with all that it entails slightly smiling face

stephanmg · Answer

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

stephanmg · Answer

anyway good talk in this thread

Ben Butterworth · Answer

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

Nir · Answer

< Ben Butterworth> What Andrey says are of course a good set of considerations but there are opposite considerations as well that aren t mentioned

Nir · Answer

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

Nir · Answer

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

Ben Butterworth · Answer

Thanks slightly smiling face thats a clear perspective from the other side as well Lots of trade offs

gildor · Answer

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