Live data from Hacker News

Should JavaScript be split into two languages?

devclass.com

161–170 of 324 posts

Re: Should JavaScript be split into two languages?

#161
post #6

JavaScript is two languages: 1) JavaScript, the original assembly language of the internet, does not need new language features. 2) JavaScript, the front-end web development language is a fractal of infinitely many sub-languages that transpile back to ES5. The proposal, as I read it, is: Let's stop adding front-end web features to the assembly language; it doesn't get easier, better or faster if we change the underly…

This isn’t really true on a practical level any more. ES6 support is very widespread (97% of all web users according to caniuse.) That even includes module import syntax! There are still some new language features that need to be transpiled, but most projects do not need to worry about transpiling cost/let/arrow functions/etc. I mean even newer features like nullish coalescing and optional chaining are at 93-94% supp…

[dead]

Re: Should JavaScript be split into two languages?

#162

Earlier quoted context omitted.

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://gi…

Quote from https://wingolog.org/archives/2023/10/19/requiem-for-a-strin... We don’t yet have consensus on this proposal in the Wasm standardization group, and we may never reach there, although I think it’s still possible. As I understand them, the objections are two-fold: WebAssembly is an instruction set, like AArch64 or x86. Strings are too high-level, and should be built on top, for example with (array i8). The r…

> Dealing with strings is not fun right now.

And dealing with strings isn't fun in many other languages or runtimes or OSes.

e.g.1. C# "Strings in .NET are stored using UTF-16 encoding. UTF-8 is the standard for Web protocols and other important libraries. Beginning in C# 11, you can add the u8 suffix to a string literal to specify UTF-8 encoding. UTF-8 literals are stored as ReadOnlySpan objects" - https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

e.g.2. Erlang/BEAM/Elixir: "The Erlang string type is implemented as a single-linked-list of unicode code points. That is, if we write “Hello” in the language, this is represented as [$H, $e, $l, $l, $o]". The overhead of this representation is massive. Each Cons-cell use 8 bytes for the code point and 8 bytes for the pointer to the next value. This means that the 5-byte ASCII-representation of “Hello” is 5*16 = 80 bytes in the Erlang representation." - https://medium.com/@jlouis666/erlang-string-handling-7588daa...

Re: Should JavaScript be split into two languages?

#163

Earlier quoted context omitted.

Quote from https://wingolog.org/archives/2023/10/19/requiem-for-a-strin... We don’t yet have consensus on this proposal in the Wasm standardization group, and we may never reach there, although I think it’s still possible. As I understand them, the objections are two-fold: WebAssembly is an instruction set, like AArch64 or x86. Strings are too high-level, and should be built on top, for example with (array i8). The r…

> Dealing with strings is not fun right now. And dealing with strings isn't fun in many other languages or runtimes or OSes. e.g.1. C# "Strings in .NET are stored using UTF-16 encoding. UTF-8 is the standard for Web protocols and other important libraries. Beginning in C# 11, you can add the u8 suffix to a string literal to specify UTF-8 encoding. UTF-8 literals are stored as ReadOnlySpan objects" - https://learn.mic…

Okay? Is this an argument in favor of doing nothing?

Re: Should JavaScript be split into two languages?

#164
post #71

> Regarding BigInt, the presentation states that “use cases never materialized.” Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend). Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one…

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.

That's a general problem: languages end up having features that are only useful for writing compilers, and vice versa.

Re: Should JavaScript be split into two languages?

#168
post #128

Earlier quoted context omitted.

That's nice. The implementation of a numerical tower is common in Lisps: https://en.wikipedia.org/wiki/Numerical_tower

Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats. This is where you say something about "exact" vs "inexact" as though that will hand wave it away.

that's not what pike is doing though. int and float are still kept separate.

btw, i just checked, typeof() no longer shows the difference between int and bigint. it did in the past if i remember correctly

Re: Should JavaScript be split into two languages?

#169
post #158
post #90

Earlier quoted context omitted.

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…

> 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 That doesn't have to be true. Eventually WASM will get direct access to the full browser API, without going through JavaScript. The browser exposes a browser API to the JavaScript VM it hosts, so things like the DOM are availa…

That doesn't have to be true.

Eventually WASM will get direct access to the full browser API, without going through JavaScript.

well, that is what i am waiting for. my point is that it's not the case yet, while the gp seemed to suggest that it's not needed because access through the host is available

Re: Should JavaScript be split into two languages?

#170
post #96
post #90

Earlier quoted context omitted.

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 h…

you are not answering my question. most existing webapps are not running inside WASM.

i am only talking about webapps running inside WASM. are there any WASM based webapps that are as fast as pure js webapps?

Post reply on HN