221–230 of 323 posts
Earlier quoted context omitted.
Notice how this doesn't even mean anything.
Sure it does. Ask a direct question get a direct answer. Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy.
The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? I mean come on man, I understand you don't need parallelism for a lot of use cases but even if that fits your situation why javascript? It can't be that hard using a different language. I refuse to believe that.
The argument that people always throw at me is that too hard for people to know two languages, well, for frontend devs to know two languages. Now in a perfect world the frontend people who just can't figure out two or more languages would never touch the backend but the world of software now is "that'll do" not "what is the right tool." It's a shame to me really but I'm not a frontend dev for a reason.
Earlier quoted context omitted.
Using non-blocking IO is a very old trick. Even nginx does exactly this, and it's written in C. The ability to use non-blocking IO does not make a language unique in any real fashion.
It has nothing to do with the language, there were other serverside javascript frameworks before node; they didn't take off (e.g. Narwhal). Node's success has everything to do with the environment itself in combination with the language. The node runtime, the associated stdlib, and most open source/3rd party modules have been written for a non-blocking runtime from day #1. The same stuff can be achieved in plenty of…
The real innovation that the Node environment and the Javascript language offered is one of marketing to developers who did not know better. Because there were no I/O paradigms in Javascript, one could be created to support this way of doing things, and there was no competing paradigm that people could point to in Javascript to say "Why would I do this when I could just use threads? It's not that hard."
With that out of the way, the floodgates opened, because once the first few people started adopting it because they did not understand threads, it was only a matter of time when "front end" people adopted it, because they did not know any languages other than Javascript. And thus, the current fad was born.
Earlier quoted context omitted.
My take on this (I have had the same experience, fwiw) is that it is like the well-known story of bridges falling down due to experienced engineers retiring (Tay Bridge Disaster, Tacoma Narrows Bridge for example). A new generation of folks who actually believe that "Single Threaded is a benefit" arrive on the scene and make a bridge that falls down..
Single-threaded isn't a benefit, but in a world where multi-process isn't a problem, a lot of that is blunted. Granted, for problems that are both compute- and IO-heavy, something like the JVM makes much more sense (so just use it--duh, right?). For throwing bytes over a wire, something like Node is really, really easy and really, really effective. My biggest beef with it is the weak libraries for talking to RDBMSes,…
>Single-threaded isn't a benefit
Earlier quoted context omitted.
Single-threaded isn't a benefit, but in a world where multi-process isn't a problem, a lot of that is blunted. Granted, for problems that are both compute- and IO-heavy, something like the JVM makes much more sense (so just use it--duh, right?). For throwing bytes over a wire, something like Node is really, really easy and really, really effective. My biggest beef with it is the weak libraries for talking to RDBMSes,…
>Single-threaded isn't a benefit Huh? Of course it has some benefits. Unfortunately everything is just trade-offs. A benefit of single-threadedness is that you don't deal with the certain pitfalls of multi-threadedness.
The fact that JavaScript and the web platform kind of sucks while at the same time being "unavoidable" is why it's so good. It forced a lot of very smart people and a lot of eyes onto the platform to try and find solutions within the extremely restrictive "box" to these problems. How do you solve the API issues when you don't control the platform? How do you solve for perf when things can't be installed? How do you s…
These are why I dislike the javascript ecosystem. It's like a giant game of codegolf -- solving problems that shouldn't be solved overcoming constraints that shouldn't be imposed using creativity that ought to be spent on the big picture. "Very smart people" are great at twisting and stretching and finding the most optimal possible solution within the restrictive box that you give them. But they're not always great a…
Tl;dr -- pragmatism is why the web ecosystem is eating the world, not optimal design.
The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? I mean come on man, I understand you don't need parallelism for a lot of use cases but even if that fits your situation why javascript? It can't be that hard using a different language. I refuse to believe that.
The argument that people always throw at me is that too hard for people to know two languages, well, for frontend devs to know two languages. Now in a perfect world the frontend people who just can't figure out two or more languages would never touch the backend but the world of software now is "that'll do" not "what is the right tool." It's a shame to me really but I'm not a frontend dev for a reason.
I would propose "person who can only be at most half-competent," except that is too wordy and probably too charitable.
Earlier quoted context omitted.
> collectively evaluate competency and correctness of a developer I'm sorry, is this a dig at Ryan Dahl, or of JavaScript/Node developers in general? I'm having trouble understanding what point you're addressing with this comment. As for evaluating languages for their "best purpose", I think that's a very complex discussion that doesn't necessarily yield a best (or cost effective/productive) result. And certainly, as…
I'm sorry, what don't you understand? Complexity is best discussed by those who introduce it. To be clear: I said js is misplaced on the 'server' side and is a wart in general when applied in that context. Any educated comment on these sentiments?
Exactly what I asked.
> Any educated comment on these sentiments?
Without clarity on the sentiments themselves there's not a lot to elaborate on without simply fumbling in the dark. If the concern, though, is that, in Node, you live and die by an asynchronous event loop, I'd say that's not a small footgun. I don't think that's in dispute. I'd also say that the presence of footguns doesn't, by itself, disqualify a language from being used in any particular context.
As for JavaScript being a wart, I don't really agree with that sentiment. I think that's attributable to some pretty strong and level-headed language evolution making what was once a very blunt scripting instrument into something somewhat reasonably suited to larger-scale applications.
The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? I mean come on man, I understand you don't need parallelism for a lot of use cases but even if that fits your situation why javascript? It can't be that hard using a different language. I refuse to believe that.
For the millionth time: It is not accurate to refer to it as single threaded. The language is non-blocking, so any asynchronous tasks (DB read/writes, disc I/O, cache, http, etc) will immediately jump to processing the next request the moment it is not doing blocking computation. Non-blocking: [aa][bb][cc][/aa][/cc][/bb][dd][ee][ff][gg][/dd][/ff][/gg][/ee] Blocking-threaded: [aa]------------------------[/aa][ff]-----…
You can have "non-blocking" and multiple threads at the same time.