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 90 posts

Re: What Color Is Your Function? (2015)

#21

Post by jayd16 »

tsimionescu wrote: post #11
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 can actually do the same thing as `go SlowThing() ` in C#, though it has more boilerplate. For example, you can do `Task.Factory.StartNew(() => SlowThing())`. The thing is, Go doesn't have async functions, because it doesn't have await. That is why you don't have colored functions in Go: it doesn't support anything as advanced. Sure, the runtime does really cool things under the hood, but the Go programming model…

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.

Re: What Color Is Your Function? (2015)

#23

Post by philwelch »

jayd16 wrote: post #21
tsimionescu wrote: post #11

Earlier quoted context omitted.

You can actually do the same thing as `go SlowThing() ` in C#, though it has more boilerplate. For example, you can do `Task.Factory.StartNew(() => SlowThing())`. The thing is, Go doesn't have async functions, because it doesn't have await. That is why you don't have colored functions in Go: it doesn't support anything as advanced. Sure, the runtime does really cool things under the hood, but the Go programming model…

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.

Except in Go you could just as easily call:

  foo := bar()
and if bar() is a function that does something annoying or time-consuming before finishing its work and returning the value, it just behaves like a normal, synchronous function call. “Await” is, as TFA explains, syntactic sugar for slapping an async function into behaving like a normal synchronous function call. In Go there is no reason you can’t just write your function calls synchronously in the first place.

Re: What Color Is Your Function? (2015)

#24

Post by jayd16 »

anonymoushn wrote: post #19
jayd16 wrote: post #16

Earlier quoted context omitted.

Sometimes you want to block the main thread, or at least finish what you were doing. With async/await and cooperative concurrency you can be explicit about what will run on a thread. You retain control of the thread until you yield or await. You can ask tasks to complete on other threads or post back to the main thread. You have a lot of control. Its easy to write code without locks that runs concurrently on the main…

You can spawn a goroutine that immediately waits on a channel, so that it will not actually do anything until you want it to. This seems at least as expressive as a single-threaded switch() primitive. I think it can also express the threaded async pattern you want, but I'm not sure.

Are there any popular, idiomatic Go UI frameworks I could explore?

Re: What Color Is Your Function? (2015)

#25

Post by ceronman »

jayd16 wrote: post #21
tsimionescu wrote: post #11

Earlier quoted context omitted.

You can actually do the same thing as `go SlowThing() ` in C#, though it has more boilerplate. For example, you can do `Task.Factory.StartNew(() => SlowThing())`. The thing is, Go doesn't have async functions, because it doesn't have await. That is why you don't have colored functions in Go: it doesn't support anything as advanced. Sure, the runtime does really cool things under the hood, but the Go programming model…

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.

Re: What Color Is Your Function? (2015)

#26

Post by 4bpp »

jayd16 wrote: post #21
tsimionescu wrote: post #11

Earlier quoted context omitted.

You can actually do the same thing as `go SlowThing() ` in C#, though it has more boilerplate. For example, you can do `Task.Factory.StartNew(() => SlowThing())`. The thing is, Go doesn't have async functions, because it doesn't have await. That is why you don't have colored functions in Go: it doesn't support anything as advanced. Sure, the runtime does really cool things under the hood, but the Go programming model…

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 prefixed with await or some other async-wrangling boilerplate, you lose access to language features such as exceptions et cetera.

Golang functions only have one colour. This colour may be closer to "red" than "blue", but at least you never need to concern yourself with this as the consumer of an API, and you can count on the rest of the language having been designed around what is possible with these "purple" functions, as opposed to JS where the situation is that the language provides you with plenty of nice features to structure your code on paper but the design of existing code you need to interface with prevents you from effectively using them.

Re: What Color Is Your Function? (2015)

#27

Post by [deleted] »

anonymoushn wrote: post #19
jayd16 wrote: post #16

Earlier quoted context omitted.

Sometimes you want to block the main thread, or at least finish what you were doing. With async/await and cooperative concurrency you can be explicit about what will run on a thread. You retain control of the thread until you yield or await. You can ask tasks to complete on other threads or post back to the main thread. You have a lot of control. Its easy to write code without locks that runs concurrently on the main…

You can spawn a goroutine that immediately waits on a channel, so that it will not actually do anything until you want it to. This seems at least as expressive as a single-threaded switch() primitive. I think it can also express the threaded async pattern you want, but I'm not sure.

[deleted]

Re: What Color Is Your Function? (2015)

#29

Post by [deleted] »

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…

[deleted]

Re: What Color Is Your Function? (2015)

#30

Post by jayd16 »

philwelch wrote: post #23
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.

Except in Go you could just as easily call: foo := bar() and if bar() is a function that does something annoying or time-consuming before finishing its work and returning the value, it just behaves like a normal, synchronous function call. “Await” is, as TFA explains, syntactic sugar for slapping an async function into behaving like a normal synchronous function call. In Go there is no reason you can’t just write you…

You mean if you rewrite bar so it didn't use a channel?

That's syntactically different though, isn't it? Would the Go runtime lock you to that specific thread and block it or sleep that goroutine and move it to another thread when its no longer sleeping? Maybe in Go there's no difference in those concepts but in many languages certain threads are special. UI threads are often used for event serializiation but beyond that you might have a GL context on a specific thread.

How does Go manage that? How do you protect yourself from the runtime splitting your single thread work at a point you didn't intend? You probably have to make sure you only have a main goroutine that runs in a threaded way (as they do) and pass messages to it.

I can't really find an idiomatic Go UI example so I don't know what the answer is.

Post reply on HN