Hacker News new | ask | show | jobs
by geezerjay 2807 days ago
Those features are hardly exclusive to javascript. Why did they made you love javascript but not any of the myriad of languages that support those features?
2 comments

What makes you assume z3t4 exhaustively tried every other language before settling on JS? It's not typical that you present your opinion of a tv show by giving the few unique positive traits it has in contrast to the union of all positive traits from tv shows in the same genre. You just watch the show on a micro level, record what you liked about it, and report that, regardless of what the macro landscape looks like. That's the same way coders typically report preference about languages (on a micro level, not a macro level).
> What makes you assume z3t4 exhaustively tried every other language before settling on JS?

My point was that you'd be hard pressed to find a popular programming language that does not support those features.

Which languages are async-everything?

I can think of JS, Go, and Erlang.

The rest, you are stuck interoperating sync and async code. Like having a Twisted/Tokio event loop embedded somewhere in your Python/Rust program and thinking very, very hard about how your blocking calls are not blocking your async runtime, like passing around an I/O thread pool and ensuring it cannot be starved.

I wouldn't be so quick to dismiss it, much less as something that every other language has.

But I have noticed that it's not something you necessarily appreciate until you've written async systems in languages with blocking APIs.

In another comment you point out that Java has promises, so who cares if JS has them. As if the hard part of straddling async/sync ecosystems is whether there exists a concurrency primitive at all.

Even Go programmers should be able to look at their WaitGroup code and have some envy when they see:

    Promise.map(things, (thing) => process(thing), { concurrency: 4 })
I think our propensity to miss the light of other languages/ecosystems is a reminder of how little breadth of experience we actually have across the field.

It's kind of like how the person that seems to have the most negative views of other people is likely to be the person who has least left their hometown -- it's just how humans are.

> Which languages are async-everything?

Op referred to async programming. I'm unaware of any popular programming language that does not support async programming.

> I wouldn't be so quick to dismiss it, much less as something that every other language has.

All languages can play the "no true scotsman" game and claim they are the only one within a myriad of alternative languages. Yet, they all support async programming, either conventional forms or as a nuanced implementation, either through modules or built into the language with the right to reserved keywords and all.

> I think our propensity to miss the light of other languages/ecosystems is a reminder of how little breadth of experience we actually have across the field.

Actually, people who lack experience and understanding tend to grab hold to their only tool of the trade and give it an inflated value just because it happens to be the only thing they do, and thus they see their personal worth as tied to the perceived worth of their tool. Consequently we end up with these futile discussions on how language X or Y is the bestest, most unique technology that nothing even comes close to match.

But yet async programming is supported by all popular programming languages, isn't it?

Some historical perspective:

Some languages picked it up along the way. So in my case, I only first found out about closures in JS, after going through several popular languages, that got closures only later on: Pascal, C++, PHP...

Then again, Lisp, Smalltalk, Haskell, etc. predate JS, from a historical perspective.
Popular languages?
This is especially important when considering what you'll see in codebases.

e.g. Java may be adding support for more async stuff, but most of the Java codebases I've worked with won't use it.

Async-await is just syntactic sugar over futures/promises and java has those for decades.
It only got the promise equivalent (CompletableFuture and CompletionStage) in java8, which is hardly "decades" ago, and a lot of common stuff like JDBC doesn't support it, so using it can be quite a pain. And that's not to mention the disaster that is checked exception interoperability with the default Java functional interfaces that force constant workarounds...
Embarrassingly enough I had programmed for many years before understanding those concepts. I only knew them instinctively. Coming from a multi-threaded web framework background, writing heavily async code was painful. But it became so simple after learning about closures and lexical scope, and that's why I consider them to be JavaScript's main features, even though almost all other languages have them too. The main reason why I haven't moved on to another language is that I get PTSD (from maintaining multi threaded code with global variables) - when I see a variable or function that I don't know where it comes from, which is common in languages that does not support lexical scoped named imports.