Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I finally escaped Node

acco.io

Post reply on HN
Print view View original

171–180 of 181 posts

Re: I finally escaped Node

#171

Post by IceDane »

jimbokun wrote: post #123
haolez wrote: post #43

Earlier quoted context omitted.

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…

I maintain a Java Spring Boot service full time, and when something stops working or doesn't do what you expect, it can be a total nightmare to debug. There is so much misdirection, it can be incredibly difficult to figure out which code will be executed, in which order. I try to make things as explicit as possible, which can help in testing and debugging.

Java and Spring is a nightmare and I can't believe someone can actually look at that stack and not see it as a complete joke.

Re: I finally escaped Node

#172

Post by watwut »

haolez wrote: post #155
watwut wrote: post #102

Earlier quoted context omitted.

> 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 10x more in Java. You are comparing stuff that is super helpful on large project with how to be quick in 1 hour by one person. If I have 1 hour long project in java, I wont use co…

I agree that the way I've made my statement can be ambiguous. What I meant was when using Node/Python/Go for projects of similar complexity. Maybe not millions of lines of code, but a web app with some order processing, database access and specific business logic. It feels harder in every way when using Java + Spring Boot, but my question was sincere: I'm pretty sure that this combo is a successful platform and I wan…

Imo, if you know what all of that means and what to do, it is fast and easy. If you are new to it all, it can be frustrating.

Re: I finally escaped Node

#173

Post by kgin »

benlumen wrote: post #8

I'm just getting in to Node, coming from only having used PHP and then Laravel. Is it a bad time? Using Sails.js for rapid prototyping.

No you’ll be fine. Huge amounts of the internet are built with node.

I’ve learned the hard way, you never want to pick a more-obscure solution because it’s technically better. The size of the community is just as much a feature language syntax is.

Re: I finally escaped Node

#174

Post by bstar77 »

chrisandchris wrote: post #169
bstar77 wrote: post #137

Earlier quoted context omitted.

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...

We are going to have to agree to disagree then. Both Node and frontend js share the same package management system (npm). Everything is modular because it has to be. When you work fullstack JS and use one package manager for everything, it makes all the sense in the world why things are done the way they are. The same code has to work in Node, Blink, Webkit, Electron, etc.

Re: I finally escaped Node

#175

Post by int_19h »

marcosdumay wrote: post #135
int_19h wrote: post #127

Earlier quoted context omitted.

I'm not sure I follow. Can you explain how two runtimes, each with its own green thread implementation, would interoperate in this manner to make a call across the boundary? Say, X (written in A) wants to asynchronously call Y (written in B) and wait on it, passing it Z (also written in A), which Y needs to call several times to perform its task.

X does not wait on Y. It starts the task, and adds the polling interface for the task into its internal polling list. When something is available, calls the continue interface of Y as many times as it needs, just as it does with the OS data polling. The same happens for Y calling Z.

By "wait" I mean logical wait for the result of the async operation - e.g. to use it as an input for another operation - not a blocking thread wait. What you describe sounds like callbacks to me?

Re: I finally escaped Node

#176

Post by marcosdumay »

int_19h wrote: post #175
marcosdumay wrote: post #135

Earlier quoted context omitted.

X does not wait on Y. It starts the task, and adds the polling interface for the task into its internal polling list. When something is available, calls the continue interface of Y as many times as it needs, just as it does with the OS data polling. The same happens for Y calling Z.

By "wait" I mean logical wait for the result of the async operation - e.g. to use it as an input for another operation - not a blocking thread wait. What you describe sounds like callbacks to me?

Polling loops are completely different from callbacks.

What I described uses functions to read partial or complete results, and functions that indicate if there is any result to read (and yeah, there must be some blocking thing to indicate whether there is any result at all available). It's something much closer to async/await, except that there is something to tell you if await will block.

It is much more complex than callbacks, but it enables much higher parallelism and somewhat higher single-thread throughput. Also, runtimes with green threads already have it implemented anyway, because it's the preferred OS (any high performance OS) interface for async.

Re: I finally escaped Node

#177

Post by martinald »

hajile wrote: post #167
martinald wrote: post #149

Earlier quoted context omitted.

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... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

This is sort of what I mean though. The SharedArrayBuffer seems very limited. It's fine if you are sharing binary content for processing, or some numbers. But I can't see how you could easily send a standard JS object through that?

Re: I finally escaped Node

#178

Post by Koiwai »

mamcx wrote: post #138
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…

> Is node a bad technology? You describe a lot of things that factually are signs of a bad technology. Why languages have this "free pass" where it cost BILLONS in troubles but, "no, not exist bad languages"?

You see, node is not exactly a language.

Re: I finally escaped Node

#179

Post by anko »

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…

If you've come from java and you like node, maybe you should spend some time with the alternatives?

A big part of it depends on what your exact requirements are but my experience with node didn't bite me for quite a while.

1/2) my experience is that even the supported packages have had glaring holes where they don't in other languages. Just to give a quick example, I had a project that used node-cache-manager to implement a tiered cache. There was a bug (in the cache library with the most stars) just last year where the cached values in a memory cache were passed by reference as opposed to copied. That meant any mutation on them affected other fetches from the cache! That would never happen in java. This particular bug took weeks to debug in production because values were being randomly mutated. After the fix, it also had different behaviour for when the cache value was new vs when it was retrieved. So two mutation bugs in the same cache codebase see https://github.com/BryanDonovan/node-cache-manager/issues/13....

I'm not blaming the author, he's a really good guy. What i'm saying is this is a wart both in the language and the library ecosystem - it's not unreasonable to expect a sensible caching library.

3) I agree that threads aren't necessarily the way to go. But can we agree that a language that CAN efficiently take advantage of multiple cores would be better? It's not just for your application. It's also for any compiling eg. typescript!

> Just check out the recent GitHub report where they were accidentally leaking information from other users into their sessions.

Concurrency is hard! except in a language where it isn't. In elixir each "thread" (erlang process) would get a different copy of the data so this type of bug doesn't happen.

4.

> Typescript (combined with autogenerating typescript type files from GraphQL schema definitions) has been honestly heaven for us, and the benefits I've seen with the structural-based typing of TS made me realize the huge number of times I had to battle the nominal-based typing of Java and the immense pain that caused.

That is an interesting assessment. I've never really noticed a difference in practice between structural/nominal type systems to the extent that i didn't realise typescript was structural. Normally if you have multiple classes implementing the same structure, you want an interface anyway to make sure they don't diverge i.e. there is a higher purpose for them being the same.

Would you have an example of how this would be a deal breaker?

I think besides this aspect, Kotlin might be up your alley.

Re: I finally escaped Node

#180

Post by int_19h »

marcosdumay wrote: post #176
int_19h wrote: post #175

Earlier quoted context omitted.

By "wait" I mean logical wait for the result of the async operation - e.g. to use it as an input for another operation - not a blocking thread wait. What you describe sounds like callbacks to me?

Polling loops are completely different from callbacks. What I described uses functions to read partial or complete results, and functions that indicate if there is any result to read (and yeah, there must be some blocking thing to indicate whether there is any result at all available). It's something much closer to async/await, except that there is something to tell you if await will block. It is much more complex th…

Async/await is just syntactic sugar over callback-based continuations, though.

And in .NET at least, you can easily tell if await will block or not, by looking at Task.IsCompleted.

Post reply on HN