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

What Color Is Your Function?

journal.stuffwithstuff.com

Post reply on HN
Print view View original

71–80 of 153 posts

Re: What Color Is Your Function?

#71

Post by bcantrill »

sbov wrote: post #46
Nilzor wrote: post #34

His solutions is threads ? Really? Has he read no history? There are problems with threads. That's why async I/O is hot right now. Threads is a limited resource. Threads are expensive to create and dispose. Context switches are espensive. Threads must be synchronized. Threads can have race conditions. Good rant, but I didn't expect him to serve such a shallow conclusion after a solid and insightful introduction.

He is talking of threads as an abstraction. Not operating system threads, more like green threads. Different languages call it different things, so I'm fine with the word thread. He even explains that he doesn't mean operating system threads, so your response doesn't make complete sense to me. I've always wondered why Joyent built Node.js when they already used Erlang. I've tried to research it but there seems to be…

Well, we weren't using Erlang much (and had written very little, if any). And while it's unclear if it's related to Erlang or not, over time our Erlang-based systems have been ripped out of our stack because of their failure to meet our production needs. In particular: Erlang-based systems are fine when they're fine, but undebuggable when they're not. While JavaScript might not be known for its observability, we have been able to advance the state of the art there considerably[1]; at this point there is no question that node.js is much more observable and debuggable in production than Erlang.

[1] https://www.joyent.com/developers/node/debug

Re: What Color Is Your Function?

#72

Post by utunga »

jenius wrote: post #54

So I've been writing javascript full time for a couple years at this point, client, server, and open source, and what I have adopted is coercing everything into promises, which I suppose would be the author's way of saying making everything red. If you have something that is not async mixed in with something that's async, you can still add it to the promise chain and it will resolve right away. If you have a library…

I agree. I think that there are two things that are missed out from the this article.

1. Programmers are lazy and will waste cycles like crazy around IO if given a chance. Core library async get's them thinking in red mode but it also get's them actually thinking in ways that allow the overall app to usefully get on with other things. Go sounds like it might be a nice exception to this but I'm not familiar enough to comment.

2. He kinda skips over the fact that threads are really really hard to work with and test (I immediately think about wasting time with race conditions that are just about impossible to reproduce or fix). Node.JS style continuation hell has the advantage of being a model that can actually be understood and made to work reliably in a way that threading, in theory can, but in practice cannot.

Re: What Color Is Your Function?

#73

Post by Nitramp »

tel wrote: post #10

We can massively generalize this by calling "blue" "pure" and "red" "impure". The end result is essentially Haskell (but you can take it much further, too!). --- There's something horrifyingly restrictive about having merely (blue -> pure, red -> impure), though. All "blue" functions behave roughly the same (e.g., very, very nicely and compositionally) but "red" functions come in many classes: async, stateful, except…

Effect Typing and Monads are yet another colour for the lipstick you put on the pig. You still have non-composability (i.e. the async monad spreads through your code), you still have the complexity, you still don't have proper tracebacks without special runtime support, and you still have the inefficiency that Bob didn't actually mention (unwinding all those stacks all the time).

Languages with threads (Java, C#) don't quite solve the problem as their threads have other disadvantages, e.g. creating too many threads causing contention, though it's much less of a problem than people make it to be.

Go actually completely removes the problem - you don't get a nice tool to pack the problem into boxes more easily, you don't get a different fancy colour for your lipstick, you just don't have the problem at all - you wouldn't know it existed was it not for those other languages.

There might be a deeper lesson here about good, pragmatic engineering vs awesome computer language geekery.

Re: What Color Is Your Function?

#74

Post by StrykerKKD »

munificent wrote: post #50
StrykerKKD wrote: post #26

What about isolates in Dart? I mean isolates are isolated processes, which also can be a thread and they also can communicate with each other.

Unfortunately: 1. Isolates can only communicate with each other using asynchronous method calls. So even though you can move some work to another isolate, you can't block waiting for it to complete, so your function still has to be red. 2. Isolates are very limited in what you can send between them, which makes then not very useful in practice for much of anything.

But waiting is non-blocking right? It means that we can just make one isolate's role to wait for all other isolates to complete.

For me the bad part of "red" functions is that testing is harder for it or I just suck at it.

Re: What Color Is Your Function?

#75

Post by mmphosis » 

  POLLIT
      CMP $C050
      BNE POLLIT
It's not a function, it's a procedure. It doesn't need to return anything, it produces an effect. Interrupts will break it.

   await until an as yet indeterminable time in the future

Re: What Color Is Your Function?

#76

Post by Guvante »

Nitramp wrote: post #73
tel wrote: post #10

We can massively generalize this by calling "blue" "pure" and "red" "impure". The end result is essentially Haskell (but you can take it much further, too!). --- There's something horrifyingly restrictive about having merely (blue -> pure, red -> impure), though. All "blue" functions behave roughly the same (e.g., very, very nicely and compositionally) but "red" functions come in many classes: async, stateful, except…

Effect Typing and Monads are yet another colour for the lipstick you put on the pig. You still have non-composability (i.e. the async monad spreads through your code), you still have the complexity, you still don't have proper tracebacks without special runtime support, and you still have the inefficiency that Bob didn't actually mention (unwinding all those stacks all the time). Languages with threads (Java, C#) don…

Go seems to have solved the IO problem, but what about the general asynchronous issue? How do you handle calling a function several thousand times on dozens of threads and combine the results?

Re: What Color Is Your Function?

#77

Post by rntz »

Nitramp wrote: post #73
tel wrote: post #10

We can massively generalize this by calling "blue" "pure" and "red" "impure". The end result is essentially Haskell (but you can take it much further, too!). --- There's something horrifyingly restrictive about having merely (blue -> pure, red -> impure), though. All "blue" functions behave roughly the same (e.g., very, very nicely and compositionally) but "red" functions come in many classes: async, stateful, except…

Effect Typing and Monads are yet another colour for the lipstick you put on the pig. You still have non-composability (i.e. the async monad spreads through your code), you still have the complexity, you still don't have proper tracebacks without special runtime support, and you still have the inefficiency that Bob didn't actually mention (unwinding all those stacks all the time). Languages with threads (Java, C#) don…

Go's "good, pragmatic engineering" solution to the problem - lightweight threads, channels, and the communicating sequential processes model - is built on the back of decades of academic research, including programming languages research.

And now for some computer language geekery:

Go solves one "code color" problem (concurrency/asynchrony), by hard-coding the solution into the language. Go programs are written in a particular monad (the "Go" monad, if you will), and so have one color. Indeed, monads originally arose in the study of the semantics of imperative languages; to be imperative is to be inside a particular monad. This is exactly the "async monad spreading through your code" problem taken to its logical conclusion: just put everything in the same monad!

This hard-coding solution has very concrete advantages. For one, you don't need to think about separate colors and how to transition between them, combine them, define them, etc. (IOW, monads are complex; by picking one, you reduce cognitive load.) For another, it's easier to optimize your implementation and tooling for that monad (lightweight threads, useful tracebacks).

But PL academics aren't satisfied with this solution, because it only solves one color problem, and it solves it non-composably: you can't put the solution in a library, you have to invent a whole new language for it. That's the holy grail (some) PL research is chasing. It's a question of concrete benefits in the here-and-now versus abstract benefits in the hopeful-future. But it pays to remember that today's concrete benefits are yesterday's green-field research.

Re: What Color Is Your Function?

#78

Post by totony »

jakobegger wrote: post #65
totony wrote: post #57

You can always make a function that sync all async operations: sleep until a global variable is changed by the callback. A pain, but still not that bad.

Yes, I've used a similar technique myself; however I consider it only a last resort. But doesn't that require your language to have threads? Is it possible to do this in eg. Javascript?

There is no sleep call that i know of in javascript, but you are right it depends on the language and its implementation of sleep.

Edit: although you could emulate a sleep call by setting a (pediodic) timeout

Re: What Color Is Your Function?

#79

Post by seanmcdirmid »

adrusi wrote: post #60

A lot of commentors are mentioning that this is just a specific case of effect typing. Haskell and monads have been brought up as an example of effects typing, but I'd like to present another example that more closely resemble familiar static type systems. Nim[1], at least at one point (I'm looking at the current manual and can't find it documented), had support for tagging functions with a pragma and the compiler wo…

Also, what about Koka ?

http://koka.codeplex.com/ and http://research.microsoft.com/en-us/projects/koka/

From the latter:

> The Koka project tries to see if effect inference can be used on larger scale programming. The language is strict (as in ML), but seperates pure values from side effecting computations (as in Haskell). Through the effect types, there is also a strong connection to its denotational semantics, where the effect type of each function has a direct translation to the type signature of the denotational function.

Re: What Color Is Your Function?

#80

Post by seanmcdirmid »

drostie wrote: post #43
Nilzor wrote: post #34

His solutions is threads ? Really? Has he read no history? There are problems with threads. That's why async I/O is hot right now. Threads is a limited resource. Threads are expensive to create and dispose. Context switches are espensive. Threads must be synchronized. Threads can have race conditions. Good rant, but I didn't expect him to serve such a shallow conclusion after a solid and insightful introduction.

Since he's a Go fan, he might prefer lightweight threads running in an event loop rather than real threads with their context-switches. Moreover his concern is syntactic , not semantic: so maybe he'd like something which "looks thread-like" but "complies-to-CPS" too. Some Microsoft engineers are working on a nice solution to the thread-race-condition problem with a somewhat different approach: pretend your threaded e…

If you are interested in concurrent revisions, you might also be interested in Glitch:

http://research.microsoft.com/en-us/people/smcdirm/managedti...

In contrast to Burckhardt et. al's work, Glitch re-executes computations to reach a fixed point (logging side effects so they can be rolled back along the way). This paper compares the various approaches in solving this problem (including concurrent revisions, but also a few others):

http://research.microsoft.com/pubs/211297/onward14.pdf

Post reply on HN