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

181–189 of 189 posts

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

#181

Post by kasey_junk »

fooster wrote: post #97
kasey_junk wrote: post #81

Earlier quoted context omitted.

He is speaking to the idea that you don't need to care about whether a function blocks or not. It's simply untrue (I'd go further and say if its untrue in all languages but that's a digression). To have an abstraction where you really don't care about blocking or not you need promises/futures. Go's futures are bad. Real bad. If you don't want the function to be non-blocking then you are fine with either method signat…

> To have an abstraction where you really don't care about blocking or not you need promises/futures. Go's futures are bad. Real bad. Please explain.

Well it's possible I over stated the necessity for futures as their might be other abstractions that allow you to compose concurrent/non-concurrent systems in a way that is transparent to the api. Its just one of the easier ones to reason about. That said, I don't believe concurrency should be transparent to the api, rather it should be front and center to it.

As for the go futures being bad, channels generally are a bad concurrent queue (contended, lack basic abstractions, etc) and using a single item queue as a future isn't in and of itself bad, but does mean you can't optimize for different usages that futures might have over message passing queues.

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

#182

Post by [deleted] »

cryptica wrote: post #12

I have read so many articles which incentivize switching from Node.js to Go and every single one of them (this one included) blabber on about the Node.js event loop becoming congested - This is completely misguided - It only shows that the engineer didn't understand the problem. A single Node.js instance runs its business logic in a single process. A single Go instance can run its business logic in multiple processes…

[deleted]

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

#183

Post by pacapaca »

rgbrgb wrote: post #139
forgettableuser wrote: post #65

I'm disappointed by the overall tone here. It's as if this were some kind of failure that everybody is piling up on. - She made three passes to fix the existing code base. - After that didn't work, with the CTO's involvement, this Go solution was devised. - It took only 2 weeks to ramp up with Go and build a replacement that solved the problem. - The number of instances needed dropped from 4 to 2 This sounds like a r…

I think the disappointment here is that the OP seemed not to understand the root cause of the problem and implemented a solution in a different language (load balanced worker pool) that could have also worked in the original language without a total rewrite. Then the new language is trotted out as the savior. It sounds like the file fetch workers and request handlers were running on the same process, so the longer-ru…

This.

The author just doesn't know how to approach the problem and copied a solution, which happened to be in go.

Nothing wrong with that. Just don't try to pass it a success story or as an excuse to bash a language.

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

#184

Post by bitwize »

wtbob wrote: post #175
bitwize wrote: post #80

Earlier quoted context omitted.

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…

> 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 I tend to agree with you here: it'd have been better had Unix offered a typed abstraction over byte streams, but OTOH its approach really was a Worse is Better deal. Building a large set of tools which can deal with t…

> I thought that select/poll blocked, but it's been a long time since I did anything low-level like that, so I could be wrong.

Well, yes. That's just the problem. ALL I/O ops in Unix block. Even the ones on O_NONBLOCK fds, which simply read or write -- blockingly -- until the underlying kernel buffer is full/empty, then return.

You don't have the option to request I/O, do some processing, and then wait until the I/O completes. If you want to interleave processing with I/O you have to buzz in a select loop, doing your I/O and processing in tiny explicit chunks. Or spawn subprocesses to do I/O, leadibg to more complexity and confusion.

The facilities in the Windows kernel for I/O are strictly more robust and flexible than what Unix (eve Linux and BSD with kqueue/epoll) provides. The designer of the Windows kernel, Dave Cutler, also designed VMS, knew what real-world I/O requirements were, and famously mocked the way Unix handles I/O.

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

#185

Post by bitwize »

prlin wrote: post #163
bitwize wrote: post #80

Earlier quoted context omitted.

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…

For 1) how do other systems handle data being stored and passed between processes?

At a very basic level -- separate handling of text vs. binary. In some operating systems, some files were record-oriented and some were not, allowing the kernel to optimize record access in a database file, for instance. The Burroughs large systems used the disk as a backing store for objects in main memory, which were typed (in proto-OO fashion) and some of the type constraints were enforced at the hardware level. For instance it was impossible to execute a word tagged as "data".

One feature that was implemented in the Amiga OS, BeOS, and just about nowhere else is the concept of datatypes. Third-party software could register OS-wide readers and writers for their file formats, allowing files of that type to be consumed or produced by any application.

PowerShell lets you construct pipelines of typed objects with fields and methods, not just untyped dumb text.

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

#186

Post by jen20 »

cryptica wrote: post #12

I have read so many articles which incentivize switching from Node.js to Go and every single one of them (this one included) blabber on about the Node.js event loop becoming congested - This is completely misguided - It only shows that the engineer didn't understand the problem. A single Node.js instance runs its business logic in a single process. A single Go instance can run its business logic in multiple processes…

"A single Node.js instance runs its business logic in a single process. A single Go instance can run its business logic in multiple processes."

Ummm, both of them run in exactly one process, this is how operating systems work. Go can do it's n-m scheduling across multiple _threads_ sure, but threads are not processes (unless as an implementation detail of an OS). If you are running lots of instances of Node, that is a different thing.

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

#187

Post by touristtam »

noir_lord wrote: post #96
romanovcode wrote: post #59

2010 - Making switch from PHP to Ruby 2013 - Making switch from Ruby to Node 2016 - Making switch from Node to Go 2019 - Making switch from Go to {hype}

Still using PHP (and Python and some other stuff) in 2016. I make it a rule to only jump on the new bandwagon when I know it's not going to explode in 3 months and currently isn't on fire.

Go has been out for quite a while now, so I'd say it is pretty safe to try it out if you feel like it. I wouldn't swap PHP for Go personally.

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

#188

Post by skybrian »

jdd wrote: post #178
skybrian wrote: post #119

Earlier quoted context omitted.

A big advantage for Go is that the standard library has been stable since 1.0 and there are no plans for breaking changes. This appears not to be true for lodash.

Lodash introduces breaking changes in major version bumps (following semver). So upgrades are optional and not pulling the rug out from underneath the feet of devs. Major releases allows the project to make corrections and avoid carrying around years of baggage.

Yes, that's usually the best strategy for most of us.

But a standard library is a little different due to the sheer number of dependencies and level of coordination needed to upgrade them all. Go got it mostly right the first time, and the lack of churn is a major advantage.

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

#189

Post by daveroberts »

rgbrgb wrote: post #139
forgettableuser wrote: post #65

I'm disappointed by the overall tone here. It's as if this were some kind of failure that everybody is piling up on. - She made three passes to fix the existing code base. - After that didn't work, with the CTO's involvement, this Go solution was devised. - It took only 2 weeks to ramp up with Go and build a replacement that solved the problem. - The number of instances needed dropped from 4 to 2 This sounds like a r…

I think the disappointment here is that the OP seemed not to understand the root cause of the problem and implemented a solution in a different language (load balanced worker pool) that could have also worked in the original language without a total rewrite. Then the new language is trotted out as the savior. It sounds like the file fetch workers and request handlers were running on the same process, so the longer-ru…

The first result from Google for nodejs worker pool leads to this project: https://github.com/jeffmo/node-worker-pool

The project has only 9 stars on GitHub. While it might be a perfectly fine solution that fixes OP's problem, it certainly doesn't inspire confidence as a battle-tested production-ready library. On the other hand, worker pools and Golang go together very naturally.

Post reply on HN