5 ms·
I am not sure I like some of the new changes. It seems to me like JS is expanding both towards an upper level language and a lower level language, which frankly
by franciscop 10y ago
I am not sure I like some of the new changes. It seems to me like JS is expanding both towards an upper level language and a lower level language, which frankly makes it look more like a Frankenlanguage. I guess it's the limitations of having a single real language to be used in the browsers.
Edit: just check this tutorial. I'd venture to guess to 99% of JS developers it sounds totally bizarre: https://github.com/tc39/ecmascript_sharedmem/blob/master/TUTORIAL.md https://github.com/tc39/ecmascript_sharedmem/blob/master/TUT...
- pmalynin 10y agoYou mean like Python? I agree.
- tdb7893 10y agoHas python gotten much more low level recently?
- brianwawok 10y agoI would say async is a little bit lower level, but not at the atomic array level.
- icebraining 10y agoimport ctypes from multiprocessing import Array mysharedarray = Array(ctypes.<type>, 100) That's essentially the same as this proposal.
- franciscop 10y agoAdded a tutorial on SharedArrayBuffer with a lot of other low level JS stuff that looks like a total different language.
- zensavona 10y agoBut 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 agoBut 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 agoI believe the issue is in building high performance types that are both secure and that fit in with the rest of js.
- Dylan16807 10y agoJIT 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 agoC++ was OS-native on some older now extinct systems, like Symbian and BeOS.
- metaobject 10y agoI think he's talking about Java
- josefx 10y agoThere 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.
- rtpg 10y agoI think the idea is for these things (much like TypedArray and the like) to be used by "compile-to-JS" languages, rather than to be used directly too often.
- johncolanduoni 10y agoMaking them accessible from WASM is also likely to happen in the future, as they're perfect for running truly multithreaded C/C++, Rust, etc. code.
- tonyedgecombe 10y agoWe certainly don't seem to know when to stop extending software.