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

The Way of the Gopher: Making the Switch from Node.js to Golang

medium.com

Post reply on HN
Print view View original

101–110 of 189 posts

Re: The Way of the Gopher: Making the Switch from Node.js to Golang

#101

Post by sagichmal »

Lukasa wrote: post #95
vishbar wrote: post #58

Earlier quoted context omitted.

Go isn't just a threaded concurrency model, it uses an M:N greenthreads pattern. Also, when you say that Go I/O operations are blocking, it is true that they'll logically block a goroutine. However, under the hood, it uses the same libuv-style async IO (or IOCP on Windows) that Node does. An operating system thread doesn't get blocked; the goroutine is "shelved" and woken up again when the I/O is complete. It accompl…

Honestly, I think the distinction between M:N threading and straight OS threading is pretty minor. It grants some advantages to the language runtime: it can control the stack size, for example. But in terms of how it affects the development style and what kinds of bugs it encourages/discourages I don't think it dramatically differs from the OS threading model.

It is categorically different. OS threads are orders of magnitude more expensive, which makes them a nonstarter for most problems that are a good fit for lightweight conceptual concurrency.

Re: The Way of the Gopher: Making the Switch from Node.js to Golang

#104

Post by Lukasa »

jerf wrote: post #82
Lukasa wrote: post #57

Earlier quoted context omitted.

> The caller can make function "non-blocking" by wrapping the call in a goroutine themselves. Sure, but if they want the return value then either they need to construct the Future-y wrapper I just described or they need to assemble it together in a collection of other function calls wrapped inside a function that itself is either Future-y or uses a long-lived channel to communicate results. It is not novel to build u…

The core problem here is that the Node community invented/popularized a connotation of "blocking" and "non-blocking" that is excessively event-loop-specific. The important difference in their connotation is that code that blocks blocks the whole OS process . The conventional meaning of the term referred just blocking the running thread. In normal Go, nothing is blocking in the Node sense. (Oh, if you put your mind to…

I agree with this entirely. As I said many times before, I like Go and I like its approach to concurrency.

All I'm trying to do is to make sure that people who make bold claims about abstracting away blocking code aren't misleading others: when calling other code you should always be aware of how it interacts with the flow control of your program.

Re: The Way of the Gopher: Making the Switch from Node.js to Golang

#105

Post by skewart »

madgar wrote: post #78
Fluda3 wrote: post #41

Earlier quoted context omitted.

Why on earth are both of you getting downvoted so hard? I am so tired of reading hacker news articles with comments that are so pushed down because of subjective opinionated voting that is so obviously skewed towards one personality type. I have so many thoughts and opinions I want to contribute to these discussions but I have zero confidence it will fit within this type of environment that's been created. It really…

pg believes downvoting is an appropriate expression of disagreement: https://news.ycombinator.com/item?id=117171

That's fine. I think most of the HN community disagrees with him on that.

Given the way HN is designed (comments are ranked, low scores get grayed out, user karma scores are visible) if people downvote to express disagreement it would worsen the experience of reading comments, and, I suspect, the overall conversation.

Re: The Way of the Gopher: Making the Switch from Node.js to Golang

#107

Post by sagichmal »

spullara wrote: post #36

Switching from one essentially single threaded language to another wasn't likely to solve your issues. Instead of Go you could have chosen any JVM language or even C++ and had similar success.

Go is not a single threaded language.

Re: The Way of the Gopher: Making the Switch from Node.js to Golang

#108

Post by Lukasa »

sagichmal wrote: post #101
Lukasa wrote: post #95

Earlier quoted context omitted.

Honestly, I think the distinction between M:N threading and straight OS threading is pretty minor. It grants some advantages to the language runtime: it can control the stack size, for example. But in terms of how it affects the development style and what kinds of bugs it encourages/discourages I don't think it dramatically differs from the OS threading model.

It is categorically different. OS threads are orders of magnitude more expensive, which makes them a nonstarter for most problems that are a good fit for lightweight conceptual concurrency.

It is not categorically different.

As I said above, green threading has advantages over OS threading, but they behave exactly the same in terms of design patterns and potential bugs.

This is what I was getting at when I said "not that different": compared to the difference between event-loop concurrency and threaded concurrency, M:N green threading is basically just a subcategory of threading.

Re: The Way of the Gopher: Making the Switch from Node.js to Golang

#109

Post by Ericson2314 »

erlich wrote: post #25
Ericson2314 wrote: post #20

Not gonna lie, one shitty language for another, lol.

What do you use?

But to answer the question, languages with (at least) type parameters and no data races (without using escape hatches). (Hint: that includes, but is not limited to, Rust).

Re: The Way of the Gopher: Making the Switch from Node.js to Golang

#110

Post by crzwdjk »

bitwize wrote: post #80
fooyc wrote: post #69

Earlier quoted context omitted.

Care to explain?

Two iron-clad rules of data processing: * All data has a type * All I/O is asynchronous and interrupt (event) driven At its inception Unix doubled down on stupid, first by encouraging data to be stored and migrated in the form of untyped text streams, which require ad-hoc parsing and unparsing logic at the endpoints; and secondly by failing to provide asynchronous I/O primitives to user space. POSIX later provided an…

> you could even put the process to sleep until pending I/O is completed and have it take up no CPU during this time. Instead what people do is burn CPU cycles in select/poll loops

That's what select() does though: you give it a timeout, and it goes to sleep until either an fd becomes ready or the timeout expires. As an example, the X server on you typical linux laptop uses select() on a whole bunch of sockets, one for each client, and it both has good enough latency to be interactive, and doesn't burn a lot of CPU doing so. Is this the most convenient programming model for this? Probably not. And of course it still has the issue that a long-running function can delay your getting back into the select loop.

Post reply on HN