I use bigint all the time.
Not adopted? Its not true.
Should JavaScript be split into two languages?
91–100 of 324 posts
Re: Should JavaScript be split into two languages?
#92I'd argue that other languages did this (or something similar) to great success, most notably Java. That is, the Hotspot VM was such a phenomenal engine that lots of other languages sprung up to take advantage of that: Closure, Scala, Kotlin, etc.: https://en.m.wikipedia.org/wiki/List_of_JVM_languages . Even with the Java language itself, syntactic changes happen much more frequently than VM-level bytecode changes. W…
It seems to me that wasm should just support the web/browser API instead of the current trampoline business; this way, JS build tooling can emit wasm files, which is similar to the example you use.
I’ve been hearing about access to DOM APIs from WASM for years now. Does anyone know why this is such a difficult problem?
Re: Should JavaScript be split into two languages?
#93Earlier quoted context omitted.
one contributor to the pike programming language when asked why he took the effort to optimize syntactic sugar responded: so that pike users can write simple code and still have it run blazingly fast. in pike, bigint and int are integrated in such a way that the transition is automatic. there is no overflow but as long as the values fit in an int, that is used internally to keep the code fast.
I used LPC a long time ago on an LP Mud, so Pike has always had a fond spot in the back of my mind, even if I don't use it now. However, that works for int and bigint, but Number (double precision) can represent numbers that BigInt can not, and BigInt can represent numbers which Number can not. There isn't a graceful way to automatically promote/degrade one to the other in all cases, and a silent conversion will do t…
heh, yeah, that's where i started too. i don't know how or even if LPC did it, but in pike the transition really is seamless. give it a try. as a naive user i can't even tell the difference (you can see it though if you compare typeof(1) vs typeof(20000000000000000000) (i hope that number is big enough))
Re: Should JavaScript be split into two languages?
#94"ECMA TC39", not "Emca TC39". Also, looks like a bad markup link for TC39. Also note that it's either "co-authored by Mozilla, Apple, Moddable and Sony" or "authored by Guo along with others from Mozilla, Apple, Moddable and Sony", but directly related to that statement, that makes this "not a Google proposal" but clearly an "industry proposal" if it has Mozilla and Apple buy-in. Also, "the proposed solution is not t…
> 1995 - Brendan Eich reads up on every mistake ever made in designing a programming language, invents a few more, and creates LiveScript. Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.
Re: Should JavaScript be split into two languages?
#95Earlier quoted context omitted.
direct access to the DOM for example without having to go through the javascript host, which is slow and makes DOM intensive applications impractical
Or you can just draw to canvas to make the UI fast which is what Flutter does now: https://flutterweb-wasm.web.app/ https://www.youtube.com/watch?v=Nkjc9r0WDNo
Drawing to canvas means recreating the UI and all its wide-sweeping concerns, which is quite an undertaking. And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application. Acceptable (or even preferred) for certain applications but not for most.
Providing access to an already proven DOM would be the better solution.
Re: Should JavaScript be split into two languages?
#96Earlier quoted context omitted.
Can you give an example of anything anywhere that manipulates the DOM without using JavaScript? Because it seems to me that pretty much every web application is currently using the javascript host, and the well written ones are pretty snappy.
this is going beyond my level of experience, but i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM, which is slower. how much slower, i don't know. i also don't know how old that discussion is where i learned about this. so maybe it improved since. that would be good news. did…
Previously you said:
> [...] go through the javascript host, which is slow
And now you admit:
> this is going beyond my level of experience [...]
> how much slower, i don't know
I guess people just repeat what they hear without questioning or understanding it, and then it becomes dogma.
> did you mean there are snappy webapplications running in WASM?
No. I meant that all existing web apps go through the "javascript host", using JavaScript. So if any of them are fast enough, and some certainly are, the problem isn't the "javascript host".
Re: Should JavaScript be split into two languages?
#97Sounds like the presenters are assuming that everyone must be using JS in the same way they are. As someone who prefers to work in VanillaJS, I'm already frustrated by all the language changes being forced upon me. So maybe I agree with them that fewer changes should be made, but for completely different reasons. I'd rather them work on API improvements so that web apps get closer to parity with native apps. All this…
I think the proposal is actually good for people like you. You can choose to just work with the core and maybe a minimal sugar library. Which will probably be faster and don't include "all the language features that were forced upon you".
This is not what happened in C vs C++.
Re: Should JavaScript be split into two languages?
#98Earlier quoted context omitted.
>> WASM isn’t the silver bullet everyone seems to cling to. And it isn’t the silver bullet exactly for the reason that it's horribly complicated to access normal JS objects including strings.
You're two library functions away from having it easy: Copy from JavaScript to WebAssembly: Use TextEncoder to convert a JS String to Uint8Array Copy the bytes from the Uint8Array to WemAssembly.Memory Copy from WebAssembly to JavaScript: Copy the bytes from WebAssembly.Memory into a Uint8Array Use TextDecoder to convert from Uint8Array to JS String JS Strings are pretty much always going to be "rope data structures"…
From the new official WASM proposal:
https://github.com/WebAssembly/js-string-builtins/blob/main/...
"the overhead of importing glue code is prohibitive for primitives such as String, ArrayBuffer, RegExp, Map, and BigInt where the desired overhead of operations is a tight sequence of inline instructions, not an indirect function call"
I guess the more elegant and universal stringref proposal is DEAD now !?
https://github.com/WebAssembly/stringref/blob/main/proposals...
I don't really mind, as it keeps the wasm bytecode cleaner.
Re: Should JavaScript be split into two languages?
#99This sounds like a crock of shit.
No, it won't be faster, if you only optimize a lesser language. If you have higher level code running your optimizer can do more than if it only has a low level version.
No, it won't be more secure. Js0 might be more secure, but if we sites all run any of dozens of different tools those tools are going to be creating the vulnerabilities. It's shifting where security issues occur, and creating more of them.
I'm terrified this could happen. JS has gotten so much better over time. We are so close to being able to not need transpilers. This sounds like such an absurd cop out for browsers to say, meh, we just don't want to do the work to implement. Being so close & then saying, sorry, you must use big toolchains to develop for the web is a monstrously bad future.
Re: Should JavaScript be split into two languages?
#100Earlier quoted context omitted.
That part caught my attention too. It reminds me of the discussion to remove complex numbers from Go. Funny enough, compiler writers can't even imagine why you would want BigInt or Complex, because those aren't useful for writing compilers.
The problem with Google compiler developers is that they will do a search of the google3 repository, find no uses (because Google doesn’t do any advanced math, for example) and declare the language feature to be useless.
Which is ironic because I use Google Sheets a lot and occasionally run into problems when it doesn't support BigInt calculations. Sheets is the best excuse Google has for keeping BigInt support in the language.