4 ms·

Love when the C++ dev enters the debate and claims with a straight face that security vulnerabilities is problem in other languages.

IanSanders 7y ago
It's not about C++, it's about selecting a more appropriate tool that JS. JS is often used only because the developer knows nothing else. What's even more ridiculous, often JS is not even the easiest route. Serious question, what are reasons to use JS in non-web contexts, apart from developer familiarity?
- paraboul 7y ago
  > @paraboul is on point: JS is often used only because the developer knows nothing else. I never said that.
  - IanSanders 7y ago
    Apologies, I misinterpreted. Redacted
- saagarjha 7y ago
  JavaScript is one of the fastest scripting languages, for one. It often has pretty decent bindings to native code as well.
- cookiecaper 7y ago
  JavaScript is the only thing that you can really run on any semi-modern device. TVs, phones, laptops, desktops, servers, the only thing you can expect to execute on all of them is JavaScript. If you write your core libraries in JavaScript, you'll have that much less to worry about re-implementing and maintaining in something else. You'll have flexibility to potentially execute the same code on either client or server, phone or desktop. There are situations where that's pretty useful. More than that, at least last time I checked, V8 is really fast. It is many times faster than the usable Python implementations, or practically any other memory-managed runtime. Only luajit seemed to sit in the same ballpark when I pulled up the shoot-out a couple years back. I personally hate all of these facts, but sometimes, they really do mean that prioritizing JavaScript, or at least something that compiles down to JavaScript, is the best choice.
  - saagarjha 7y ago
    > JavaScript is the only thing that you can really run on any semi-modern device. Wait, hold on: you can usually run C on most devices.
    - Moru 7y ago
      The difference is that C needs to be compiled to run on anything, javascript does not.
      - saagarjha 7y ago
        Right, but JavaScript needs a runtime to work at all. And I don't think there was any requirement that the language couldn't be compiled?
        GoblinSlayer 7y ago
        It's not like you seriously want to run C without a runtime.
        saagarjha 7y ago
        Many people do in fact do this, often for embedded systems. And most other systems happen to ship with a C runtime.
      - pjmlp 7y ago
        There are C interpreters, commercial and open source since the mid-90's, don't mix languages with implementations.
    - cookiecaper 7y ago
      Generally true, but we both know that it's not so simple, and I'm surprised HN took this bait so readily. With JS, you have to worry way less about hardware-specific builds, platform-specific linking implications, differing system behavior and intrinsics, or any of the other substantial hangups that become relevant when you need to distribute a native application across a wide range of devices. We don't need to repeat the rest of the thread where everyone hops in and says "tut tut, hypothetically, it would be possible for it to not be that way". We're talking about the way things actually are. In an ideal world, JS would've been out of the picture about 3 years after it was born. :)
- Wowfunhappy 7y ago
  It's the only kind of JIT'd code you're allowed to run on iOS without going through Apple's approval process. Pebble apps use JS for any code they need to run on the phone (as opposed to the watch) for this reason.
  - saagarjha 7y ago
    (Technically there's also WebAssembly as of recently, but it's part of JavaScriptCore so this is somewhat pedantic.)
- Moru 7y ago
  To be fair, this is the case in just about everything. If you know one language or tool, most will use that tool to do what they need instead of learning something else that might or might not be used ever again. Some even find it fun to bend something that isn't meant to be bent.
- vorpalhex 7y ago
  It doesn't matter if it was a Delphi interpreter. Having an unsandboxed interpreter running unsigned code was a stupid move. That some C++ developer thought it wise to do this is perhaps part of the issue. V8 on the server has a very nice eventloop that's very easy to leverage for high performance while avoiding horrifying overflow issues and fits well for a large majority of web request/response patterns while still offering significant developer speed.

IanSanders 7y ago

It's not about C++, it's about selecting a more appropriate tool that JS. JS is often used only because the developer knows nothing else. What's even more ridiculous, often JS is not even the easiest route. Serious question, what are reasons to use JS in non-web contexts, apart from developer familiarity?

paraboul 7y ago
> @paraboul is on point: JS is often used only because the developer knows nothing else. I never said that.
- IanSanders 7y ago
  Apologies, I misinterpreted. Redacted
saagarjha 7y ago
JavaScript is one of the fastest scripting languages, for one. It often has pretty decent bindings to native code as well.
cookiecaper 7y ago
JavaScript is the only thing that you can really run on any semi-modern device. TVs, phones, laptops, desktops, servers, the only thing you can expect to execute on all of them is JavaScript. If you write your core libraries in JavaScript, you'll have that much less to worry about re-implementing and maintaining in something else. You'll have flexibility to potentially execute the same code on either client or server, phone or desktop. There are situations where that's pretty useful. More than that, at least last time I checked, V8 is really fast. It is many times faster than the usable Python implementations, or practically any other memory-managed runtime. Only luajit seemed to sit in the same ballpark when I pulled up the shoot-out a couple years back. I personally hate all of these facts, but sometimes, they really do mean that prioritizing JavaScript, or at least something that compiles down to JavaScript, is the best choice.
- saagarjha 7y ago
  > JavaScript is the only thing that you can really run on any semi-modern device. Wait, hold on: you can usually run C on most devices.
  - Moru 7y ago
    The difference is that C needs to be compiled to run on anything, javascript does not.
    - saagarjha 7y ago
      Right, but JavaScript needs a runtime to work at all. And I don't think there was any requirement that the language couldn't be compiled?
      - GoblinSlayer 7y ago
        It's not like you seriously want to run C without a runtime.
        saagarjha 7y ago
        Many people do in fact do this, often for embedded systems. And most other systems happen to ship with a C runtime.
    - pjmlp 7y ago
      There are C interpreters, commercial and open source since the mid-90's, don't mix languages with implementations.
  - cookiecaper 7y ago
    Generally true, but we both know that it's not so simple, and I'm surprised HN took this bait so readily. With JS, you have to worry way less about hardware-specific builds, platform-specific linking implications, differing system behavior and intrinsics, or any of the other substantial hangups that become relevant when you need to distribute a native application across a wide range of devices. We don't need to repeat the rest of the thread where everyone hops in and says "tut tut, hypothetically, it would be possible for it to not be that way". We're talking about the way things actually are. In an ideal world, JS would've been out of the picture about 3 years after it was born. :)
Wowfunhappy 7y ago
It's the only kind of JIT'd code you're allowed to run on iOS without going through Apple's approval process. Pebble apps use JS for any code they need to run on the phone (as opposed to the watch) for this reason.
- saagarjha 7y ago
  (Technically there's also WebAssembly as of recently, but it's part of JavaScriptCore so this is somewhat pedantic.)
Moru 7y ago
To be fair, this is the case in just about everything. If you know one language or tool, most will use that tool to do what they need instead of learning something else that might or might not be used ever again. Some even find it fun to bend something that isn't meant to be bent.
vorpalhex 7y ago
It doesn't matter if it was a Delphi interpreter. Having an unsandboxed interpreter running unsigned code was a stupid move. That some C++ developer thought it wise to do this is perhaps part of the issue. V8 on the server has a very nice eventloop that's very easy to leverage for high performance while avoiding horrifying overflow issues and fits well for a large majority of web request/response patterns while still offering significant developer speed.