Typescript is fun. Java's type system is super unfun, with its interface-based approach to nominative typing. Of course, it has gotten better (I remember before generics, all the data structures had to have ridiculous cast statements to get stuff out). Type inference and structural are rad.

Also, the javascript runtime basically has cooperative parallelism, which makes concurrency way easier to reason about. I love this fact. I think golang is going to eventually beat out node (or node will make a seismic shift in a multithreaded direction) for just this reason. Goroutines are a really good parallelism story. I don't have as much fun in go (I admit, this is a personal and ineffable metric) but it does seem to perform really well in a web socket sort of situation.

  Dynamically-typed(for fast iteration)

NodeJS rose to popularity because it was a gateway into non-PHP backends for your typical frontend dev.

Have you ever refactored code in OCaml? (or SML, or Haskell, for that matter) This is a breeze! It's mostly the ecosystem that drives me to Python and/or JavaScript.

After years of learning I'm quite proficient with Haskell, and of course I recognize its enormous benefits, but I still totally understand the choice to use Node rather than Haskell, just like I also understand the choice to use bash for a lot of things!

I think Haskell is a transition language that will be replaced soon enough, because its warts and deficiencies significantly hinder learning and adoption.

TypeScript is probably a way more pragmatic choice for most people who want the majority of the benefits of a static type system.

What do you have in mind when you say that?

One of the existing contenders? (SML, OCaml, Rust, Elm)

Or something completely different?

Rust isn't a competitor as it's too close to metal and too verbose (great for those kinds of things, but not for everything).

Elm has nice libraries (though not even all the the standardized web APIs are supported yet). It also gets rid of Haskell's lazy evaluation, so reasoning is easier. It doesn't have type classes though (and misses many advanced features). The side effect question isn't great either IMO (I believe side effects are necessary for real-world code).

SML would benefit from a little more syntax (borrow a couple good ideas from Ocaml), but is very simple to learn and despite the simplicity, has an amazingly powerful type system. While it could gain some benefit from type classes, at least it isn't lazy, allows side effects, and is immutable by default (but allows mutation if you need).

It doesn't have classes like Ocaml or F#, but I don't consider that to be a loss. It has sane operator rules (and overloading which is important for native-feeling APIs). SML is very fast (thank you mlton) and unlike Ocaml, doesn't have to lose all its performance when you need 32 or 64-bit integers for something. Unlike Ocaml, there are actually working multi-threading implementations like poly-ml (mlton has an experimental one like Ocaml). It's worth noting that because there is a standard, you don't have one implementation/company that defines the spec.

The big flaws of SML are adoption, libraries, and the need for some extra syntax (there is work on this that is ongoing). In the grand scheme of things, it's in a very good position for a language that isn't that popular.

It's just a premonition I have of Haskell getting more complex while still tied to backwards compatibility and suddenly there's a new kid in town.

Maybe it will be something like Elixir is to Erlang or Reason to O'Caml, like, reusing the GHC runtime and GHC Core but with a new syntax and standard library.

(Of course you could argue that you don't need OCaml for that, as TypeScript or Flow can prevent this, too. But then the argument of using "dynamic" JavaScript instead of static types is moot.)

Native types like int/string/float/etc in Java/C# help little, but are a lot more write. With dynamically typed languages one doesn't have to babysit such redundant things, and often there is therefore no need to refactor function declarations, etc. And with a proper IDE refactoring works great and is as easy as with a stactically typed language.

The simple fact is you can try new ideas out quickly and very easily in Nodejs and then even take the raw prototype into production with a simple re-factor.

I don't think it works that way.

One of the reasons is you can forget about all that nasty race condition stuff you get with threading in most high level languages. There are also no pointers or direct memory manipulation. Nodejs is pretty much asynchronous by design.

I think it really is harder to “shoot yourself in the foot” than using the oldguard method of developing backend systems.

Maybe this partly explains why it is at least plausible.

The JS ecosystem does seem a lot more approachable though, you can just click through an installer and run a copy / past example, instead of a custom Java installer, IDE, configuration, Maven, all that stuff.

- Portable

- Cross-platform

- “Fast enough” out-of-the-box

- Massive ecosystem

- No need for an application container

- Actively developed and maintained

- Supports procedural, object-oriented, and functional styles equally

- Non-proprietary programming language

It's the reason why Node was at the forefront for this new wave of client-centric graph query systems (GraphQL, Falcor) that is well on its path to displacing REST as the go-to model for client-server communication.

I do agree with your point, but I'd say "1 day" instead of 3 months. After enough time elapses, JS quirks and lack of typing become a net time loss, compared to (for example) C#.

End of the day it's just syntax, framework weirdness (js devs should be used to crazy language contortions), and data structures for ~80% of day to day work.

Node just made the transition easier.

1: https://trends.google.com/trends/explore?date=all&q=Node.js,...

And, in my opinion nodejs is really good for quick & lightweight solutions.

I think my reply to your comment would have to be something like:

  * it depends what type of project experience is required (desktop app, mobile app, web server, embedded device, etc)
  * it depends where the job is
  * it depends what sector you are talking about (governments tend to choose Microsoft languages more than startups)
  * it depends what age range of applicants is expected (I'd wager Java has is a decent bias towards older programmers who probably wouldn't get hired at most companies I've interviewed at)