Comment by tossandthrow

Comment by tossandthrow 11 days ago

8 replies

View on Hacker News

And this is definitely a problem.

Had I had the opportunity to choose a language across the entire stack with mature wide adopted frameworks and libraries, I had done it.

Had there been something line Rust, Go, Java, C#, etc. that would work end to end, that would have been amazing.

In practice, even the weak safety typescript provides catches so many bugs before they hit production that it is indeed worth it - I have more than 140k LOCs of Typescript in production, and that would not be manageable without types.

CharlieDigital 11 days ago

    >  I have more than 140k LOCs of Typescript in production, and that would not be manageable without types
The Svelte team achieved it with JSDoc. Google's JS style guide also focuses on JSDoc for the same reasons[0].

And to be just a tad pedantic: you have JS in production; your TS is only in dev.

    > Go, Java, C#, etc. that would work end to end, that would have been amazing.
It's not that you can't; it's that you choose not to (and yes, generally for good and valid reasons). There are end-to-end solutions for C# (e.g. Blazor), for example, that are perfectly fine depending on your use case (not great for all use cases). Fable is another example using F#[1]

There are also libraries like Bootsharp[2] that are doing interesting things, IMO, and has some of the same energy as OP's project (moving the typing and logic into a runtime that supports runtime static types and interfacing minimally with JS)

[0] https://google.github.io/styleguide/jsguide.html#jsdoc

[1] https://fable.io/docs/

[2] https://sharp.elringus.com/

Reply View 7 replies
  • tossandthrow 11 days ago

    > you have JS in production; your TS is only in dev.

    As my sibling says, this is wrong. We indeed have TS in production.

    Even for the parts that are being compiled to JS: You wouldn't say: You can not have C++ in production, only binaries.

    The fact is that we don't write any JS as a part of our platform.

    > It's not that you can't; it's that you choose not to

    I think I made that quite clear in my comment.

    > a language across the entire stack with mature wide adopted frameworks and libraries

    Reply View 4 replies
    • CharlieDigital 11 days ago

          > Even for the parts that are being compiled to JS: You wouldn't say: You can not have C++ in production, only binaries.
      I would say that because it can be decompiled; the type information is still present. Same with C#. I can decompile the binary and still see the type information.

      The process of going from TS to JS is lossy; you cannot get back the type information.

      I would absolutely say "I have C++ in production" or "I have C# in production" but not say "I have TypeScript in production". "We build our app with TypeScript" is accurate, but it is transpiled -- not compiled -- into JavaScript. Your Node.js server then interprets that JavaScript and executes C++.

      Reply View 3 replies
      • tossandthrow 11 days ago

        That is not right, When you compile to binaries, you do type erasure in CPP, som of the stuff can not be reconstructed or inferred, especially when using o flags.

        JS -> TS is easy, you just re-anotate with `: any` everywhere.

        Anyways, you are word juggling now.

        Reply View 1 reply
        • Nijikokun 11 days ago

          Type definitions are definitely compiled with CPP. Type erasure only happens with polymorphism types. You can actually view the types with ghidra.

          Reply View 0 replies
      • unchar1 11 days ago

        > Your Node.js server then interprets that JavaScript and executes C++.

        Umm...no? V8 specifically compiles it into machine code directly.

        There used to be a pseudo-translation layer in the CrankShaftScript days, but that hasn't been true in almost a decade.

        > I can decompile the binary and still see the type information.

        Also no. The de-compiler can _infer_ the types, much like how V8 tries to infer the type. But the actual type information is gone.

        Even in languages like Java where most of the type information is preserved, some things are still lost (e.g. generic methods with dynamicinvoke)

        Reply View 0 replies
  • gcau 11 days ago

    >And to be just a tad pedantic: you have JS in production; your TS is only in dev.

    This is not even pedantic, it's wrong. You have JS/TS in both dev and prod, with javascript being the actual runtime code in both, and typescript checking your code at build time in both. If you're running javascript compiled/checked by , and written in, typescript, it's not uncommon or unreasonable to call it typescript.

    Reply View 0 replies
  • mubou 11 days ago

    > Google's JS style guide also focuses on JSDoc for the same reasons

    Google uses TS internally. Any JS is strictly legacy code at this point. The link you posted even says this at the top:

    > Please note: This guide is no longer being updated. Google recommends migrating to TypeScript, and following the TypeScript guide.

    Also, Google's style guides are not really authoritative outside of Google. They are for some people, who choose to adopt them as their own, but you really shouldn't point to them as the end-all-be-all argument-stopper. Google has a lot of its own idiosyncrasies. Their C# style guide puts braces on the same line, for example, because Google primarily uses Java internally.

    Reply View 0 replies