Hacker News Reader

Comment by FridgeSeal | Hacker News Reader

If I threw billions of dollars of vested interest at Python/Ruby/COBOL/(insert language of your choice) we can probably make those run at JS speeds as well. Does that solve the fundamental drawbacks of the languages?

Nope. No it does not.

JavaScript is particularly egregious because of it's weird behaviour about types and coercion and you know, just silently failing, behaviour that I wouldn't want going on in any proper system that handles anything important. Other people have written at great length about JS's many failings.

JS is not the only language with nice async support, practically every mature language has async support and a good number of the compiled ones have proper parallel support as well.

View on HN

I think this is a really important point. Every browser vendor has spent huge amounts of dollars to increase the performance of Javascript. I don't know if there's another language that has enjoyed this level of investment... Maybe Java is closest, there are multiple companies working on their own VM implementations.

The reason so much has been spent on Javascript: it runs in the web browser. For sure, people have found other reasons to like Javascript but at the bottom of the pile, money was spent because it was in the browser and the browser vendors wanted the browser to do more.

every dynamically-typed language has "weird" behaviour around type coercion, that's simply the nature of the beast.

sure wish i knew what you are talking about w/r/t "silently failing". JS has working exceptions just like 99% of widely used languages.

I'm very glad that you've been omniscient enough to determine what "proper" parallel support is, though. How's that working out for you? Meanwhile, those of us using JavaScript simply run one process per core and never worry about contention, deadlocks, or race conditions.

Probably this thing, easy to spot in isolation but much harder when part of a larger system:

   > x={}
   > x.fred
   undefined

Actively unhelpful!

> every dynamically-typed language has "weird" behaviour around type coercion

Do they now?

    $ irb
    irb(main):001:0> "0" + 1
    TypeError: no implicit conversion of Fixnum into String
            from (irb):1:in `+'
            from (irb):1
            from /usr/bin/irb:11:in `<main>'
    irb(main):002:0> ^D
    $ python
    >>> "0" + 1
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: cannot concatenate 'str' and 'int' objects
    >>> ^D
    $ node
    > "0" + 1
    '01'

> Meanwhile, those of us using JavaScript simply run one process per core and never worry about contention, deadlocks, or race conditions.

If you never worry about those things, then you're either not sharing any resources at all (in which case threads are also dead easy), or you're failing to deal with the shared resources properly.

I know you know this, but for the GP or anyone else: "Dynamically typed" doesn't mean "strongly typed". Python and Ruby are strongly typed, JS is weakly typed.

Yeah, went for the "picture is worth a thousand words" approach to explaining the distinction :)

and yet you still managed to misunderstand the point :)

Thank you for illustrating my point. All of the dynamic languages made different decisions on how to handle type conflicts, there simply is no right or wrong answer.

Oh, and JavaScript is single-threaded. It's impossible to share resources in a single process.

> Oh, and JavaScript is single-threaded. It's impossible to share resources in a single process.

DBs, files, etc etc. in-process memory isn't the only resource you're sharing.

> every dynamically-typed language has "weird" behaviour around type coercion, that's simply the nature of the beast.

No, that's not true at all. Dynamic languages don't necessarily have type coercion at all, much less weird behavior around it (and, conversely, statically typed languages they have coercion may have weird behavior around it; there's just no link between dynamic typing and weird coercion behavior.)

Who's to say not doing type coercion isn't weird? Every dynamic language treats things slightly differently.

> Who's to say not doing type coercion isn't weird?

Well, if someone has to do it, I will: not doing type coercion isn't weird, and doing inplicit type coercion (not strict promotion[0]) is both weird and dangerous.

But, in any cases that's not really the point. The point is that in this...

> Every dynamic language treats things slightly differently.

“dynamic” is irrelevant. Languages have a wide variety of approaches, doing promotion, coercion, neither, or both (though where both are done, it's often just called coercion even when it is promotion), and dynamic vs. static is mostly irrelevant.

[0] that is, where the “from" type has a range that is a subset of the range of the “to” type.so that there is never a change in meaning resulting from the conversion.

> I'm very glad that you've been omniscient enough to determine what "proper" parallel support is, though. How's that working out for you? Meanwhile, those of us using JavaScript simply run one process per core

Yeah, and I can do the same thing in Python, and it will be equally as lame: both languages are fundamentally single-threaded.

You act as if JS has all problems solved: Erlang/Elixir/Golang have far superior async & parallel stories and will happily thrash JS/Node in performance and efficiency.

How’s it working out for me? Well I do a lot of stuff in Haskell and Rust now, so pretty great actually.

Reply on news.ycombinator.com