-
> By far the most important aspect is that we need to keep the new codebase as compatible as possible, both in terms of semantics and in terms of code structure. We expect to maintain both codebases for quite some time going forward. Languages that allow for a structurally similar codebase offer a significant boon for anyone making code changes because we can easily port changes between the two codebases. In contrast, languages that require fundamental rethinking of memory management, mutation, data structuring, polymorphism, laziness, etc., might be a better fit for a ground-up rewrite, but we're undertaking this more as a port that maintains the existing behavior and critical optimizations we've built into the language. Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.
--https://github.com/microsoft/typescript-go/discussions/411
I haven't looked at the tsc codebase. I do currently use Golang at my job and have used TypeScript at a previous job several years ago.
I'm surprised to hear that idiomatic Golang resembles the existing coding patterns of the tsc codebase. I've never felt that idiomatic code in Golang resembled idiomatic code in TypeScript. Notably, sum types are commonly called out as something especially useful in writing compilers.
Is there something special about the existing tsc codebase, or does the statement about idiomatic Golang resembling the existing codebase something you could say about most TypeScript codebases?
-
InfluxDB
InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.
-
> other well-adopted tools in the ecosystem use Go
esbuild is the most well-known/used project, probably beats all other bundlers combined. I can't remember anything else off the top of my head.
https://github.com/evanw/esbuild
-
There are some external projects that have tried to port tsc to native. stc[0], for instance, was one. Iirc it started out in Go since it had a more comparable type system (they both use duck typing) making it easier to do one-to-one conversions of code from one language to the other. I’m not totally sure why it ended up pivoting to rust.
[0]: https://github.com/dudykr/stc
-
The major roadblock for WasmGC in Golang at the moment is WasmGC does not support interior pointers, which Go requires - https://github.com/golang/go/issues/63904#issuecomment-25852...
-
I personally find Go miles easier than Rust.
Is this the ultimate reason,Go is fast enough without being overally difficult. I'm humbly open to being wrong.
While I'm here, any reason Microsoft isn't sponsoring a solid open source game engine.
Even a bit of support for Godot's C#( help them get it working on web), would be great.
Even better would be a full C# engine with support for web assembly.
https://github.com/godotengine/godot/issues/70796
-
I love Rust, but you can play exactly the same game with Rust: https://github.com/Speykious/cve-rs
-
turborepo
Discontinued Incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust – including Turborepo and Turbopack. [Moved to: https://github.com/vercel/turbo]
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
biome
A toolchain for web projects, aimed to provide functionalities to maintain them. Biome offers formatter and linter, usable via CLI and LSP.
-
> I mean, I can't think of a time a high profile project written in a lower level representation got ported to a higher level language.
Prisma is currently being rewritten from Rust to TypeScript.
> Yet projects inevitably get to the stage where a more native representation wins out.
I would be careful about extrapolating the performance gains achieved by the Go TypeScript port to non-compiler use cases. A compiler is perhaps the worst use case for a language like JS, because it is both (as Anders Hejlsberg refers to it) an "embarassingly parallel task" (because each source file can be parsed independently), but also requires the results of the parsing step to be aggregated and shared across multiple threads (which requires shared memory multithreading). Over half of the performance gains can be attributed to being able to spin up a separate goroutine to parse each source file. Anders explains it perfectly here: https://www.youtube.com/watch?v=ZlGza4oIleY&t=2027s
We might eventually get shared memory multithreading in JS via the Structs proposal [1], but that remains to be seen.
[1] https://github.com/tc39/proposal-structs?tab=readme-ov-file
-
> Cue rust devotees in 3, 2, ..
If you are a rust devotee, you can use https://github.com/FractalFir/rustc_codegen_clr to compile your rust code to the .NET runtime. The project is still in the works but support is said to be about 95% complete.
-
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/
[2]: https://gleam.run/
-
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/
[2]: https://gleam.run/
-
For previous attempts at doing this in rust, see:
1. stc [https://github.com/dudykr/stc] - Abandoned [https://github.com/swc-project/swc/issues/571#issuecomment-1915966297] -
2. ezno [https://github.com/kaleidawave/ezno] - In active development. Does not have the goal of 1:1 parity to tsc.
-
runtimelab
This repo is for experimentation and exploring new ideas that may or may not make it into the main dotnet/runtime repo.
I am holding out hope for NativeAOT-LLVM https://github.com/dotnet/runtimelab/tree/feature/NativeAOT-...
-
Overly expressive type systems have way more potential for footguns than simple type systems. In fact, I would say that overly expressive type systems make it easy to create unmaintainable code (still waiting on this showstopping bug which nobody can debug because it uses overly expressive types in TS: https://github.com/openapi-ts/openapi-typescript/issues/1769)
-
If you squint, Porffor[1] might end up being something like that.
It doesn't use type hints yet, and the difficulty there is that you'd need a sound type system in order to rely on the types. You may be able to use type hints to generate optimized and fallback functions, with type guards, but that doesn't exist yet and it sounds like the TypeScript team wants to move pretty quickly with this.
[1]: https://porffor.dev/
-
TinyGo
Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.
In my experience it is pretty difficult to make WASM faster than JS unless your JS is really crappy and inefficient to begin with. LLVM-based WASM is your best bet to surpass vanilla JS, but even then it's not a guarantee.
Go's WASM tooling isn't as good since it doesn't use LLVM and I've found it very difficult to even get parity with vanilla JS performance. There is a way to use a subset of go with llvm for faster wasm ([tinygo](https://tinygo.org/)).
I'm hoping that Microsoft might use some of their wasm chops to improve GO's native wasm compiler. Their .NET wasm compiler is pretty darn good, especially if you enable AOT.
-
revive
🔥 ~6x faster, stricter, configurable, extensible, and beautiful drop-in replacement for golint
The Uber page does a pretty good job of summing it up. The only thing I'd add is that there has been a little bit of effort to reduce footguns since they've posted this article; as one example, the issue with accidentally capturing range for variables is now fixed in the language[1]. On top of having a built-in race detector since 1.1 and runtime concurrent map access detection since 1.6, Go is also adding more tools to make testing concurrent code easier, which should also help ensure potentially racy code is at least tested[2]. Accidentally capturing named return values is now caught by a popular linting tool[3]. There is also gVisor's checklocks analyzer, which, with the help of annotations, can catch many misuses of mutexes and data protected by mutexes[4]. (This would be a lot nicer as a language feature, but oh well.)
I don't know if I'd evangelize for adopting Go on the scale that Uber has: I think Go works best for shared-nothing architectures and gets gradually less compelling as you dig into more complex concurrency. That said, since Uber is an early adopter, there is a decent chance that what they have learned will help future organizations avoid repeating some of the same issues, via improvements to tooling and the language.
[1]: https://go.dev/blog/loopvar-preview
[2]: https://go.dev/blog/synctest
[3]: https://github.com/mgechev/revive/blob/HEAD/RULES_DESCRIPTIO...
[4]: https://pkg.go.dev/gvisor.dev/gvisor/tools/checklocks
-
I actually really enjoy Go. Sure it has a type system I wish was more powerful with lots of weird corners ( https://100go.co/ ), but it also has REALLY GOOD tooling- lots of nice libraries, the compiler is fast, the editor tooling is rock solid, it's easy to add linters to warn you about many issues (golangci-lint), and releasing binaries and updating package repositories is super nice (Goreleaser).
-
-
I wonder if they explored using a Gc like https://github.com/Manishearth/rust-gc with Rust. I think that probably removes all the borrow checker / cycle impedance mismatch while providing a path to remove Gc from the critical path altogether. Of course the Rust Gc crates are probably more immature, maybe slower, than Go’s so if there’s no path to getting rid of cycles as part of down-the-road perf optimization, then Go makes more sense.
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
