6 ms·

[flagged]

by Starlord2048 2y ago

[flagged]

ninetyninenine 2y ago
I wish there was a language like rust without the borrow checking and lifetimes that was also popular and lives in the same area as go. Because I think go is actually the best language in this category but it’s only the best because there is nothing else. All in all golang is not an elegant language.
- michaelsbradley 2y ago
  It’s not popular compared to Go/Rust, but many find Nim scratches that itch: https://nim-lang.org/ https://nim-lang.org/
  - pclmulqdq 2y ago
    Zig is another popular neo-language in the same rough space.
- sapiogram 2y ago
  Rust loses a lot of its nice properties without borrow checking and lifetimes, though. For example, resources no longer get cleaned up automatically, and the compiler no longer protects you against data races. Which in turn makes the entire language memory unsafe.
  - throw-the-towel 2y ago
    OTOH it would still have Rust's sane type system and all the nice features it makes possible.
    - nine_k 2y ago
      OCaml and Haskell already have that nice type system (and even more nice). If OCaml's syntax bothers you, there is Reason [1] which is a different frontend to the same compiler suite. Also in this space is Gleam [2] which targets Erlang / OTP, if high concurrency and fault tolerance is your cup of tea. [1]: https://reasonml.github.io/ https://reasonml.github.io/ [2]: https://gleam.run/ https://gleam.run/
  - SkiFire13 2y ago
    I believe OP meant to give it a GC like in Go, while keeping other features from Rust from enums/match/generics/traits/etc etc. This should prevent most of the memory safety issues, though data races could still be tricky (e.g. Go is memory unsafe due to data races)
- noelwelsh 2y ago
  O'Caml is similar, now that it has multicore. Scala is also similar, though the native code side (https://scala-native.org/en/stable/ https://scala-native.org/en/stable/) is not nearly as well developed as the JVM side.
  - ninetyninenine 2y ago
    The problem with O'Caml is it won't get popular because people are afraid of FP. But I would be totally down to use it.
- duped 2y ago
  That language is Rust, though.
nindalf 2y ago
> is this the beginning of a larger trend where JS/TS tooling migrates to native implementations No, it is not. It is a continuation of an existing trend You may be interested in esbuild (https://github.com/evanw/esbuild https://github.com/evanw/esbuild), turborepo (https://github.com/vercel/turborepo https://github.com/vercel/turborepo), biome-js (https://github.com/biomejs/biome https://github.com/biomejs/biome) are all native reimplementations of existing projects in JS/TS. esbuild is written in Go, the others in Rust. > reveals something deeper: Microsoft prioritized shipping a working solution over language politics Its not that "deep". I don't see the politics either way, there are clearly successful projects using both Go and Rust. The only people who see "politics" are those who see people disagreeing, are unable to understand the substance of the disagreement and decide "ah, it's just politics".
register 2y ago
I don't see why Go deployment model is superior to C#. You can easily build native binaries in C# as well nowadays.
- abdusco 2y ago
  Smaller binary sizes for easier + cheaper distribution might be a factor.
  - gwbas1c 2y ago
    You can make very small binaries in C# if you want to. But, the team posted their rationale for Go here: https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411
- gwbas1c 2y ago
  I get the impression that, because Go has a lot of similar semantics to Typescript, it was easier to port to Go than other languages. From https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411 > Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable. > We also have an unusually large amount of graph processing, specifically traversing trees in both upward and downward walks involving polymorphic nodes. Go does an excellent job of making this ergonomic, especially in the context of needing to resemble the JavaScript version of the code. Personally, I'm a big believer in choosing the right language for the job. C# is a great language, and often is "good enough" for many jobs. (I've done it for 20 years.) That doesn't mean it's always the best choice for the job. Likewise, sometimes picking a "familiar language" for a target audience is better than picking a personal favorite.
- guappa 2y ago
  Come on… 1 statically linked executable and it can cross build incredibly easily. There's no comparison even.
noelwelsh 2y ago
I don't think this is accurate. Javascript is not slow because of GC or JIT (the JVM is about twice as fast in benchmarks; Go has a GC) but because JS as a language is not designed for performance. Despite all the work that V8 does it cannot perform enough analysis to recover desirable performance. The simplest example to explain is the lack of machine numbers (e.g. ints). JS doesn't have any representation for this so V8 does a lot of work to try to figure out when a number can be represented as an int, but it won't catch all cases. As for "working solution over language politics" you are entirely pulling that out of thin air. It's not supported by the article in any way. There is discussion at https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411 that mentions different points.
- dleeftink 2y ago
  I think JS can really zoom if you let it. Hamsters.js, GPU.js, taichi.js, ndarray, arquero, S.js, are all solid foundations for doing things really efficiently. Sure, not 'native' performance or on the compile side, but having their computational models in mind can really let you work around the language's limitations.
  - jsheard 2y ago
    JS can be pretty fast if you let it, but the problem is the fastest path is extremely unergonomic. If you always take the fastest possible path you end up more or less writing asm.js by hand, or a worse version of C that doesn't even have proper structs.
    - dleeftink 2y ago
      I find these userland libraries particularly effective, because you'll never leave JS land, conveniently abstracting over Workers, WebGL/WebGPU and WASM.
- nine_k 2y ago
  JS, interestingly, has a notion of integers, but only in the form of integer arrays, like Int16Array. I wonder if Typescript could introduce integer type(s) that a direct TS -> native code compiler (JIT or AOT) could use. Since TS becomes valid JS if all type annotations are removed, such numbers would just become normal JS numbers from the POV of a JS runtime which does not understand TS.
christianqchung 2y ago
This is not accusatory, but do you write your comments with AI? I checked your profile and someone else had the same question a few days ago. It's the persistent structure of "it isn't X – it's Y" with the em dash (– not -) that makes me wonder this. Nothing to add to your comment otherwise, sorry.
- nindalf 2y ago
  That would explain a lot.
- niederman 2y ago
  You know, some humans use the correct dash too...
- mannykoum 2y ago
  Sorry for being pedantic but they are using an en dash (–) not an em dash (—) which is a little strange because the latter is usually the one meant for adding information in secondary sentences—like commas and and parentheses. In addition, in most styles, you're not supposed to add spaces around it. So, I don't think the comment is AI-generated for this reason.
  - CharlesW 2y ago
    "The en-dash is also increasingly used to replace the long dash ('—', also called an em dash or em rule). When using it to replace a long dash, spaces are needed either side of it – like so." https://en.wikipedia.org/wiki/En_(typography) https://en.wikipedia.org/wiki/En_(typography)
  - christianqchung 2y ago
    You're right, oops. I agree with your reasoning (comment still gives off slop vibes but that's unprovable). But the parent has been flagged, so I'm not sure if that means admins/dang has agreed with me or if it was flagged for another reason.
    - 2y ago
gherkinnn 2y ago
It *almost* sounds like you're telling the authors, one of which posted this, what their motivations are.
rvz 2y ago
> When a language team abandons self-hosting (TS in TS) for raw performance (Go), it signals we've hit fundamental limits in JS/TS for systems programming. I hope you really mean for "userspace tools / programs" which is what these dev-tools are, and not in the area of device drivers, since that is where "systems programming" is more relevant. I don't know why one would choose JS or TS for "systems programming", but I'm assuming you're talking about user-space programs. But really, those who know the difference between a compiled language and a VM-based language know the obvious fundamental performance limitations of developer tools written in VM-based languages like JS or TS and would avoid them as they are not designed for this use case.
- pjmlp 2y ago
  Back in my day, writing compilers was part of systems programming.
  - Yoric 2y ago
    Yeah, the term has changed meaning several times. Early on, "systems programmer" meant basically what we call a "developer" now (by opposition to a programmer or a researcher).
    - sethaurus 2y ago
      At that time, what would have been the distinction between "programmer" and "developer"?
      - Yoric 2y ago
        If my memory serves, the "programmer" was essentially a mathematician, working on a single algorithm, while a "system developer" was building an entire system around it.
madeofpalk 2y ago
> it signals we've hit fundamental limits in JS/TS for systems programming Really is this a surprise to anyone? I don't think anyone thinks JS is suitable for 'systems programming'. Javascript is the language we have for the browser - there's no value in debating it's merits when it's the only option. Javascript on the server has only ever accrued benefits from being the same language as the browser.
the_mitsuhiko 2y ago
> The Go choice over Rust/C# reveals something deeper: Microsoft prioritized shipping a working solution over language politics. Go's simplicity (compared to Rust) and deployment model (compared to C#) won the day. I'm not sure that this is particularly accurate for the Rust case. The goal of this project was to perform a 1:1 port from TypeScript to a faster language. The existing codebase assumes a garbage collector so Rust is not really a realistic option here. I would bet they picked GCed languages only.
- pc86 2y ago
  I can't imagine the devs at Microsoft have any issues with C#'s "deployment model."
  - Yoric 2y ago
    I can imagine C# being annoying to integrate into some CIs, for instance. Go fits a sweet spot, with its fast compiler and usually limited number of external dependencies.
  - giancarlostoro 2y ago
    I assume they picked Go because the binaries can be very stand alone.
- whazor 2y ago
  Also explained in the FAQ: https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411
sebzim4500 2y ago
>The Go choice over Rust/C# reveals something deeper: Microsoft prioritized shipping a working solution over language politics. Go's simplicity (compared to Rust) and deployment model (compared to C#) won the day. Even Anders Hejlsberg – father of C# – chose Go for pragmatic reasons! I don't follow. If they had picked Rust over Go why couldn't you also argue that they are prioritising shipping a working solution over language politics. It seems like a meaningless statement.
scotty79 2y ago
> Go's simplicity I think they went for Go mostly because of memory management, async and syntactic similarity to interpreted languages which makes total sense for a port.
nine_k 2y ago
Go with parametric types is already a reasonably expressive language. Much more expressive than C in which a number of compilers has been written, at least initially; not everyone had the luxury of using OCaml or Haskell. There is already a growing number of native-code tools of the JS/TS ecosystem, like esbuild or swc. Maybe we should expect attempts of native AOT compilation for TS itself, to run on the server side, much like C# has an AOC native-code compiler.

[flagged]

I wish there was a language like rust without the borrow checking and lifetimes that was also popular and lives in the same area as go. Because I think go is actually the best language in this category but it’s only the best because there is nothing else. All in all golang is not an elegant language.

michaelsbradley 2y ago
It’s not popular compared to Go/Rust, but many find Nim scratches that itch: https://nim-lang.org/ https://nim-lang.org/
- pclmulqdq 2y ago
  Zig is another popular neo-language in the same rough space.
sapiogram 2y ago
Rust loses a lot of its nice properties without borrow checking and lifetimes, though. For example, resources no longer get cleaned up automatically, and the compiler no longer protects you against data races. Which in turn makes the entire language memory unsafe.
- throw-the-towel 2y ago
  OTOH it would still have Rust's sane type system and all the nice features it makes possible.
  - nine_k 2y ago
    OCaml and Haskell already have that nice type system (and even more nice). If OCaml's syntax bothers you, there is Reason [1] which is a different frontend to the same compiler suite. Also in this space is Gleam [2] which targets Erlang / OTP, if high concurrency and fault tolerance is your cup of tea. [1]: https://reasonml.github.io/ https://reasonml.github.io/ [2]: https://gleam.run/ https://gleam.run/
- SkiFire13 2y ago
  I believe OP meant to give it a GC like in Go, while keeping other features from Rust from enums/match/generics/traits/etc etc. This should prevent most of the memory safety issues, though data races could still be tricky (e.g. Go is memory unsafe due to data races)
noelwelsh 2y ago
O'Caml is similar, now that it has multicore. Scala is also similar, though the native code side (https://scala-native.org/en/stable/ https://scala-native.org/en/stable/) is not nearly as well developed as the JVM side.
- ninetyninenine 2y ago
  The problem with O'Caml is it won't get popular because people are afraid of FP. But I would be totally down to use it.
duped 2y ago
That language is Rust, though.

nindalf 2y ago

> is this the beginning of a larger trend where JS/TS tooling migrates to native implementations No, it is not. It is a continuation of an existing trend You may be interested in esbuild (https://github.com/evanw/esbuild https://github.com/evanw/esbuild), turborepo (https://github.com/vercel/turborepo https://github.com/vercel/turborepo), biome-js (https://github.com/biomejs/biome https://github.com/biomejs/biome) are all native reimplementations of existing projects in JS/TS. esbuild is written in Go, the others in Rust. > reveals something deeper: Microsoft prioritized shipping a working solution over language politics Its not that "deep". I don't see the politics either way, there are clearly successful projects using both Go and Rust. The only people who see "politics" are those who see people disagreeing, are unable to understand the substance of the disagreement and decide "ah, it's just politics".

I don't see why Go deployment model is superior to C#. You can easily build native binaries in C# as well nowadays.

abdusco 2y ago
Smaller binary sizes for easier + cheaper distribution might be a factor.
- gwbas1c 2y ago
  You can make very small binaries in C# if you want to. But, the team posted their rationale for Go here: https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411
gwbas1c 2y ago
I get the impression that, because Go has a lot of similar semantics to Typescript, it was easier to port to Go than other languages. From https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411 > Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable. > We also have an unusually large amount of graph processing, specifically traversing trees in both upward and downward walks involving polymorphic nodes. Go does an excellent job of making this ergonomic, especially in the context of needing to resemble the JavaScript version of the code. Personally, I'm a big believer in choosing the right language for the job. C# is a great language, and often is "good enough" for many jobs. (I've done it for 20 years.) That doesn't mean it's always the best choice for the job. Likewise, sometimes picking a "familiar language" for a target audience is better than picking a personal favorite.
guappa 2y ago
Come on… 1 statically linked executable and it can cross build incredibly easily. There's no comparison even.

noelwelsh 2y ago

I don't think this is accurate. Javascript is not slow because of GC or JIT (the JVM is about twice as fast in benchmarks; Go has a GC) but because JS as a language is not designed for performance. Despite all the work that V8 does it cannot perform enough analysis to recover desirable performance. The simplest example to explain is the lack of machine numbers (e.g. ints). JS doesn't have any representation for this so V8 does a lot of work to try to figure out when a number can be represented as an int, but it won't catch all cases. As for "working solution over language politics" you are entirely pulling that out of thin air. It's not supported by the article in any way. There is discussion at https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411 that mentions different points.

dleeftink 2y ago
I think JS can really zoom if you let it. Hamsters.js, GPU.js, taichi.js, ndarray, arquero, S.js, are all solid foundations for doing things really efficiently. Sure, not 'native' performance or on the compile side, but having their computational models in mind can really let you work around the language's limitations.
- jsheard 2y ago
  JS can be pretty fast if you let it, but the problem is the fastest path is extremely unergonomic. If you always take the fastest possible path you end up more or less writing asm.js by hand, or a worse version of C that doesn't even have proper structs.
  - dleeftink 2y ago
    I find these userland libraries particularly effective, because you'll never leave JS land, conveniently abstracting over Workers, WebGL/WebGPU and WASM.
nine_k 2y ago
JS, interestingly, has a notion of integers, but only in the form of integer arrays, like Int16Array. I wonder if Typescript could introduce integer type(s) that a direct TS -> native code compiler (JIT or AOT) could use. Since TS becomes valid JS if all type annotations are removed, such numbers would just become normal JS numbers from the POV of a JS runtime which does not understand TS.

christianqchung 2y ago

This is not accusatory, but do you write your comments with AI? I checked your profile and someone else had the same question a few days ago. It's the persistent structure of "it isn't X – it's Y" with the em dash (– not -) that makes me wonder this. Nothing to add to your comment otherwise, sorry.

nindalf 2y ago
That would explain a lot.
niederman 2y ago
You know, some humans use the correct dash too...
mannykoum 2y ago
Sorry for being pedantic but they are using an en dash (–) not an em dash (—) which is a little strange because the latter is usually the one meant for adding information in secondary sentences—like commas and and parentheses. In addition, in most styles, you're not supposed to add spaces around it. So, I don't think the comment is AI-generated for this reason.
- CharlesW 2y ago
  "The en-dash is also increasingly used to replace the long dash ('—', also called an em dash or em rule). When using it to replace a long dash, spaces are needed either side of it – like so." https://en.wikipedia.org/wiki/En_(typography) https://en.wikipedia.org/wiki/En_(typography)
- christianqchung 2y ago
  You're right, oops. I agree with your reasoning (comment still gives off slop vibes but that's unprovable). But the parent has been flagged, so I'm not sure if that means admins/dang has agreed with me or if it was flagged for another reason.
  - 2y ago

gherkinnn 2y ago

It *almost* sounds like you're telling the authors, one of which posted this, what their motivations are.

rvz 2y ago

> When a language team abandons self-hosting (TS in TS) for raw performance (Go), it signals we've hit fundamental limits in JS/TS for systems programming. I hope you really mean for "userspace tools / programs" which is what these dev-tools are, and not in the area of device drivers, since that is where "systems programming" is more relevant. I don't know why one would choose JS or TS for "systems programming", but I'm assuming you're talking about user-space programs. But really, those who know the difference between a compiled language and a VM-based language know the obvious fundamental performance limitations of developer tools written in VM-based languages like JS or TS and would avoid them as they are not designed for this use case.

pjmlp 2y ago
Back in my day, writing compilers was part of systems programming.
- Yoric 2y ago
  Yeah, the term has changed meaning several times. Early on, "systems programmer" meant basically what we call a "developer" now (by opposition to a programmer or a researcher).
  - sethaurus 2y ago
    At that time, what would have been the distinction between "programmer" and "developer"?
    - Yoric 2y ago
      If my memory serves, the "programmer" was essentially a mathematician, working on a single algorithm, while a "system developer" was building an entire system around it.

madeofpalk 2y ago

> it signals we've hit fundamental limits in JS/TS for systems programming Really is this a surprise to anyone? I don't think anyone thinks JS is suitable for 'systems programming'. Javascript is the language we have for the browser - there's no value in debating it's merits when it's the only option. Javascript on the server has only ever accrued benefits from being the same language as the browser.

the_mitsuhiko 2y ago

> The Go choice over Rust/C# reveals something deeper: Microsoft prioritized shipping a working solution over language politics. Go's simplicity (compared to Rust) and deployment model (compared to C#) won the day. I'm not sure that this is particularly accurate for the Rust case. The goal of this project was to perform a 1:1 port from TypeScript to a faster language. The existing codebase assumes a garbage collector so Rust is not really a realistic option here. I would bet they picked GCed languages only.

pc86 2y ago
I can't imagine the devs at Microsoft have any issues with C#'s "deployment model."
- Yoric 2y ago
  I can imagine C# being annoying to integrate into some CIs, for instance. Go fits a sweet spot, with its fast compiler and usually limited number of external dependencies.
- giancarlostoro 2y ago
  I assume they picked Go because the binaries can be very stand alone.
whazor 2y ago
Also explained in the FAQ: https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411

sebzim4500 2y ago

>The Go choice over Rust/C# reveals something deeper: Microsoft prioritized shipping a working solution over language politics. Go's simplicity (compared to Rust) and deployment model (compared to C#) won the day. Even Anders Hejlsberg – father of C# – chose Go for pragmatic reasons! I don't follow. If they had picked Rust over Go why couldn't you also argue that they are prioritising shipping a working solution over language politics. It seems like a meaningless statement.

scotty79 2y ago

> Go's simplicity I think they went for Go mostly because of memory management, async and syntactic similarity to interpreted languages which makes total sense for a port.

nine_k 2y ago

Go with parametric types is already a reasonably expressive language. Much more expressive than C in which a number of compilers has been written, at least initially; not everyone had the luxury of using OCaml or Haskell. There is already a growing number of native-code tools of the JS/TS ecosystem, like esbuild or swc. Maybe we should expect attempts of native AOT compilation for TS itself, to run on the server side, much like C# has an AOC native-code compiler.