5 ms·

Haha TS7 is the next biggest example of, "Let's just do a line by line port to another language instead of seriously examining our architecture"

zarzavat 3mo ago
Indeed as much I dislike the approach Bun took, at least the port appears to be working. TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM.
- nicce 3mo ago
  > TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM. Is there a huge need to run that typechecking on browsers?
  - zarzavat 3mo ago
    Yes, in the Monaco editor (https://microsoft.github.io/monaco-editor/ https://microsoft.github.io/monaco-editor/). It's not just typechecking, the typescript library is also the reference parser for TypeScript and reference emit. Emitting JS from TypeScript is non-trivial and non-local. It's not just in browsers, you might want to run the typescript library on the edge or in some restricted environment where JS/WASM is OK but native code is not. You may want to use the typescript library as a dependency in your own package. TypeScript becoming non-pure JS means that your library also becomes non-pure JS.
    - anon7000 3mo ago
      NodeJS can strip types internally without a straight TS dependency. I don’t think this matters, TS was a huge bottleneck for many build pipelines because it never parallelized well
      - zarzavat 3mo ago
        Type stripping is not the same as emit, it only gets you a subset of TypeScript. Fine if you're running your own code, not fine if you want to run arbitrary TypeScript.
  - conartist6 3mo ago
    First, yes, the demand to be able to code natively in a browser is, I have reason to suspect, very large. It's just difficult to measure demand when nobody has ever offered a really compelling product. In engineering terms it's like getting a full-scale reading. The real level could be 1% above a full-scale reading, or the real level could be 100x higher than the full-scale reading. Secondly, WASM isn't the right target for the browser anyway, JS and the DOM have to be what you consider "native", for the most rigorous UI projects at least (which building an IDE is). If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates.
    - skydhash 3mo ago
      > If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates. calibre (with python+Qt) begs to differ. And I believe VLC runs on every current platforms. There's also Code::Blocks and Blender. Cross-platform UI is not rocket-science.
      - conartist6 3mo ago
        All great examples, but ones that do require installation. Their website is just where you download the product, I'm talking about making the website the product.
  - shepherdjerred 3mo ago
    It is incredibly useful
  - egeozcan 3mo ago
    I think running a typechecker on its target platforms has huge benefits.
- norman784 3mo ago
  Didn't WASM got a GC proposal that Go and other managed languages can use it? So it might be an issue in most browsers right now, but soon it might not.
deleted 3mo ago
[deleted]
raincole 3mo ago
This is the correct approach (I dare to say the only correct approach) when porting to another language. You can examining the architecture later.
- dirtbag__dad 3mo ago
  If you can lock down a test suite that ensures parity, then who cares what shape the lift ultimately looks like. A full rewrite in different language that fails to be idiomatic is a step backward operationally, even if you stand to gain on issues the new language just eats for free
  - yathaid 3mo ago
    I like your fair-mindedness but for folks who are anti-LLM-anything, your argument is not the point. Evidence: see the amount of nonsense in the postgres rewritten in Rust story - https://news.ycombinator.com/item?id=48841676 https://news.ycombinator.com/item?id=48841676 where there are two contradictory claims made: "postgres is so stable I will never trust a rewrite." "covering 100% of postgres regression suite doesn't guarantee you have replicated every behavior." Folks who are okay with LLMs think the regression test suite is the spec and is the guarantee of stability. How else can it be? If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you? Folks who are against seem to imagine a platonic ideal of PG which conveniently is the original PG implementation by tautological definition. So no rewrite can ever meet their bar.
    - consp 3mo ago
      > If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you? Decades of intrinsic knowledge. Which a rewrite lacks. imho the issue is the language used. AI rewrites are cheap and cheap exercises require a great deal of scrutiny and proof of correctness. Simply using regressions test lacks the intrinsic knowledge of a decades old codebase stuck in developers minds. Claiming a rewrite is better because it passes all tests is a flex, a new version requires a boatload of evidence for people to accept it as an improvement and not just "passes tests, written in rust via LLM so it must be better". Run it in production for a year in a sufficiently large system and you might be somewhere.

zarzavat 3mo ago

Indeed as much I dislike the approach Bun took, at least the port appears to be working. TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM.

nicce 3mo ago
> TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM. Is there a huge need to run that typechecking on browsers?
- zarzavat 3mo ago
  Yes, in the Monaco editor (https://microsoft.github.io/monaco-editor/ https://microsoft.github.io/monaco-editor/). It's not just typechecking, the typescript library is also the reference parser for TypeScript and reference emit. Emitting JS from TypeScript is non-trivial and non-local. It's not just in browsers, you might want to run the typescript library on the edge or in some restricted environment where JS/WASM is OK but native code is not. You may want to use the typescript library as a dependency in your own package. TypeScript becoming non-pure JS means that your library also becomes non-pure JS.
  - anon7000 3mo ago
    NodeJS can strip types internally without a straight TS dependency. I don’t think this matters, TS was a huge bottleneck for many build pipelines because it never parallelized well
    - zarzavat 3mo ago
      Type stripping is not the same as emit, it only gets you a subset of TypeScript. Fine if you're running your own code, not fine if you want to run arbitrary TypeScript.
- conartist6 3mo ago
  First, yes, the demand to be able to code natively in a browser is, I have reason to suspect, very large. It's just difficult to measure demand when nobody has ever offered a really compelling product. In engineering terms it's like getting a full-scale reading. The real level could be 1% above a full-scale reading, or the real level could be 100x higher than the full-scale reading. Secondly, WASM isn't the right target for the browser anyway, JS and the DOM have to be what you consider "native", for the most rigorous UI projects at least (which building an IDE is). If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates.
  - skydhash 3mo ago
    > If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates. calibre (with python+Qt) begs to differ. And I believe VLC runs on every current platforms. There's also Code::Blocks and Blender. Cross-platform UI is not rocket-science.
    - conartist6 3mo ago
      All great examples, but ones that do require installation. Their website is just where you download the product, I'm talking about making the website the product.
- shepherdjerred 3mo ago
  It is incredibly useful
- egeozcan 3mo ago
  I think running a typechecker on its target platforms has huge benefits.
norman784 3mo ago
Didn't WASM got a GC proposal that Go and other managed languages can use it? So it might be an issue in most browsers right now, but soon it might not.

deleted 3mo ago

[deleted]

raincole 3mo ago

This is the correct approach (I dare to say the only correct approach) when porting to another language. You can examining the architecture later.

dirtbag__dad 3mo ago
If you can lock down a test suite that ensures parity, then who cares what shape the lift ultimately looks like. A full rewrite in different language that fails to be idiomatic is a step backward operationally, even if you stand to gain on issues the new language just eats for free
- yathaid 3mo ago
  I like your fair-mindedness but for folks who are anti-LLM-anything, your argument is not the point. Evidence: see the amount of nonsense in the postgres rewritten in Rust story - https://news.ycombinator.com/item?id=48841676 https://news.ycombinator.com/item?id=48841676 where there are two contradictory claims made: "postgres is so stable I will never trust a rewrite." "covering 100% of postgres regression suite doesn't guarantee you have replicated every behavior." Folks who are okay with LLMs think the regression test suite is the spec and is the guarantee of stability. How else can it be? If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you? Folks who are against seem to imagine a platonic ideal of PG which conveniently is the original PG implementation by tautological definition. So no rewrite can ever meet their bar.
  - consp 3mo ago
    > If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you? Decades of intrinsic knowledge. Which a rewrite lacks. imho the issue is the language used. AI rewrites are cheap and cheap exercises require a great deal of scrutiny and proof of correctness. Simply using regressions test lacks the intrinsic knowledge of a decades old codebase stuck in developers minds. Claiming a rewrite is better because it passes all tests is a flex, a new version requires a boatload of evidence for people to accept it as an improvement and not just "passes tests, written in rust via LLM so it must be better". Run it in production for a year in a sufficiently large system and you might be somewhere.