461–470 of 943 posts
Earlier quoted context omitted.
I wouldn't be asking if there wasn't a visceral reaction from Rust devs. I must have missed previous discussions on other threads.
Is this visceral reaction in the room with us now? Edit: I have reached the bottom of the thread and still have not seen this visceral reaction mentioned by the OP.
There's more reactions here. I think devs have lost the plot, tbh.
Earlier quoted context omitted.
This is shockingly out-of-date statement by Anders. I'm not sure what's going on, I guess he's just not involved with the runtime side of .NET at all to actually know where the capability sits circa 2024/2025. But really, it's a terrible situation to be in. Especially just how worse langdev UX in Go is compared to C#, F# or Rust. No one would've batted an eye if either of those was used.
Honest q, which part is out of date and why? Thanks
> While C# does have AOT capabilities nowadays this is not as mature as Go's and not all platforms support it
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Only Android is missing from that list (marked as "Experimental"). We could argue about maturity but this is a bit subjective.
> Go also has somewhat better control over data layout
How? C# supports structs, ref structs (stack allocated only structures), explicit stack allocation (`stackalloc`), explicit struct field layouts through annotations, control over method local variable initialization, control over inlining, etc. Hell, C# even supports a somewhat limited version of borrow checking through the `scoped` keyword.
> This is meant to be something of a 1:1 port rather than a rewrite, and the old code uses plain functions and data structures without an OOP style.
C# has been consistently moving into that direction by taking more and more inspiration from F#.
The only reasonable reason would be extensive usage of structural typing which is present in TS and Go but not in C#.
Fast dev tools are awesome and I am glad the TS team is thinking deeply about dev experience, as always! One trade off is if the code for TS is no longer written in TS, that means the core team won’t be dogfooding TS day in and day out anymore, which might hurt devx in the long run. This is one of the failure modes that hurt Flow (written in OCaml), IMO. Curious how the team is thinking about this.
The issue with Flow is that it's slow, flaky and has shifted the entire paradigm multiple times making version upgrades nearly impossible without also updating your dependencies, IF your dependencies adopted the new flow version as well. Otherwise you're SOL. As a result the amount of libraries that ship flow types has absolutely dwindled over the years, and now typescript has completely taken over.
Hi folks, Daniel Rosenwasser from the TypeScript team here. We're obviously very excited to announce this! RyanCavanaugh (our dev lead) and I are around to answer any quick questions you might have. You can also tune in to the Discord AMA mentioned in the blog this upcoming Thursday.
(FWIW, It must have been a very well thought out rationale.)
Edit: watched the revenant clip from the GH discussion- makes sense. Maybe push NativeAoT to be as good?
I am (positively) surprised Hejlsberg has not used this opportunity to push C#: a rarity in the software world where people never let go of their darlings. :)
Earlier quoted context omitted.
Not sure if it does but the video linked in the post might answer your question? I think he is compiling vscode which includes Monaco editor which is where they are getting 10x faster stat. (I might be wrong here.) [0] [0] https://youtu.be/pNlq-EVld70?feature=shared&t=112
Yeah I saw that but will they maintain a browser compatible version is another question
That is a good question.
The post title is a bit misleading. It should say a 10x faster build time, or a 10x faster TypeScript compiler . tsc (compiler) is 10x faster, but not the final TS program runtime. Still an amazing feat! But doom will not run faster "To meet those goals, we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by…
I don't think this is misleading for anyone familiar with Typescript. Typescript itself has no impact on performance, and it is known that the compilation and type-checking speed is often a problem. So I immediately assumed that it was about exactly that.
I don't think that is too far fetched either since typescript already has most of the type information.
I'd like to see if it makes a difference to the version of DOOM that runs in the TypeScript type system. https://news.ycombinator.com/item?id=43184291 https://www.youtube.com/watch?v=0mCsluv5FXA
Earlier quoted context omitted.
Those are javascript runtimes, not TypeScript runtimes. The point stands. If you don't know enough about TypeScript to understand that TypeScript is not a runtime, I'm not sure why you would care about TypeScript being faster (in either case).
if typescript code execution got that much faster it might be a reason for someone to look into the language even if they knew nothing about it.
Earlier quoted context omitted.
I love Rust, but you can play exactly the same game with Rust: https://github.com/Speykious/cve-rs
I mean, no? That's basically a known bug in Rust's compiler, specifically it's a soundness hole in type checking, and you'd basically never write it by accident - go read the guts of it for yourself if you think you might accidentally do this. At some point a next generation solver will make this not compile, and people will probably invent an even weirder edge case for that solver. Whereas the Go example is just how…
Earlier quoted context omitted.
It’s a political anti-benefit in most of the open-source world. And C# is not considered a high quality runtime once you leave Windows.
> And C# is not considered a high quality runtime once you leave Windows. By who?