141–150 of 189 posts
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}
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…
This is one of the most absurd and myopic statements I've seen in a while. Go has a vibrant community because many people chose it, for reasons that are entirely valid. Just as people chose Node.
You're posting with an enormously superior tone for someone that didn't even read the original post (newsflash: they were using a 4 host service cluster).
I've been coding in Node for a couple of years. I find it interesting. But I'm aware that the async model of Node inverts the flow of control, turning code inside out and makes application logic difficult to scrutinize and reason about. Stack traces in traditional multithreaded languages are easy to understand, whereas in Node a stack trace is necessarily filled with unrelated calls - or perhaps no stack at all in th…
Because of the way tasks are scheduled in node.js you can have head of line blocking; i.e. a task that is scheduled to run first can block all the subsequent tasks, the issue that the OP suffered from. You can sometimes reduce this by calling process.nextTick(), but you need to remember that it is only IO is non-blocking in node.js.[1]
[0] https://stackoverflow.com/questions/14409609/does-the-v8-jav...
[1] http://greenash.net.au/thoughts/2012/11/nodejs-itself-is-blo...
I've been coding in Node for a couple of years. I find it interesting. But I'm aware that the async model of Node inverts the flow of control, turning code inside out and makes application logic difficult to scrutinize and reason about. Stack traces in traditional multithreaded languages are easy to understand, whereas in Node a stack trace is necessarily filled with unrelated calls - or perhaps no stack at all in th…
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…
I think I follow. But why do I want general-purpose functions to ever be non-blocking in Go? To me, idiomatic Go suggests that libraries, data structures, business logic, &c is encapsulated in blocking functions, and that concurrency is expressed in glue code.
What I was respond to was this specific sentiment: "With Go it doesn't matter if an operation is blocking or non blocking, that fact can totally be abstracted from the client code." My argument was that that is simply not true. Client code must know the difference between blocking and non-blocking code because it affects the flow of information around the program.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
> What Go does better than Nodejs is a better standard library What is so hard about `require('lodash')`, or `require('moment')`? > true concurrency The trade-off is you get great concurrency without thinking about it. If you are working in Go, you have to start thinking about it as you go. You can always think about it as you go with Node.js if you want, but you don't have to and you will still get quite far. > stat…
async function() { const {data} = axis.get('foo'), arr = ['foo', 'bar', 'baz']; return arr.map(ele => await axis.get(ele)); } I rewrote your async function making it more concise and compact. Isn't advisable not to use «for in» with arrays?
return arr.map(ele => await axis.get(ele));
return arr.map(async ele => await axis.get(ele));
return arr.map(ele => axis.get(ele));
That is, it returns an array of promises of values, not a promise of an array of values like erlich's function.
erlich's example is correct, with the replacement of for-in with for-of.
Edit:
Also, a solution using Array.map() is not impossible:
return Promise.all(arr.map(ele => axis.get(ele)));
I've been coding in Node for a couple of years. I find it interesting. But I'm aware that the async model of Node inverts the flow of control, turning code inside out and makes application logic difficult to scrutinize and reason about. Stack traces in traditional multithreaded languages are easy to understand, whereas in Node a stack trace is necessarily filled with unrelated calls - or perhaps no stack at all in th…
The programming model you are describing is almost exactly the model Go has, it just takes it a step further and allows N:M "green threading", so you can use all your cores.
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…
I think I follow. But why do I want general-purpose functions to ever be non-blocking in Go? To me, idiomatic Go suggests that libraries, data structures, business logic, &c is encapsulated in blocking functions, and that concurrency is expressed in glue code.
The argument to me is that Go advertises itself as being easy to write that concurrent glue code & then fails to provide basic abstractions around it.
Everything you mention about things being expressed in glue code would be easier if Golang provided a modern promises library & holds just as reasonably for other modern languages that do.
The "node requires callback hell" is a red herring because so does Golang (that or blocking code), just it does it at the app layer instead of the framework layer.