This articulates my fears around switching to node very clearly. I've played with it in the past and felt like it would become too difficult to manage with a large project and lots of contributors.
After a year of using Node.js in production
221–230 of 248 posts
Re: After a year of using Node.js in production
#222[deleted]
Re: After a year of using Node.js in production
#223Now all of a sudden, having types and some standards to gather around doesn't sound like a bad idea anymore ;) I agree with one of the commenters: Lessons already learned by older engineers (who went through similar woes with other languages/tools) are being re-learned again and again. The software industry is in a sorry state. Unless you are a very disciplined team with a very strong sense of writing modular code, d…
> 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?
Re: After a year of using Node.js in production
#224Now all of a sudden, having types and some standards to gather around doesn't sound like a bad idea anymore ;) I agree with one of the commenters: Lessons already learned by older engineers (who went through similar woes with other languages/tools) are being re-learned again and again. The software industry is in a sorry state. Unless you are a very disciplined team with a very strong sense of writing modular code, d…
I've worked in three million+ loc codebases, in PHP, Python and Java. I don't share your opinion that you need static types in these circumstances. You need discipline, modularity, and most importantly you need to have been blessed with gardeners and maintainers throughout the life of a project and not just after a mess has already taken hold.
Did you read what I wrote?
I already said that you need a disciplined team.
Good luck keeping that team together for years to come.
Not sure if you are disputing the fact that keeping code around is a challenge, or not.
Re: After a year of using Node.js in production
#225Earlier 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
I'm mostly lamenting the overall lack of progress in creating reliable, bug-free software.
You would never let a software engineer build a house, would you? For some reason, the discipline of architecting and building houses is far more advanced than building software.
Why is that? We keep inventing new programming languages to tackle various aspects of making software better (safe concurrency, preventing memory leaks, etc. etc.), but we keep introducing 5 bugs per Function Point and the rate of finding and removing bugs has stayed pretty much the same the last 20 years.
There needs to be a fundamental change in how we create software.
Re: After a year of using Node.js in production
#226Earlier quoted context omitted.
> Isn't that the case basically all the time? No, ES5 to ES2015 is a HUGE leap. ES2015 to ES2016 is a very minor jump as it only adds 2 new things to the spec. > Which is a perfectly suitable reason to avoid it at all costs except for the bare minimum required for front-end.. And honestly, that is not my job to tell you not to do. If you want to avoid Node.js go ahead. I feel Java is something I should avoid at all c…
Naturally. That's a jump of 2010 compared to 1
Took me a second, but now I get what you're saying. :)
Re: After a year of using Node.js in production
#227Earlier quoted context omitted.
> The tools and documentation for building and running Node are awful compared to a lot of other languages. Can you be more specific? > It's just a big runtime, and a lot of overhead because of the way libraries and dependencies are handled. Compared to what exactly? I don't see any mainstream dynamic language except Lua doing better. Ruby? Python? If you don't need native modules (which is actually the case in a sur…
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 on top of MongoDB's source code, that says more about the developer then about C++ and its ecosystem.
I might concede that the node ecosystem does have a disproportionate number of people with this mindset though :)
By the way, cross-compilation is also an option, although I haven't personally tried it:
https://github.com/mapbox/node-sqlite3/issues/249
A plus would be that only native modules have to be compiled, and only once. After that its possible to set up downloading them as binary blobs.
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)
Re: After a year of using Node.js in production
#228These 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 because of the error?
Chances are, you don't even measure the time spent in code archeology as I like to call it. The time probably is not significant right now as you kinda know your way around your code base...yet.
Re: After a year of using Node.js in production
#229Earlier quoted context omitted.
> 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a "merely-good" dev to make really good Web applications. All of those frameworks are threaded/synchronous - they are maybe 10 times easier to use and potentially 100x slower (less concurrent) than Node. The ruby equivalent isn't rails, its eventmachine. Mov…
Yeah, but is that really necessary? GitHub runs Rails and they have load.
It's all about cost.
If they would switch to more efficient languages, they could probably run on half of their current servers.
But there's the huge cost of rewriting something you already have. Will that affect your total cost significantly, if you can run on less servers.
I.e. it's too late to switch now. There needs to be a significant business reason to switch. "Stuff-that-kinda-works but needs more hardware thrown at it" is probably not a good reason.
Re: After a year of using Node.js in production
#230Earlier quoted context omitted.
How is JavaScript so special with async and streams? JS lacks any syntax for async, so it's not on par with languages that do. What's special there? Same for streams: they're implementable in any language, and JS has no special capability there. Or am I unaware of something JS has that other languages lack (besides popularity)?
When javascript performs an asynchronous operation it doesn't block the thread. It stacks everything on a queue and then just works through everything as fast as possible. Any other language would require a separate thread for each operation. I'm sure there's one other language out there that does it too but I don't know what it is. Event based programming effectively means that as long as it has something to do it's…
Vert.x basically gives you everything that node.js has - and it spins up several event loops, making your code scale without having to run several node processes.
It also allows you to mix in worker threads that are allowed to block (for I/O, for example).
You can develop in JavaScript, Java, Ruby, Ceylon, Groovy.
It's fast, async and robust.