We can agree to disagree, but can we agree that Deno has a high likelihood of chipping away at Node looking forward?
Yes, Rust is an alternative to C and C++. It's staking a claim in the performance game. Deno is written in Rust. Rust is also getting some love at big companies including both Microsoft (GitHub as well) and Google. It is also being used at Discord.
I would also be interested in "a lot of challenges that other language platforms don't have". Every platform has its challenges.
Sure. Let me expound -- this is anecdotal and I've worked in Ruby, Node, Python, Golang, Elixir, and now Rust in production environments. I'm also speaking exclusively for backend web services, where most of my experience is. Of these, I default to Elixir (Erlang VM/BEAM). Operationally, probably the best platform to use for long-running services. Why? It comes out of the box with runtime introspection (observer) allowing an operator to go in and look at issues happening in real time, fault-tolerance built in (supervision trees) that provides "self-healing" that's great for avoiding some pages during the middle of the night, clustering and service discovery out of the box (granted that you're running on a cloud provider that supports it or VPC, but not Heroku). So while, every platform, including the BEAM has its challenges, it's less painful than that of Node. More often than not, because most of us know JS, we default to "easy to write" implicitly. Remember, though, that code is read more times than it is written, and maintenance has a cost. Node/JavaScript when compared to even the other language that I mention has many challenges that for me, and I'd imagine for others (if they're familiar with other platforms) would choose not to adopt. Node/JS isn't very good for numbers or mathematics. The package management is pretty gnarly (i.e. peek at node_modules lately?). You have to adopt the async model of programming -- which is much harder to debug and introspect -- compare this to Elixir where one can stick an IO.inspect into the middle of a pipeline/chain of function calls.
I don't make as bold claims and/or predictions as you do. Sometimes you're right and sometimes you're wrong. I'm simply citing an observation that is perhaps unique to the bubble/pocket of tech that I'm in (San Francisco). Maybe you've grown to love Node and TS and that's fine, because you and the others that are enjoying it will be its torch-bearers. And most of us will default to starting any project in something we're most familiar with or make choices from things we're familiar with. I'm not going to tell someone to go do Elixir or Rust while building a start-up or new project if they don't already know it. That would be signing up for zero productivity. For me, having worked in the platforms above, I would never choose Node. I still enjoy writing JavaScript and would leave it to just client-side/browser-specific applications. Would I mind reading someone's small project in it? No. However, I would take pause before I signed up to work in Node in production and most certainly wouldn't start a project in it. I would certainly explore Deno before Node if JS/TS is the language choice. I find Node/JS to have the most "footguns" of all the languages/platforms that I've listed.
I wrote my post simply to urge people to try new things -- explore. It opens one's world to the possibilities and what's been done about the parts you don't like in your language and platform. That's the message I would hope people are taking from it :)
I wouldn't say I "love" Node/TS. I firmly believe pick the right tool for the right job. What I am saying is that if you want to build out a GraphQL server or even some serverless RESTful API endpoints - the Node/TS stack is currently my goto.
But, I will agree that that stack needs better debugging/testing/introspection tools. Some of the cloud vendors offer some drop-in libs. Async, threads, or any non-blocking style coding is going to be harder to debug for sure. My teams use strong linting rules and code formatters so that there is some guidance on how to structure code.
Anyway. I do appreciate your thoughts and I very much agree that people should explore :)
Yeah -- definitely. However, for some of us, we only have a single tool. Anything and everything that can be done in JavaScript, will be done in JavaScript. It's a double-edged sword -- it does open up the doors to areas that formerly weren't open before (e.g., hardware/IoT, ML, etc), because it is a pretty large undertaking to learn new languages and their ecosystems. JS certainly has served as the "gateway language" for many, including myself. It's hard to see how different things could be until we've actually experienced them. When I only did JavaScript, it was easy to just acknowledge the warts and work around them as a fact of life. You're also right about some of the drop-ins some providers have come up with to better the experience.
And no problem -- I thoroughly enjoy discussions around different technologies and reconfiguring my line of thought with the advent of new info and data points :)
Out of curiosity, though, being that you've worked in Java, do you like Java? If not, what about other JVM languages? I've never worked in Java in production, but have fiddled around with a few JVM langs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We can agree to disagree, but can we agree that Deno has a high likelihood of chipping away at Node looking forward?
Yes, Rust is an alternative to C and C++. It's staking a claim in the performance game. Deno is written in Rust. Rust is also getting some love at big companies including both Microsoft (GitHub as well) and Google. It is also being used at Discord.
Sure. Let me expound -- this is anecdotal and I've worked in Ruby, Node, Python, Golang, Elixir, and now Rust in production environments. I'm also speaking exclusively for backend web services, where most of my experience is. Of these, I default to Elixir (Erlang VM/BEAM). Operationally, probably the best platform to use for long-running services. Why? It comes out of the box with runtime introspection (observer) allowing an operator to go in and look at issues happening in real time, fault-tolerance built in (supervision trees) that provides "self-healing" that's great for avoiding some pages during the middle of the night, clustering and service discovery out of the box (granted that you're running on a cloud provider that supports it or VPC, but not Heroku). So while, every platform, including the BEAM has its challenges, it's less painful than that of Node. More often than not, because most of us know JS, we default to "easy to write" implicitly. Remember, though, that code is read more times than it is written, and maintenance has a cost. Node/JavaScript when compared to even the other language that I mention has many challenges that for me, and I'd imagine for others (if they're familiar with other platforms) would choose not to adopt. Node/JS isn't very good for numbers or mathematics. The package management is pretty gnarly (i.e. peek at node_modules lately?). You have to adopt the async model of programming -- which is much harder to debug and introspect -- compare this to Elixir where one can stick an
IO.inspectinto the middle of a pipeline/chain of function calls.I don't make as bold claims and/or predictions as you do. Sometimes you're right and sometimes you're wrong. I'm simply citing an observation that is perhaps unique to the bubble/pocket of tech that I'm in (San Francisco). Maybe you've grown to love Node and TS and that's fine, because you and the others that are enjoying it will be its torch-bearers. And most of us will default to starting any project in something we're most familiar with or make choices from things we're familiar with. I'm not going to tell someone to go do Elixir or Rust while building a start-up or new project if they don't already know it. That would be signing up for zero productivity. For me, having worked in the platforms above, I would never choose Node. I still enjoy writing JavaScript and would leave it to just client-side/browser-specific applications. Would I mind reading someone's small project in it? No. However, I would take pause before I signed up to work in Node in production and most certainly wouldn't start a project in it. I would certainly explore Deno before Node if JS/TS is the language choice. I find Node/JS to have the most "footguns" of all the languages/platforms that I've listed.
I wrote my post simply to urge people to try new things -- explore. It opens one's world to the possibilities and what's been done about the parts you don't like in your language and platform. That's the message I would hope people are taking from it :)
Thanks for the excellent reply.
I wouldn't say I "love" Node/TS. I firmly believe pick the right tool for the right job. What I am saying is that if you want to build out a GraphQL server or even some serverless RESTful API endpoints - the Node/TS stack is currently my goto.
But, I will agree that that stack needs better debugging/testing/introspection tools. Some of the cloud vendors offer some drop-in libs. Async, threads, or any non-blocking style coding is going to be harder to debug for sure. My teams use strong linting rules and code formatters so that there is some guidance on how to structure code.
Anyway. I do appreciate your thoughts and I very much agree that people should explore :)
Yeah -- definitely. However, for some of us, we only have a single tool. Anything and everything that can be done in JavaScript, will be done in JavaScript. It's a double-edged sword -- it does open up the doors to areas that formerly weren't open before (e.g., hardware/IoT, ML, etc), because it is a pretty large undertaking to learn new languages and their ecosystems. JS certainly has served as the "gateway language" for many, including myself. It's hard to see how different things could be until we've actually experienced them. When I only did JavaScript, it was easy to just acknowledge the warts and work around them as a fact of life. You're also right about some of the drop-ins some providers have come up with to better the experience.
And no problem -- I thoroughly enjoy discussions around different technologies and reconfiguring my line of thought with the advent of new info and data points :)
Out of curiosity, though, being that you've worked in Java, do you like Java? If not, what about other JVM languages? I've never worked in Java in production, but have fiddled around with a few JVM langs.