7 ms·

But that is exactly what is needed. JavaScript is essentially a becoming a ~native~ language (like C, C++, Java) which is used to implement all kinds of abstrac

But that is exactly what is needed. JavaScript is essentially a becoming a ~native~ language (like C, C++, Java) which is used to implement all kinds of abstractions. Think of C++ for example. It's used to implement frameworks like JUCE, used for high-level application logic and UIs, but underneath that there are a lot of optimised abstractions. Some of these abstractions can only be so good or so deep until the language they are implemented in can get closer to the "metal" (or in this instance, VM). I for one welcome these new additions to the ECMAscript spec.

franciscop 10y ago
But not really, Javascript has to be interpreted/JITed, so it will never be in the same level as C/C++. IMO it'd be way better to: - Introduce real native types, not complex-named functions that are way more bothersome to work with than types. - Use WASM or something similar to provide for a low level variant.
- foota 10y ago
  I believe the issue is in building high performance types that are both secure and that fit in with the rest of js.
- Dylan16807 10y ago
  JIT can be faster than static compilation.
vvanders 10y ago
> ... ~native~ language (like C, C++, Java) One of those is not like the others.
- fulafel 10y ago
  C++ was OS-native on some older now extinct systems, like Symbian and BeOS.
  - metaobject 10y ago
    I think he's talking about Java
    - josefx 10y ago
      There are coprocessors that run Java Bytecode directly. Is there actually an implementation of the machine outlined in the C standard? Clearly C is an abstraction while Java is a truly native language.
      - voxic11 10y ago
        Well those processors just run bytecode compiled from Java source code. The same is true of more traditional processors they just run bytecode compiled from c source code. I thicnk they are both doing essentially the same thing.
        josefx 10y ago
        So what are the properties of C bytecode? Other than undefined, implementation defined and format C:\\ ? Java specifies a high level language, the low level bytecode and a target machine while C has to abstract over the byte code and large parts of the machine, leaving it up to the developer to fight countless "implementations". Guaranteeing that the same code is simultaneously right, wrong and file not found while limiting access to features exposed by the underlying "bytecode" in ways that require software workarounds like fmadd that are used in place of hardware. Clearly the Java language -> Java bytecode -> Java Hardware chain is inherently more native and consistent than C language -> C Virtual Machine -> x64 -> Intel Core 2, where each step in the C language chain looses access to features of the underlying layer.
- stymaar 10y ago
  Surprisingly enough, Java is a native language in some parts of the embeded world (see smart cards for instance, but not only [1]). [1]: https://en.m.wikipedia.org/wiki/Java_processor https://en.m.wikipedia.org/wiki/Java_processor
  - fulafel 10y ago
    Also Android.
goatlover 10y ago
Javascript is less than ideal for this, and was never designed with this sort of thing in mind, unlike C/C++. Plus, web assembly is here.
- skrebbel 10y ago
  How is web assembly going to help with multithreading?
  - pg_is_a_butt 10y ago
    by assembling them, duh. you're all idiots.
  - voxic11 10y ago
    It's one of the primary goals of the project > Provide low-level buildings blocks for pthreads-style shared memory: shared memory between threads, atomics and futexes (or synchronic). New atomic memory operators, including loads/stores annotated with their atomic ordering property, will follow the C++11 memory model, similarly to the PNaCl atomic support and the SharedArrayBuffer proposal. Regular loads and stores will be bound by a happens-before relationship to atomic operators in the same thread of execution, which themselves synchronize-with atomics in other threads. Following these rules, regular load/store operators can still be elided, duplicated, and split up. This guarantees that data-race free code executes as if it were sequentially consistent. Even when there are data races, WebAssembly will ensure that the nondeterminism remains limited and local.

franciscop 10y ago

But not really, Javascript has to be interpreted/JITed, so it will never be in the same level as C/C++. IMO it'd be way better to: - Introduce real native types, not complex-named functions that are way more bothersome to work with than types. - Use WASM or something similar to provide for a low level variant.

foota 10y ago
I believe the issue is in building high performance types that are both secure and that fit in with the rest of js.
Dylan16807 10y ago
JIT can be faster than static compilation.

vvanders 10y ago

> ... ~native~ language (like C, C++, Java) One of those is not like the others.

fulafel 10y ago
C++ was OS-native on some older now extinct systems, like Symbian and BeOS.
- metaobject 10y ago
  I think he's talking about Java
  - josefx 10y ago
    There are coprocessors that run Java Bytecode directly. Is there actually an implementation of the machine outlined in the C standard? Clearly C is an abstraction while Java is a truly native language.
    - voxic11 10y ago
      Well those processors just run bytecode compiled from Java source code. The same is true of more traditional processors they just run bytecode compiled from c source code. I thicnk they are both doing essentially the same thing.
      - josefx 10y ago
        So what are the properties of C bytecode? Other than undefined, implementation defined and format C:\\ ? Java specifies a high level language, the low level bytecode and a target machine while C has to abstract over the byte code and large parts of the machine, leaving it up to the developer to fight countless "implementations". Guaranteeing that the same code is simultaneously right, wrong and file not found while limiting access to features exposed by the underlying "bytecode" in ways that require software workarounds like fmadd that are used in place of hardware. Clearly the Java language -> Java bytecode -> Java Hardware chain is inherently more native and consistent than C language -> C Virtual Machine -> x64 -> Intel Core 2, where each step in the C language chain looses access to features of the underlying layer.
stymaar 10y ago
Surprisingly enough, Java is a native language in some parts of the embeded world (see smart cards for instance, but not only [1]). [1]: https://en.m.wikipedia.org/wiki/Java_processor https://en.m.wikipedia.org/wiki/Java_processor
- fulafel 10y ago
  Also Android.

goatlover 10y ago

Javascript is less than ideal for this, and was never designed with this sort of thing in mind, unlike C/C++. Plus, web assembly is here.

skrebbel 10y ago
How is web assembly going to help with multithreading?
- pg_is_a_butt 10y ago
  by assembling them, duh. you're all idiots.
- voxic11 10y ago
  It's one of the primary goals of the project > Provide low-level buildings blocks for pthreads-style shared memory: shared memory between threads, atomics and futexes (or synchronic). New atomic memory operators, including loads/stores annotated with their atomic ordering property, will follow the C++11 memory model, similarly to the PNaCl atomic support and the SharedArrayBuffer proposal. Regular loads and stores will be bound by a happens-before relationship to atomic operators in the same thread of execution, which themselves synchronize-with atomics in other threads. Following these rules, regular load/store operators can still be elided, duplicated, and split up. This guarantees that data-race free code executes as if it were sequentially consistent. Even when there are data races, WebAssembly will ensure that the nondeterminism remains limited and local.