Funny story—
Along with a friend who has at least a decade more development experience, I have been building a cryptocurrency trade execution platform. He started it in Node, and I picked up where he left off not even knowing what a Promise was. Fast forward a year, and after taking a distributed systems course that required me to use Elixir for all the projects I demanded that we abandon Node for Elixir.
I finally escaped Node
51–60 of 181 posts
Re: I finally escaped Node
#52I agree with some points author is making, but overall I wouldn't put them either on Node.js runtime, or Node.js ecosystem. a) Erratic max latency IME Node.js performs well if you are not pushing its limits. If you have a service receiving 25k+ requests per second, you should better benchmark it, regardless of the language. Horizontal scaling should be configured based on the results of the benchmark. b) Cognitive ov…
> You know what's an even worse cognitive overhead? Languages without strong typing, like Elixir. I see this mentioned many times, but when I do my impression (which might be wrong) is that you haven't written Elixir or Erlang for any thing more serious than tutorials or docs examples. Besides, elixir is technically (?) strongly typed - but not statically typed. Regarding async/await, compared to the things you get i…
Green threads are great, right up until the moment you have to interoperate with something written in another language / using another VM. Then it's a mess (see also: Go).
The nice thing about async/await is that, because it's all just a bunch of syntactic sugar over callbacks, any language that supports some kind of callbacks with state, can be mapped to async/await - even C! On WinRT, for example, such interop works across C++, C#, and JavaScript.
This is largely why languages that push this model tend to form rather tightly closed ecosystems, IMO. Which, in turn, leads to their lower adoption - and thus, no particular implementation of green threads can become a de facto standard.
Re: I finally escaped Node
#53Earlier quoted context omitted.
Most people have moved on from ORMs and the like, since most DBs are not SQL anymore and supporting all of the different DB types is just too hard.
"Most DBs" by what metric? If you count them as products, you're probably correct. But I seriously doubt that is true when adjusted for usage - say, number of requests per second, globally, across all deployed databases worldwide. (in fact, I suspect that SQLite would win that contest handily.)
SQLite is in every android phone, it wins by a mile. I'd even go as far to wager that MSSQL instances alone outnumber Mongodb or Dynamo by a good margin.
Re: I finally escaped Node
#54> What you end up with is a paradigm for concurrency that a human can easily map to and reason about. I always feel like I'm thinking about concurrency at the right layer of the stack.
Interesting. Is this a common view in the Elixir community? It's a hard problem to find a good abstraction for and I think it's only really possible to know if it holds up as a good abstraction after a fair bit of use. Can anyone corroborate this perspective? Is there something helpful about the module layer specifically?
Re: I finally escaped Node
#55Funny story— Along with a friend who has at least a decade more development experience, I have been building a cryptocurrency trade execution platform. He started it in Node, and I picked up where he left off not even knowing what a Promise was. Fast forward a year, and after taking a distributed systems course that required me to use Elixir for all the projects I demanded that we abandon Node for Elixir.
>I have been building a cryptocurrency trade execution platform. He started it in Node, and I picked up where he left off not even knowing what a Promise was.
Sounds secure
Re: I finally escaped Node
#56I'm not a node.js programmer by trade, so maybe I have this all wrong, but I thought the main selling point of the language was that it is fast.
The thing is, everything in computer science comes with a tradeoff: the tradeoff in this case seems to be that, in gaining speed, now you are sacrificing a layer of abstraction that would normally be hidden by the operating system.
What I mean by that is that instead of just letting the operating system handle putting a thread to sleep when it blocks, and then waking it back up when it's ready (for example during a database query), now you have to start explicitly handling that blocking yourself in the form of callbacks.
It seems like the author is realizing that maybe that is not really ideal.
Re: I finally escaped Node
#57From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most req…
> tell me a development platform that can run under 100 MB of memory, handle most requests under 50 ms, can spin up a http service in a day or so
This is a strange set of requirements for a platform.
Re: I finally escaped Node
#58From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most req…
ASP.NET Core does all that just fine. Uses ~83 MB of memory when idle but easily handles the rest
Re: I finally escaped Node
#59I'm not a node.js programmer by trade, so maybe I have this all wrong, but I thought the main selling point of the language was that it is fast. The thing is, everything in computer science comes with a tradeoff: the tradeoff in this case seems to be that, in gaining speed, now you are sacrificing a layer of abstraction that would normally be hidden by the operating system. What I mean by that is that instead of just…
Yeah, I think that's not quite right. I think the main selling point of Node has always been that it's Javascript and thus you can use the same language, and people, to do both frontend and backend development. Node is not fast and it's not trying to compete with compiled language in that regard.
Re: I finally escaped Node
#60We went away from node as a backend technology for a bunch of reasons. Here's a list of the biggest pain points: - Lack of a good standard API; compared to environments like Java, C# or Go, node's standard library is significantly sparse. - The tendency for small libraries/frameworks leads to a very high number of third party code with all the problems attached; bigger attack surface, licensing challenges, it's econo…
I would upvote this comment a hundred times if I could. I had got a Node project in my previous gig and I hated it every minute. The team got immensely productive when we migrated it to Golang.
In the times of RESTful APIs and µServices, is there really a need for node? JVM, C#, Elixir, Golang etc provide excellent development experience and are battle tested the way single-threaded Node just hasn't been.