21–30 of 181 posts
From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most req…
From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most req…
How about Go?
From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most req…
From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most req…
Its probably a rhetorical question, but I would suggest Go as another alternative.
Naturally, you wouldn't want to write the frontend in Go and it also has the "not perfect" quality.
Earlier quoted context omitted.
> Languages without strong typing, like Elixir. Have you ever actually worked with elixir? In practice the (strong) dynamic typing of elixir is not a problem. I have not written a type error that has made it to prod in tens of thousands of lines of code. The last type error I made only showed up extremely rarely (once a week or so) and it didn't matter because the supervisory tree restarted the process that threw it.…
How is refactoring? I was considering moving from Node to Elixir, but now that I’m using TypeScript it does feel like I would be giving something up. It’s a breeze to make broad changes knowing the compiler will prevent me from missing a code path, etc.
In node for example, I'm refactoring constantly (or, at least, should be...) because I keep backing myself into cognitive and developmental corners by using a kind of brick-by-brick approach that is perhaps encouraged not only by the language but by the eco-system.
I'm not finding this with Elixir, possibly because many of the more important architectural decisions have already been made for me at the language level, and apparently been made very well.
The hurdle becomes more understanding how to best do something, rather than figuring out how to do something at all.
A big part of this also may be Elixir's REPL. It has help for everything built-in. Whereas in node for example I find I'm constantly searching online and piecing together things from many different parts, in Elixir I almost never am, it's all just right there.
From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most req…
I'll plug Vert.x here but just about anything these days depending on your workload.
> can spin up a http service in a day
Surely this is a typo?
From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most req…
> tell me a development platform that can run under 100 MB of memory, handle most requests under 50 ms, can spin up a http service in a day or so and still perform well under load (and scales horizontally with ease). I'll plug Vert.x here but just about anything these days depending on your workload. > can spin up a http service in a day Surely this is a typo?
Earlier quoted context omitted.
> You know what's an even worse cognitive overhead? Languages without strong typing, like Elixir. I see this mentioned many times, but when I do my impression (which might be wrong) is that you haven't written Elixir or Erlang for any thing more serious than tutorials or docs examples. Besides, elixir is technically (?) strongly typed - but not statically typed. Regarding async/await, compared to the things you get i…
I've been using Elixir for five years and I think it's sorely missing a better type system. I've done fine without it and have gotten entirely used to it but that doesn't mean things wouldn't be better with one. I only really started noticing as I started to build more complex Typescript systems how much it helps. My teammate shipped a bug in Elixir yesterday that would have been caught by a static type checker
I also won't say that it doesn't happen but I do believe if the same effort that goes into writing typed typescript and tests, aka, using dialyser and writing tests, that there shouldn't really be any difference? And when you include things like guards, explicit pattern matching, casting your data at the entry points of your system that it provides a much more robust experience?
But that's all optional - what I've seen is that theoretically there's nothing you can't express with the base syntax (+ecto) that you could with most (as in the common ones) type systems, perhaps the difference is that since in a typed language it won't compile you are forced to do those things, define all enums, all their variants, exhaustively match, etc?
Earlier quoted context omitted.
> tell me a development platform that can run under 100 MB of memory, handle most requests under 50 ms, can spin up a http service in a day or so and still perform well under load (and scales horizontally with ease). I'll plug Vert.x here but just about anything these days depending on your workload. > can spin up a http service in a day Surely this is a typo?
Why? Use NestJS, AdonisJS, or use an existing boilerplate. You may not have everything but a simple endpoint can be up and running pretty soon. Use Heroku and / or Lambdas and your prototype is deployed and running.
The article focuses on server-side Node, rather than its role as a CLI tool. Compared to V8, Ruby, Python, and PHP are not performant. Node’s libuv network library was highly concurrent and Node built single-core concurrency into the runtime and libraries; multi-core concurrency, however, is not best-of-class. IMO, Ryan Dahl made two fundamental mistakes in both Node and Deno that make them uncompetitive for simple s…