Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I’m porting the TypeScript type checker tsc to Go

kdy1.dev

Post reply on HN
Print view View original

181–190 of 252 posts

Re: I’m porting the TypeScript type checker tsc to Go

#181

Post by gonzo41 »

kaba0 wrote: post #180

Slightly off topic, but do I not get something about Go? It comes up waay to often nowadays here, perhaps even more than LISPs - last time Rust was the hyped one, but it seemed to have decreased a bit. But at least rust is an interesting language with some novel features, adding new value to the low level PL domain. I fail to see what is unique about Go, other than the perhaps least known non-blocking concurrency (ba…

Go is about getting things done. I think it's interesting to HN because it is enough engineering to solve a problem, and no more. I think the biggest feature of golang is the community process that considers change slowly, in contrast to the JS ecosystem, that's a distinct feature.

Re: I’m porting the TypeScript type checker tsc to Go

#182

Post by hiptobecubic »

epolanski wrote: post #173
endgame wrote: post #111

Earlier quoted context omitted.

> you can only have one `Eq` or `Ord` instance for some type A. This is a good thing - it stops you from using one Ord instance when putting As into a Map or Set, and then trying to pull them back out using another. Newtypes let you provide "additional" instances in a safe way.

Why shouldn't I be able to use as many Ord instances as I want? I'll give you a trivial example I have some data type representing a TvShow, why should there be just one way to sort a collection of TvShow? Maybe I want to sort by year, maybe by length, maybe by category. It's trivial to do in fp-ts, you can have as many Ord instances as you wish.

They just said why it's important to explicitly track which instance is in effect and newtypes do that.

Re: I’m porting the TypeScript type checker tsc to Go

#183

Post by kibwen »

epolanski wrote: post #105
danenania wrote: post #38

Earlier quoted context omitted.

If they focus on the core features and make a significant enough improvement, perhaps the core TS team could be convinced to pull it in as a native extension and make calls to it for the operations it covers? If something like 62x improvement is really achievable, it's hard to imagine the team not being interested at all. I would personally be very happy to use a significantly slimmed down subset of TypeScript if it…

One of the main requirements of TypeScript is that the compiler has to work in a browser. The monaco editor is the prince jewel of TypeScript applications. So the only possibility I see is a webassembly alternative.

Not saying that the TypeScript team should actually do this, but Rust does have best-in-class WASM support.

Re: I’m porting the TypeScript type checker tsc to Go

#184

Post by kibwen »

marcus_holmes wrote: post #146
moltonel3x wrote: post #138

Earlier quoted context omitted.

SWC (by the same author as this tentative tsc port) is a part of more and more people's typescript toolchain, and is written in Rust. Having all your ecosystem in a single language feels nice, but pragmatically different tools might be better in different languages.

The point of having it all embeddable in Go is that we could write a single executable that handles the entire process, with the toolchain embedded and the configuration written as code.

You can embed Rust code in Go, unless there's something about Go that prevents static linking across FFI boundaries.

Re: I’m porting the TypeScript type checker tsc to Go

#185

Post by Nullabillity »

epolanski wrote: post #173
endgame wrote: post #111

Earlier quoted context omitted.

> you can only have one `Eq` or `Ord` instance for some type A. This is a good thing - it stops you from using one Ord instance when putting As into a Map or Set, and then trying to pull them back out using another. Newtypes let you provide "additional" instances in a safe way.

Why shouldn't I be able to use as many Ord instances as I want? I'll give you a trivial example I have some data type representing a TvShow, why should there be just one way to sort a collection of TvShow? Maybe I want to sort by year, maybe by length, maybe by category. It's trivial to do in fp-ts, you can have as many Ord instances as you wish.

Ord is for the natural (obvious and hopefully uncontroversial) ordering of a given type.

If your type doesn't have a natural ordering (as your TvShow doesn't) then you would use sortBy to supply an arbitrary compare function (just like what you would define in your Ord instance).

Re: I’m porting the TypeScript type checker tsc to Go

#186

Post by Mawr »

kaba0 wrote: post #180

Slightly off topic, but do I not get something about Go? It comes up waay to often nowadays here, perhaps even more than LISPs - last time Rust was the hyped one, but it seemed to have decreased a bit. But at least rust is an interesting language with some novel features, adding new value to the low level PL domain. I fail to see what is unique about Go, other than the perhaps least known non-blocking concurrency (ba…

> I fail to see what is unique about Go

That's because you're looking at it purely from only one point of view - the number of available features in the language itself.

What's unique about Go is not so much about the language itself as the approach of its authors to creating it. Go hasn't meaningfully changed in the 10 years of its existence. That's not an accident - the bar to add anything is extremely high. A feature needs to be punching way above its cost to even be considered.

If you look around the programming language space, you'll see the exact opposite attitudes, features get added into languages willy-nilly. Not much point in having different languages when they just trade features until they become indistinguishable from each other.

There are only three other languages that I know of that at least sort-of follow a similar philosophy to Go: 1. C 2. Zig 3. Elixir

You aren't going to be writing general-purpose code in C, so that's out. Zig is about a decade away from being a contender. Elixir is a valid choice, albeit much more niche and unfamiliar to the average programmer than Go is.

So if you want a language that'll be there for you in the long haul, that will not invalidate what you've learned about it every 3 years or so, you're left with Go.

Re: I’m porting the TypeScript type checker tsc to Go

#188

Post by ModernMech »

hardwaregeek wrote: post #32

This reminds me of when people try to make a new Ruby implementation. They get the basics down and think "this isn't so bad! I can do this!". Fast forward a few months and they're stuck on some nasty little edge case around eval and method_missing that they need to run Rails. Or some weird aspect of C extensions. TypeScript's compiler is an unholy, unsound mess, because JavaScript is an unholy, unsound mess. Sure the…

> This reminds me of when people try to make a new Ruby implementation. They get the basics down and think "this isn't so bad! I can do this!". Fast forward a few months and they're stuck on some nasty little edge case around eval and method_missing that they need to run Rails. Or some weird aspect of C extensions.

This is true of many programming languages projects. It's not uncommon for someone to write a language in a weekend, and then marvel at how their very simple toy language is faster than C! And look how quickly it compiles! Thus begins a several years-long journey, where with every feature added the runtime and compiler get slower and slower and slower.

Re: I’m porting the TypeScript type checker tsc to Go

#189

Post by exdsq »

epolanski wrote: post #104
dmitriid wrote: post #87

Earlier quoted context omitted.

However, more than once I've also yelled "HOW DO YOU NOT KNOW THIS?!" at something or other :)

Just today I was triggered that this compiles. declare foo: never[] // it can only be an empty array foo[1] // compiles TypeScript is a nice type system, it's surprisingly expressive and flexible, like e.g. in Haskell I was surprised that there's this strange notion that for a given type you can only have one `Eq` or `Ord` instance for some type A. But in TypeScript you can have as many Ord interfaces as you want. I…

Just a note that TypeScripts type checking & compilation are two separate systems. It's never a compilation error because it always compiles.

Re: I’m porting the TypeScript type checker tsc to Go

#190

Post by zja »

constexpr wrote: post #154

I'm the author of esbuild. I think this is a very smart, practical choice and is one of the approaches that has the best chance of succeeding (the other being a semi-automated porting tool instead of a purely manual port). I'm very excited to see someone take this approach. This is how I would do it if I were to do it. Web developers around the world are hoping this works out :) The hard part about this project isn't…

Love ESBuild! Convert a relatively large project from webpack to it today, really easy to do & much faster build times now!
Post reply on HN