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

After a year of using Node.js in production

geekforbrains.com

Post reply on HN
Print view View original

231–240 of 248 posts

Re: After a year of using Node.js in production

#231

Post by Silhouette »

spion wrote: post #227
Silhouette wrote: post #213

Earlier quoted context omitted.

Can you be more specific? Sorry, it wasn't my part of the project so I can't offer much detail. I know they never got as far as a Node build that passed the full test suite on some platforms. Many of the problems seemed to be around how floating point is handled on different types of CPU. Compared to what exactly? I don't see any mainstream dynamic language except Lua doing better. Ruby? Python? The total footprint f…

I'm afraid that based on what you said, it only made it clearer that this wasn't an issue with the ecosystem but with that particular developer. I don't really see how you can extrapolate that this was the node ecosystem's fault, when you have a developer that is trying to implement SQL on top of NoSQL and pull in a gigabyte of dependencies for an embedded platform. If a C++ developer was trying to implement the app…

Just to be clear in case I've given the wrong idea, my point here is not really to criticise Node in general. I'm just saying, with the benefit of hindsight of course, that it was not the ideal choice for that particular job. In particular, because of the hype around Node, I think the people making the decisions (including the developer who was working on it) honestly didn't expect that, and perhaps weren't sure how to proceed when the problems I mentioned started mounting up.

(Edit: That said, the difficulties with size, portability and dependency management in the Node ecosystem that were exposed by this particular project are more general flaws with that Node ecosystem and not specific to this particular developer.)

You got me curious about the application, by the way. If you let me know what it does, it might be fun to try and implement a prototype in node (with sane dependencies and easy to deploy on a RPi)

It really wasn't anything very complicated by database standards, just storing some settings in a central place. Those settings were a bit more complicated and inter-related in this case than you could conveniently store using something as simple as a plain text file, so a lightweight database was the next logical step. As mentioned before, it was the kind of thing where you could implement the basic infrastructure required within a few hours using more suitable tools.

Re: After a year of using Node.js in production

#232

Post by Silhouette »

auvrw wrote: post #218
Silhouette wrote: post #65

Earlier quoted context omitted.

Lessons already learned by older engineers (who went through similar woes with other languages/tools) are being re-learned again and again. If only that were true! I think the JS (and more generally web development) ecosystem today is more a case of those who do not learn from history being doomed to repeat it. The thing is, if you actually are Google or Facebook or Microsoft or Mozilla or Apple, you can throw huge a…

maybe i haven't read this thread closely enough ... the parent to this post mentions "lessons of the past" and its parent mentions typed languages, so uh, what lessons are being discussed here? certainty not "the past teaches that typed languages are best," b/c lisp

For what it's worth, I don't think Lisp is a very convincing example of how useful a language with a limited type system can be, because to a first approximation no-one uses it.

But more generally, the modern web development world is only just waking up to the idea that if you want to build software sensibly beyond a very small scale, you need tools for modularity and composition. Separation of concerns is important to preserve developer sanity and keep maintenance manageable. It is helpful to have well-defined, stable interfaces, whatever the current underlying implementation. Having an expressive language is good, but having an expressive language built on sound foundations and with consistent patterns and clean semantics is much better. Standards for protocols and formats are important. Performance matters, in many different ways. Quality matters. Portability and standards compliance matter. Longevity and stability and backward compatibility matter. Having a few good tools that work well and offer substantial benefits is much more valuable than having a million tiny things that change or become unsupported within weeks. Frameworks can be useful for getting going quickly, but you lose flexibility down the line if your requirements evolve beyond what the framework was designed to support and that can hurt. Libraries offer more flexibility, but you often incur overheads converting to and from their conventions and those overheads need to be reasonable if the library is going to be useful. Reuse is good but not always the best choice.

These and many other lessons in real world software development were brought to you by the words "developers older than", the number 30, and experience of programming outside the JS bubble. :-)

Re: After a year of using Node.js in production

#233

Post by mpweiher »

beders wrote: post #223
mpweiher wrote: post #144

Earlier quoted context omitted.

> And even then, the single-most useful function in an IDE > 'Show Call Hierarchy' will never be available when > using a dynamically typed language. True when "never" = "40 years ago". Smalltalk IDEs have had features for displaying call hierarchies statically and dynamically since essentially forever. And of course, in a dynamic environment the IDE vs. program distinction doesn't matter, so if you want to really kn…

If your IDE is your runtime environment. Sure. I've started with Allegro Common Lisp, so i kinda know a thing or two about that. The success of Smalltalk then speaks for itself?

So much the worse if you actually knew that what you claimed was factually wrong.

Re: After a year of using Node.js in production

#236

Post by joshmanders »

beders wrote: post #228
joshmanders wrote: post #9

These types of articles make me laugh. Typically a dev with many many years experience with one language, learned all it's quirks, standards, etc decides to try Node.js because it's the "new hot fun toy", and expect it to work like their old language, and realize that is not how it works, doesn't know where to find what and fails real hard to realize that JavaScript in general is in a huge influx of updating at this…

You seem to enjoy switching tools and methodologies and see it as part of embracing Node.js. Others don't have that luxury and just can't afford that. And if your software needs to be around for more than 5 years, you want to keep your costs low. How long would it take you to find a bug given a stack trace from a Node API with close to no clue which part part of your app registered that callback that isn't called bec…

> You seem to enjoy switching tools and methodologies and see it as part of embracing Node.js.

I've been using the same tools for the last 7 months outside of switching from Angular 1.5 to React because I'm not a fan of Angular 2.0.

> Others don't have that luxury and just can't afford that.

Then don't? What is this sense of needing to change everything because something else comes out, that developers have?

If your current toolset works, why change it? Why rewrite a monolithic app in another fancy language or tool just because someone wrote a blog post boasting about that new tool/language?

Re: After a year of using Node.js in production

#237

Post by spion »

Silhouette wrote: post #231
spion wrote: post #227

Earlier quoted context omitted.

I'm afraid that based on what you said, it only made it clearer that this wasn't an issue with the ecosystem but with that particular developer. I don't really see how you can extrapolate that this was the node ecosystem's fault, when you have a developer that is trying to implement SQL on top of NoSQL and pull in a gigabyte of dependencies for an embedded platform. If a C++ developer was trying to implement the app…

Just to be clear in case I've given the wrong idea, my point here is not really to criticise Node in general. I'm just saying, with the benefit of hindsight of course, that it was not the ideal choice for that particular job. In particular, because of the hype around Node, I think the people making the decisions (including the developer who was working on it) honestly didn't expect that, and perhaps weren't sure how…

Okay. I've had vastly different experience with node on ARM. Much more reasonable dependencies size then what you report (by about 2 orders of magnitude) and excellent performance from the JIT. Combined with the ability to first write dynamic code then switch to static types, as well as the memory safety, its been a lot more pleasant than working with C.

So honestly, I really can't relate to most of what you said here :)

Re: After a year of using Node.js in production

#238

Post by spion »

majewsky wrote: post #172
spion wrote: post #97

Earlier quoted context omitted.

The main problem with most typed languages is basically that types are nominal by default. What I want is free-form records and structural types by default, nominal types only when necessary. I get more than half of that with TypeScript (it does lack nominal types but there are ways to get around that), and honestly its the half I prefer having.

Most serious statically-typed languages have some sort of "anything" type where you can check the actual value type at runtime using some sort of reflection. For example, the direct Golang equivalent of a Javascript object is a map[string]interface{}.

I'm not looking for an `any` type, but for structural types: Go interfaces are already a basic form of that, although a bit too basic.

And I hate to say it, but Go doesn't qualify as a serious statically typed language. No language without generics does.

Re: After a year of using Node.js in production

#239

Post by firasd »

ralusek wrote: post #156
firasd wrote: post #25

I've been on a similar learning curve with Node over the last year, and it has certainly been a rougher incline than other languages I've used. The whole async situation needs to settle down, it's completely unacceptable to write code with callbacks, promises, etc. This is because they are not just challenging to deal with, but intrinsically wrong in concept. I have to wait for a database query to complete, then pass…

I feel like I'm taking crazy pills. "Async situation needs to settle down"...? "Completely unacceptable to write code with promises"? Look at the following code: https://paste.ee/r/LJnhg I have function requestFromService and another readFromDB. On a single thread, I issue one request to a service and one to the database server, and you think it makes sense for the thread to just wait around? In javascript, the secon…

I'm not disputing the architectural choices behind Node's async model. I'm talking about syntax. It's cool that you can process multiple promises at the same time, but most of the time I need one promise to complete before continuing. In those cases the way it inverts regular code flow is very unnatural. Like I said, I think more support/usage of 'await' will help.

Re: After a year of using Node.js in production

#240

Post by popmystack »

maattdd wrote: post #188
Tarks wrote: post #174

Earlier quoted context omitted.

With TS do I have to have a spec for every third party code or can I import something and use it as-is, but not get the benefits of TS on that part of the code?

You can do both.

Seems like a silly conundrum to be in.
Post reply on HN