3 ms·

>> 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 nor

by singularity2001 2y ago

>> 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.

xscott 2y ago
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". Trying to provide anything other than copy-in and copy-out is going to expose implementation details that are complicated as fuck and not portable between browsers.
- singularity2001 2y ago
  From the new official WASM proposal: https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md 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/stringref/Overview.md https://github.com/WebAssembly/stringref/blob/main/proposals... I don't really mind, as it keeps the wasm bytecode cleaner.
  - xscott 2y ago
    Thank you for the links. To the extent I understood it from a quick reading, it all looks like stuff you could get with the existing import/export mechanisms. I would choose (modified) UTF-8, but I understand why UCS16 is always going to be around. I agree about keeping wasm bytecode cleaner. The core plus simd stuff is such a great generalization of the ARM and X86 CPUs we mostly use. The idea of gunking it all up with DOM related stuff is distasteful.
  - davexunit 2y ago
    Quote from https://wingolog.org/archives/2023/10/19/requiem-for-a-stringref 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 requirement to support fast WTF-16 code unit access will mean that we are effectively standardizing JavaScript strings. I really like stringref and hope the detractors can be convinced of its usefulness. Dealing with strings is not fun right now.
    - robocat 2y ago
      > 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<byte> objects" - https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/reference-types 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-7588daad8f05 https://medium.com/@jlouis666/erlang-string-handling-7588daa...
      - davexunit 2y ago
        Okay? Is this an argument in favor of doing nothing?
      - debugnik 2y ago
        > The Erlang string type is implemented as a single-linked-list This refers just to Erlang's string() type, not BEAM strings in general; it's just a bad default. If you're not using binaries, you're doing it wrong, and that's exactly why Elixir's strings are UTF-8 binaries.

>> 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.

xscott 2y ago

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". Trying to provide anything other than copy-in and copy-out is going to expose implementation details that are complicated as fuck and not portable between browsers.

singularity2001 2y ago
From the new official WASM proposal: https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md 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/stringref/Overview.md https://github.com/WebAssembly/stringref/blob/main/proposals... I don't really mind, as it keeps the wasm bytecode cleaner.
- xscott 2y ago
  Thank you for the links. To the extent I understood it from a quick reading, it all looks like stuff you could get with the existing import/export mechanisms. I would choose (modified) UTF-8, but I understand why UCS16 is always going to be around. I agree about keeping wasm bytecode cleaner. The core plus simd stuff is such a great generalization of the ARM and X86 CPUs we mostly use. The idea of gunking it all up with DOM related stuff is distasteful.
- davexunit 2y ago
  Quote from https://wingolog.org/archives/2023/10/19/requiem-for-a-stringref 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 requirement to support fast WTF-16 code unit access will mean that we are effectively standardizing JavaScript strings. I really like stringref and hope the detractors can be convinced of its usefulness. Dealing with strings is not fun right now.
  - robocat 2y ago
    > 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<byte> objects" - https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/reference-types 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-7588daad8f05 https://medium.com/@jlouis666/erlang-string-handling-7588daa...
    - davexunit 2y ago
      Okay? Is this an argument in favor of doing nothing?
    - debugnik 2y ago
      > The Erlang string type is implemented as a single-linked-list This refers just to Erlang's string() type, not BEAM strings in general; it's just a bad default. If you're not using binaries, you're doing it wrong, and that's exactly why Elixir's strings are UTF-8 binaries.