I finally escaped Node • Hacker News Board

Re: I finally escaped Node

#161

Post by ineptech » Thu, Mar 25, 2021, 4:35 AM UTC

hn_throwaway_99 wrote: post #72

cygned wrote: 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…

To each their own. I was a Java engineer for most of my career since the early 00s, switched to Node a couple years ago (primarily running Apollo GraphQL server in Node), and I find myself so much more productive now. Addressing each of your points: 1. Yes, I think it's true that server-side Node isn't really usable without tight reliance on NPM. That said, I think NPM has improved by leaps and bounds over the past f…

Thanks to you and the parent comment both for this rundown on the pros and cons, I found it helpful; and also, using a throwaway account to defend nodejs is, if intentional, a fantastically subtle joke.

Re: I finally escaped Node

#162

Post by cygned » Thu, Mar 25, 2021, 5:06 AM UTC

haolez wrote: post #156

cygned wrote: post #48

Earlier quoted context omitted.

Great question. I was very concerned about that, too. I strongly recommend learning Domain Driven Design before diving into Spring, you will recognize a lot of patterns and it then makes sense how things work. Even things like having an interface + an implementation for basically everything becomes apparent. I had a lot of bad experience with Spring and Jakarta EE in the past, but I can assure you Spring Boot does a…

Thanks for the thoughtful answer. Do you have any recommendation of a good book to solidify my DDD understanding? I've read one in the past (can't remember the name) and that one felt like IT consulting bullshit :)

Read in order:

1. Anatomy of Domain-Driven Design, S. Millett

2. Domain Driven Design quickly, InnoQ

3. Implementing Domain Driven Design, V. Vernon

Re: I finally escaped Node

#163

Post by nickthemagicman » Thu, Mar 25, 2021, 5:21 AM UTC

egeozcan wrote: post #117

nickthemagicman wrote: post #83

Earlier quoted context omitted.

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.

It's not bad. Would I rather use anything else if possible? Yes.

Re: I finally escaped Node

#164

Post by hnedeotes » Thu, Mar 25, 2021, 5:29 AM UTC

int_19h wrote: post #126

hnedeotes wrote: post #104

Earlier quoted context omitted.

Here I'm a bit out of my depth. I think with Erlang you don't need to know >that particular implementation of green threads, but you need to implement the required specifics of the VM FFI (which in practical terms might be what you meant) - but this has a reason, in that, for the VM to provide its guarantees it needs to be able to count "cycles", refs, etc in order to preempt the execution of any function/process at…

That's the thing - it works for Erlang/Elixir, because it tends to live in its own ecosystem with its own libraries etc. If you are working on something where there's an existing large ecosystem in, say, C++, you'll be reinventing the wheel. Or jumping through hoops with a multiprocess implementation (pipes, sockets etc), and having fun synchronizing those. Now, not all projects are like that - but reusing libraries…

Yeah, it kinda limits the scope of adoption/interest in a way and I think everybody working with it would like that it wasn't the case but I don't think that gap can be worked out easily (or in a practical way) because without the code being written to accommodate the requirements of the VM it can't do what it's meant to do.

If you link a piece of code that can crash the whole VM or steal the processors schedulers then the value in writing supervision trees, restart strategies, compartmentalising your runtime concerns into processes, plus the tradeoffs made in the vm/language design themselves go down, because a single invocation can throw it all out of the window.

(and note, this is not to say the "outside" code is of less quality or anything, is just that when writing "inside" the vm, if you don't account for an unknown problem that happens only sometimes but place it under a proper chain of supervision (and this is much easier to do than writing 100% bug-free I've covered all cases including heinsenbugs code), it will be contained and not bring down the entire VM along with everything it was doing at the time, like all open client sockets or work it was doing, or impact other users when it happens)

Re: I finally escaped Node

#165

Post by jake_morrison » Thu, Mar 25, 2021, 5:31 AM UTC

int_19h wrote: post #84

hnedeotes wrote: post #66

Earlier quoted context omitted.

I think I might be missing what you mean? You can write an async/await implementation from scratch in a few dozen lines of elixir if wanted, but you also have Tasks that provide that already written for you (with support for being included into supervision trees, etc)? How does JS interoperate with something outside V8?

A JS library that wants to interop with something outside of its runtime (which is not necessary V8 - it isn't in WinRT, for example) can do so through FFI facilities. So long as said FFI supports all the same things that C does, it supports callbacks via function pointers. And if you can pass a function pointer + data pointer to some API, you have a stateful callback - i.e. a promise/future/task. And you can map any…

Elixir/Erlang has some of the most mature ways of interoperating with external code of any language.

It's literally what Erlang was invented for 30 years ago, building telephone switches where the main logic was on the Erlang VM, interfacing with logic in C which interfaces with the switch hardware.

There are multiple ways of doing it, each with different tradeoffs of safety and performance. You can write FFI code using NIFs, but the Erlang culture of reliability frowns upon it unless you have real performance needs. A good example would be doing cryptography. If the FFI code needs to handle concurrency itself, it can, communicating with Erlang/Elixir via messages. You don't need to care about the threading model. But that's generally not a great architecture. You should rely on the VM's processes to handle concurrency and make the FFI code just be libraries.

It's very common to write performance critical code in a compiled language such as C++ and talk to it over a "port", which spawns an OS process and communicates with it over stdin/stdout. An example is high frequency trading, where Erlang is used to supervise low level code.

You can also write a "C node" which allows a standalone program written in C or Java to talk the native Erlang network distribution protocol. So you just send messages to it.

This kind of thing is very common in Elixir embedded systems, and a joy to work with. See https://www.cogini.com/blog/elixir-and-embedded-programming-...

Re: I finally escaped Node

#166

Post by jake_morrison » Thu, Mar 25, 2021, 5:52 AM UTC

argvargc wrote: post #125

ducharmdev wrote: post #45

Earlier quoted context omitted.

Do you have any concrete examples you can link to show these differences? I'm unsure what you mean by architectural decisions made at the language level.

Maybe a good example could be the recursion pattern in Elixir. This is considered almost a base element of the language. Typically in Elixir recursion and "guards", are used instead of things like for-loops and if-else statements in other languages. Take a basic factorial function in Elixir: defmodule Math do def factorial(0), do: 1 def factorial(n), do: n * factorial(n - 1) end There is almost nothing there that isn…

That's a good example, but I would not want to overstate the need for recursion. Most people look to the standard patterns in https://hexdocs.pm/elixir/Enum.html unless they are doing some custom control flow.

Pattern matching is really helpful, though. It turns complex nested logic into simple truth tables and acts like Eiffel's design by contract, just pattern match on valid inputs, then handle the errors.

The same functional patterns repeat at different levels in the stack. For example, in the Phoenix web framework, processing a HTTP request can be considered as pattern matching on the expected inputs (validating them), then a series of transformations (making a db request, taking the result and rendering it into HTML via a template), then returning the result.

From a concurrency perspective, the interesting part is that each HTTP request runs in its own separate blocking process (green thread). So when you are doing the programming, you don't need to think about concurrency and async stuff. You just do your thing. This makes it easy to think about and debug.

Re: I finally escaped Node

#167

Post by hajile » Thu, Mar 25, 2021, 6:02 AM UTC

martinald wrote: post #149

hajile wrote: post #146

Earlier quoted context omitted.

Node has worker threads and shared memory buffers to share data between them.

Do you have a link to the shared memory buffers? I can't find much about them. I've found some stuff about worker threads but can only pass strings.

Here's one overview that's a pretty easy overview.

https://dev.to/feezyhendrix/worker-threads-in-node-js-2ikh

You can read more about atomics and shared array buffers in JS on MDN

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: I finally escaped Node

#168

Post by chrisandchris » Thu, Mar 25, 2021, 7:49 AM UTC

bstar77 wrote: post #110

chrisandchris wrote: post #109

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.

Strongly disagree.

Who maintains day.js? It‘s (i did not look, i guess) not the same people that develop the JavaScript standard library. At some point, day.js is abandoned or breaks something and nobody is going to fix it because it is abandoned, or even worse, soneone creates a fork and fixes it there and now we have 2 day.js.

If it is in the standard library, you have a guarantee that it works today, works tomorrow and with a quite high certainty still works the day after. There are not that many languages that successfully break backwards compatibility often.

And don‘t get me started with the legal aspect. There are many projects where one cannot simply pull another dependency just to calculate a date diff.

Re: I finally escaped Node

#169

Post by chrisandchris » Thu, Mar 25, 2021, 7:52 AM UTC

bstar77 wrote: post #137

codecurve wrote: post #118

Earlier quoted context omitted.

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.

That why we read and learn. You can't expect node to work like java. I feel like I'm talking to a wall with you guys. I've been working with JS for 15 years. I would never presume to start Java dev and expect to do things my way. I saw the same thing when Java devs were trying to learn Ruby... you have to approach with a different mentality. Regarding Moment, on their site and they plaster exactly why you should not…

That‘s not the point. Nobody expects that Node/Js does exactly the same as Java or C#. If so, one could simply use Java or C#.

A language should provide a set of functionality that makes the developers life easier and consists of a set that he can achieve basic (daily) things without the need of 3rd-party dependencies. And if that usually starts with „npm -i“ I‘m going to question that...

Re: I finally escaped Node

#170

Post by hn_throwaway_99 » Thu, Mar 25, 2021, 8:18 AM UTC

ineptech wrote: post #161

hn_throwaway_99 wrote: post #72

Earlier quoted context omitted.

To each their own. I was a Java engineer for most of my career since the early 00s, switched to Node a couple years ago (primarily running Apollo GraphQL server in Node), and I find myself so much more productive now. Addressing each of your points: 1. Yes, I think it's true that server-side Node isn't really usable without tight reliance on NPM. That said, I think NPM has improved by leaps and bounds over the past f…

Thanks to you and the parent comment both for this rundown on the pros and cons, I found it helpful; and also, using a throwaway account to defend nodejs is, if intentional, a fantastically subtle joke.

Meh, check my post history. I created a throwaway account years ago to comment on some somewhat controversial topic back in the day. I just forgot to throw it away.