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

31–40 of 90 posts

Re: What Color Is Your Function? (2015)

#31

Post by jayd16 »

4bpp wrote: post #26
jayd16 wrote: post #21

Earlier quoted context omitted.

Agreed. Await seems much nicer for the case of some sleep/wait causing subroutine that returns something. var foo = await bar(); vs c1 := make(chan float64, 1) go bar(c1) foo := Sure you have to be in an async method to use await but its really not that bad if you embrace it. Go seems better suited for high throughput message passing.

Isn't there still a key difference there? Inserting the latter snippet in your Golang function does not require you to change anything about the function's definition or calling conventions. From the outside, it continues looking and behaving exactly as any other (synchronous) Golang function. On the other hand, if your JS function contains an await, then it must be made async and every invocation of it must be made…

Oh sure, async/await is more colorful than goroutines but there's a reason async/await exists.

Re: What Color Is Your Function? (2015)

#32

Post by hombre_fatal »

KingOfCoders wrote: post #28

Still we need a language where every function call is async and the runtime decides what to inline.

Looking at my async code, I just don't see how that would make things more clear instead of less clear.

For example, something as simple as:

    const result1 = promise() // start this promise first but don't await it yet.
    // ...
    const results = await Promise.map([promise(), promise(), result1])

Re: What Color Is Your Function? (2015)

#33

Post by hombre_fatal »

benhoyt wrote: post #2

I love this about Go. All functions are simple and synchronous, but if you want to call them concurrently, just "go SlowThing()" and coordinate with a channel. Compare that to the async stuff in C#, Python, etc -- it's bolted on later, and you see double of everything.

Go routines just act like threads. Something you can spawn in any language with the same guarantees. Even C/C++ have channel libraries. Channels just easily introduce complexity and channel-hell which is why they aren't all that popular as abstractions. Even in Go.

Frankly, I have a hard time imagining too many seasoned developers clutching channels to their chest as something superior to async/await. Async code with channels is not simple, you have in-channels, out-channels, and channels-over-channels. It's a pretty niche instrument working best when you only have uni-directional communication in your application.

For example, I've worked on channel code where I'd rather be debugging mutex deadlocks.

Re: What Color Is Your Function? (2015)

#35

Post by speedgoose »

ceronman wrote: post #25
jayd16 wrote: post #21

Earlier quoted context omitted.

Agreed. Await seems much nicer for the case of some sleep/wait causing subroutine that returns something. var foo = await bar(); vs c1 := make(chan float64, 1) go bar(c1) foo := Sure you have to be in an async method to use await but its really not that bad if you embrace it. Go seems better suited for high throughput message passing.

I'm not that experienced with Go, but it seems to me that the equivalent Go code to var foo = await bar(); is foo := bar() Go concurrency is much nicer because it doesn't have colored functions. You can use the same functions and library both synchronously and concurrently in millions of goroutines.

Golang's concurrency can be much more cumbersome in some cases.

    const foo = await Promise.all(randomArray.map(bar));
I would have to google stuff to know where to start for the golang version.

Re: What Color Is Your Function? (2015)

#36

Post by z3t4 »

This article made me angry then I first read it, and now it makes my blood boil. First off there where no colors in JavaScript pre ES6, there where only functions. You can call them first class functions, but those are still functions. A callback is just a function! Then we have side effects, but executing the side effect while returning a promise like in ES6 you are still executing the side effect, even if yo do not call .then() so nothing really changes.

So first you think there is a problem, but there are not any, but by solving the imagined problem you do actually create it. You now have generator functions and "async" (with the async keyword) functions that always returns a promise, and normal functions.

Re: What Color Is Your Function? (2015)

#37

Post by hombre_fatal »

speedgoose wrote: post #35
ceronman wrote: post #25

Earlier quoted context omitted.

I'm not that experienced with Go, but it seems to me that the equivalent Go code to var foo = await bar(); is foo := bar() Go concurrency is much nicer because it doesn't have colored functions. You can use the same functions and library both synchronously and concurrently in millions of goroutines.

Golang's concurrency can be much more cumbersome in some cases. const foo = await Promise.all(randomArray.map(bar)); I would have to google stuff to know where to start for the golang version.

Spoiler: 40 lines of wait group code in Go to implement that.

Re: What Color Is Your Function? (2015)

#38

Post by saagarjha »

z3t4 wrote: post #36

This article made me angry then I first read it, and now it makes my blood boil. First off there where no colors in JavaScript pre ES6, there where only functions. You can call them first class functions, but those are still functions. A callback is just a function! Then we have side effects, but executing the side effect while returning a promise like in ES6 you are still executing the side effect, even if yo do not…

I think you didn’t really understand the argument. The author is not saying that the language lacks first-class functions, in fact he requires it for his real point, which is that async and sync functions are not really compatible.

Re: What Color Is Your Function? (2015)

#39

Post by kjksf »

bcrosby95 wrote: post #4
benhoyt wrote: post #2

I love this about Go. All functions are simple and synchronous, but if you want to call them concurrently, just "go SlowThing()" and coordinate with a channel. Compare that to the async stuff in C#, Python, etc -- it's bolted on later, and you see double of everything.

You're just using the channel as a future. None of this is really problematic at the top level view of things. But when you need to compose libraries or applications that make use of these things - yes, even channels in Go - you can start running into problems. Especially if you don't actually control the process you're running in. This is why promises and async/await really exist. E.g. if you have code you need to f…

A channel can be used as future / promise but that's not what it is and that's not how it's used by majority of Go programs.

Channel is what it says it is: a way to send data between goroutines.

Also, Go works just fine for UI code, out of the box. See https://github.com/lxn/walk for one of many examples.

You just lock main goroutine with runtime.LockOSThread() to its thread and that's your UI thread and marshall code that touches UI to UI thread. Which is the same thing you must do in C# (or any other language). See https://github.com/golang/go/wiki/LockOSThread

Post reply on HN