Live data from Hacker News

I finally escaped Node

acco.io

111–120 of 181 posts

Re: I finally escaped Node

#111
post #43
post #19

We 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…

How do you feel about the impact on developer productivity after migrating to Java + Spring Boot? I haven't used Java in a long while and every time that I try to come back to it, I get driven away by the difficulty and complexity to do simple things (thinking of annotations, dependency injection, complicated design patterns). It feels like an effort of one hour of Node or Python programming (or even Go) would take 1…

This is why choosing the right language for the job is so important.

I know PHP has a bad reputation, but I personally think it offers an excellent middle ground for web projects. It has some great frameworks which have been used at scale while not having all the complexity and rigidness of Java.

As a dev that's used Java, PHP and Node in the past I perfer working on PHP and Node projects because I feel far more productive and less constrained, but I can certainly appreciate why a larger corporate project might choose Java.

Arguing about the perfect language seems pointless without some idea of the requirements.

Re: I finally escaped Node

#112
post #20

From 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…

Pretty sure all major stacks including php/python/ruby can get good performance. Having one good devops person is way more important than what language you pick nowdays.

Re: I finally escaped Node

#113

> 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 corro…

Yes.

When I open a module I haven't seen before, and the first line that I read is:

    use GenServer
I immediately know how this module behaves in terms of (distributed) concurrency. If I can find where this module is started, I also know how it handles when things go wrong (via supervision trees).

GenServer supports three ways of communicating:

    * call -> handle_call (sync)
    * cast -> handle_cast (async)
    * send -> handle_info (async system messages, signals etc)
Here's an example:

    def send_greeting(pid, greeting, from) do
      GenServer.call(pid, {:receive_greeting, greeting, from})
    end

    def handle_call({:receive_greeting, greeting, name}, sender, current_state) do
      IO.puts greeting
      {:reply, "Hello #{name}!", current_state}
    end

    ------------------------

    {:ok, mikes_computer} = Greeter.start_link(:mike)

    response = Greeter.send_greeting(mikes_computer, "Hello Mike!", "Joe")

    IO.puts response
    > "Hello Joe!"
There's more ways to implement concurrency than by GenServers, but it's the combination of GenServers and Supervisors that sets the BEAM and OTP a head above everything else (in this very specific domain of soft realtime distributed servers).

Re: I finally escaped Node

#114
post #94

It’s really hard to read such posts. The tool is only as good as the contributor, that’s all there is. Great things were built in all languages and frameworks. For god sakes, stop blaming the tool by doing naive comparisons with other languages/framework. Nothing’s perfect, that’s a given, but these kinds of post smells so much like entitlement. You don’t need to trash your previous framework/language and discourage…

I get where you're coming from - the post meanders around some topics every programmer has to learn by hard experience, such as the value of being able to reason about code / systems and the importance of data structures.

That said my feeling is Node gives you multiple pump action shotguns you can easily shoot yourself in the foot with. For example https://nodejs.org/en/docs/guides/dont-block-the-event-loop/

> One common way to block the Event Loop disastrously is by using a "vulnerable" regular expression.

If you're leading an engineering team, just this should be giving you panic attacks every time you hire someone new into the team.

What makes this worse is it's very hard to detect problems at scale, if you missed it in code reviews. If you have one "vulnerable regex" in your event loop that only exposes itself on certain request inputs, it means that only every now and again - when given "bad input" - it's going to block the event loop.

But then how to you detect issue? It's likely going to manifest itself first in _other_ requests that got blocked taking an excessively long time to respond.

From an operational point of view, that's a nightmare scenario. Every now and again you're going to see slow requests in your logs but when you dig into it you find no problems. And that's going to make you very uncertain on how you're doing when it comes to scaling up; instead of a gradual slow down across all requests, you're going to see erratic spikes and jams.

...which actually occurs to me it's not unlike how traffic jams occur - https://www.youtube.com/watch?v=azmcu1cn2vg - https://traffic-simulation.de/

Re: I finally escaped Node

#115

Earlier quoted context omitted.

About lack of standard library: I don‘t personally work with node for the backend but typescript/javascript in the browser. And I think what is meant is something like LINQ in C# (all kinds of functions you can apply on enumerables/arrays), some basic DateTime library (how to add two dates in JS? How to get the diff of two dates in days or hours in JS? Both are 1 liners in C#) and maybe some more stuff for string mut…

It's a one liner if you use Day.js. It's makes no sense to include this functionality in Node.

I think others think differently https://tc39.es/proposal-temporal/docs/

Re: I finally escaped Node

#116
post #99

In some years: I escaped Elixir. Use the right tool to get the sht done.

So true. People pick new stacks all the time and then complain when after 10 years it's boring and there's shinier or more suitable tools out there. Now Node wouldn't be my first choice but I'm sure it's good enough for most purposes, easy to find people to hire etc. There's absolutely no reason to do a rewrite to java imo. I don't buy the "because types" argument.

Re: I finally escaped Node

#117

Javascript these days is a very productive language, especially with Typescript. Node however, with its lack of a remotely passable standard library, is not doing it justice. The async await is amazing and top level await works just fine in a browser console. The fact that node still has it behind a flag is... I mean, they surely have their reasons and I don't know enough to question the decisions of the maintainers,…

I think the author's argument wasn't that JS was a 'productive' language but that it was an overall poorly designed and bad language.

So my argument is that a significant portion of the poorly designed part comes from node.

It's also not a bad language. It's okay for its main purpose: Creating web applications. If people start using it to write distributed systems, async/await won't save you from any troubles you might have.

Next.js is a perfect example for what JS is good for. However, the super lacking standard library frustrates me to no end.

Re: I finally escaped Node

#118

Earlier quoted context omitted.

About lack of standard library: I don‘t personally work with node for the backend but typescript/javascript in the browser. And I think what is meant is something like LINQ in C# (all kinds of functions you can apply on enumerables/arrays), some basic DateTime library (how to add two dates in JS? How to get the diff of two dates in days or hours in JS? Both are 1 liners in C#) and maybe some more stuff for string mut…

It's a one liner if you use Day.js. It's makes no sense to include this functionality in Node.

What makes the Date constructor a good candidate for the standard library but not the aforementioned methods? Not everyone knows about Day.js, you had to learn that at some point. Why Day.js instead of Moment or Luxon or Date-Fns? There's a lot of cognitive value to having a fully featured standard library.

Re: I finally escaped Node

#119

Earlier quoted context omitted.

About lack of standard library: I don‘t personally work with node for the backend but typescript/javascript in the browser. And I think what is meant is something like LINQ in C# (all kinds of functions you can apply on enumerables/arrays), some basic DateTime library (how to add two dates in JS? How to get the diff of two dates in days or hours in JS? Both are 1 liners in C#) and maybe some more stuff for string mut…

It's a one liner if you use Day.js. It's makes no sense to include this functionality in Node.

Node's lack of a robust standard library results in significant dependency bloat, even for small projects. I often choose other languages (Racket, Python) for most projects because of this. I tend to consider a large number of dependencies as a risk for the stability and maintainability of projects. Through this lens, adding date handling to the standard library can make sense, I think.

Re: I finally escaped Node

#120
post #9

The article focuses on server-side Node, rather than its role as a CLI tool. Compared to V8, Ruby, Python, and PHP are not performant. Node’s libuv network library was highly concurrent and Node built single-core concurrency into the runtime and libraries; multi-core concurrency, however, is not best-of-class. IMO, Ryan Dahl made two fundamental mistakes in both Node and Deno that make them uncompetitive for simple s…

For clarification: PHP never had GIL. And it's a magnitude faster than Ruby or Python.

It's a common misconception to group PHP with Ruby and Python in terms of performance.

Even more now that PHP8 is JIT'ed. Plus async/await is coming with Fibers RFC and already present as modules.

People have been using async PHP in production for years. See Swoole.

Post reply on HN