Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What color is your function? (2015)

journal.stuffwithstuff.com

Post reply on HN
Print view View original

21–30 of 63 posts

Re: What color is your function? (2015)

#21

Post by isaacimagine »

Ezku wrote: post #16
isaacimagine wrote: post #9

In previous threads I haven't seen an in-depth discussion of algebraic effects as a solution to this problem, i.e. composing arbitrarily-many 'red' functions. Thoughts?

I’m thinking your reference to composing red functions doesn’t seem congruent with your desire to discuss algebraic effects. Composing arbitrarily many red functions, or blue functions, is a solved problem. (I won’t mention the lingo knowing many in the audience to be allergic.) Composing functions with heterogenous, or completely arbitrary, colors is much less so. That’s what the article is about, too, is it not - c…

By 'red' I was referring to anything effectful, whether that be concurrency, IO, state, or otherwise. Composing any one effect is a solved problem (e.g. monad); composing arbitrarily many effects is a lot harder. Recent languages like Koka describe effects over the free monad; because they are described over a single monad, and this single monad composes, effects compose.

I am by no means an expert in this area, but I hope this clarifies the intent of my original comment. What transformations and/or constraints exist for composable heterogeneous effects?

Koka: http://koka-lang.org/

Re: What color is your function? (2015)

#23

Post by ddek »

quickthrower2 wrote: post #8

You can call an async from a non async function of course. You just can’t return it’s result synchronously. Nitpick aside, I have got to the point where I care little! Every language has its boilerplatish things, be it Elm’s JSON parsing, GO’s “if (err != nil)” or Haskells myriad language extension declarations. I don’t think asyncs on a chain of functions, or converting a callback function into a promise based one i…

The issue is if you need to add an async call to an existing synchronous code base. If you introduce async in this situation, you’ll probably need to rewrite a huge chunk of your code to allow it. To prevent inconsistencies, this leads to a practice where programmers return promises or tasks by default, even in synchronous functions; which can cause a myriad of problems beyond simply looking really ugly.

Re: What color is your function? (2015)

#24

Post by dkdbejwi383 »

vermilingua wrote: post #17

I might be showing my inexperience here, but my understanding of async/await and promises in JS is that they create threads under the hood to solve the problem the author is talking about. I'm afraid I just don't quite understand why async/await don't solve the problem and instead sweep it under the rug, could someone explain it?

If you want to use ‘await’, the calling scope needs to be an async function, which means any other function which calls the now async caller also needs to be async (well, if you need the resolved value. You can just orphan promises but then you’ll probably have unintended consequences). You’re forced to propagate it up the chain, which one may argue is a leaky abstraction.

Re: What color is your function? (2015)

#25

Post by jillesvangurp »

Kotlin's co-routines are pretty nice. Technically it uses colored functions but because it is statically compiled language, there is no chance of doing this wrong as that would simply be a compile error.

The way suspend functions work in Kotlin is that it is essentially syntactic sugar for async await where calling a suspend function implicitly awaits it; which you can only do in a so-called CoroutineScope (for example another suspend function).

It's actually very similar to what go does. Instead of go foo(), Kotlin makes you write something like CoroutineScope(CoroutineName("myscopename")).launch { foo() }.

It's actually very similar to what go does as well. Instead of go foo(), Kotlin makes you write something like CoroutineScope(CoroutineName("myscopename")).launch { foo() }

The difference is that a coroutine scope is a thing with a name and some behavior. For example, you can control how the coroutine is dispatched for example. Some dispatchers might do everything on the main thread. Other dispatchers use thread pools. Very useful if you are integrating some blocking IO framework where you don't want to block the main thread.

There's more to it but it's a pretty well designed solution for what is a tough problem space.

Re: What color is your function? (2015)

#27

Post by Joker_vD »

BiteCode_dev wrote: post #18

In Python at least, you can easily call an async function from a sync function: result = asyncio.run_until_complete(func) Also, having explicit async/await are a wait to tell you: here are the point in your code that have something doing unreliable side effects down there. You can then use this information to: - move that code and group it, so you get the rest of the code sansIO style - put that in a try/except, beca…

You can do that in pretty much every language, it's just that in most of implementations, blocking on an async call can easily dead-lock, .NET is particularly notorious in this regard: you call GetResult(), the scheduler tries to schedule the task to the thread that have just called the GetResult() on it -- and this thread is now deadlocked, because it waits for itself. But since a threadpool has many threads, such degradation takes some time until the whole of the system deadlocks, and it's not even guaranteed to happen: the task scheduling in .NET is very convoluted.

Re: What color is your function? (2015)

#28

Post by jasode »

The different philosophies of "explicitly annotate async functions" vs "implicit async" vs "create os threads with polling" etc will always continue because they all have tradeoffs.

So, the "simplification" or a "unification" of a concurrency model always comes at a cost that some programmers don't want to pay. Whenever you see, "Language has solved the color problem so it's not an issue." -- the reflexive skepticism should be, "At what price, and do I want to pay it?"

I think it's instructive that Rust had a clean-sheet start to design a new language and so far, they've rejected Go style "channels" as Rust core syntax and instead, adopted the async/await paradigm. You don't have to program in Rust to get the gist of the following previous comments about their thought process:

https://news.ycombinator.com/item?id=21475154

https://lobste.rs/s/bfsxsl/ocaml_4_03_will_if_all_goes_well_...

https://lobste.rs/s/y3fsrm/what_is_zig_s_colorblind_async_aw...

Re: What color is your function? (2015)

#29

Post by messe »

BiteCode_dev wrote: post #19
jedisct1 wrote: post #7

Zig’s functions are colorblind: https://kristoff.it/blog/zig-colorblind-async-await/

That's an interesting design, it seems like the best of both worlds. Zip has really neat ideas. I wish it didn't go the "case as you want road" though.

> I wish it didn't go the "case as you want road" though.

That's almost inevitable given its desire for close interop with C (as in, the Zig compiler includes a C compiler and can directly #include C headers).

The standard library has a relatively consistent case style though, which the Zig guide recommends.

Re: What color is your function? (2015)

#30

Post by XorNot »

jedisct1 wrote: post #7

Zig’s functions are colorblind: https://kristoff.it/blog/zig-colorblind-async-await/

This doesn't seem as useful as it implies though with the proviso statement that you can wind up with deadlocks in sync mode that you wouldn't have in async mode. Sounds like more of a footgun you can hand yourself.
Post reply on HN