Hacker News Reader

Comment by sk0g | Hacker News Reader

If the Typescript team got carte blanche to create their own language, it would likely be... C#.

TS is complicated and chaotic because the language it compiles down to is. TS' aim is to model the behaviour seen in JS in a flexible, user-friendly type system. Good luck!

What doesn't make sense to me is when teams (like mine) have a blank slate and the choice of any mainstream backend language, and then opt in to that ecosystem anyway. TS is good when you're coming from JS sure, but some of us have used more "sane" languages like C# and Go :(

View on HN

Go is sane? I just started using it and the parsing libraries all standardize tags and reflection.

Not exactly sane. Go is one of the most clunkiest awkward languages I've ever worked with. The only benefit is that it's somewhat easy to learn.

Go is sane for some definitions of the word! If I got to choose a language to work with though, it would definitely be Kotlin or C#, but I prefer Go over Python because there are fewer ways to solve problems, leading to generally simpler code.

It's like a modernised C but for web/infrastructure. Unfortunately ignores about 3 decades worth of progress in other languages, and is simplistic to a fault. Jumping into an unknown codebase is easier than every other language I've used as a result.

Go has it's time and place just like C. The developers chose to ignore that progress and created the C for distributed and parallelizeable code. Using go for what you use JavaScript for is like using C to do Java work. Sure you can do it, but it's not going to be easy and you're going to have a bad time.

As you've said, Go is sane by some definitions of the word but a user should know what types of sanity and insanity they are willing to work with and which are inherent to their problem space

I come from a Java / Kotlin background and TS is totally fine.

Some quirks I've noticed are typed objects not performing any validations, like for building DTOs. Structural typing so the newtype pattern is not possible without some awkward hacks. A general "disconnect" between compile time and run time behaviour, so once you start casting your errors are relegated to property access/usage time, which makes — IMO excessive — test coverage paramount in catching bugs wherever you have conditional logic.

I would have gone with C# or Kotlin if I had the luxury of choice, but I'll get that with a deliberate career move maybe.

If you’re taking in data from an external source that needs to be validated, I highly recommend a schema library like zod, that can produce a typescript type.

That way you can define the type in a single place, have runtime validation for that type, but also be able to use the type in typescript at compile time.

Can you use something like Zod with the newtype pattern? I use DDD-style types for domain specific data over primitives.

> TS is complicated and chaotic because the language it compiles down to is

I hear this regularly but don't think it holds water. Other statically typed languages compile to any number of targets without issue; machine code, llvm, and even JS.

This feels like an odd excuse moreso than a reason. Consider that most folks consider compiling software to go down to an assembly language. Which often has crazy semantics and intrinsics that many of us don't understand or know about.

I suspect what you mean is that they aren't just compiling down to JavaScript, but they are wanting to do so in a way that there is no foreign function interface (FFI) consideration for folks in either language. That is, largely to say, they don't want a Typescript runtime?

Precisely, TypeScript only exists at compile time. Half their goals relate to this fact, which leads to constraints regarding what the language can achieve.

> 3. Impose no runtime overhead on emitted programs. > 4. Emit clean, idiomatic, recognizable JavaScript code. > 7. Preserve runtime behavior of all JavaScript code. > 8. Use a consistent, fully erasable, structural type system.

https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

I'm curious on reasons why not to build a new runtime. That it is hosted in javascript seems like something that shouldn't be that big of a deal.

> If the Typescript team got carte blanche to create their own language, it would likely be... C#.

This is sarcasm, right? The creator of TS is the lead architect of C#

I feel like that’s supporting the parent, right?

Not really, because it's not a question of if TS creators got to make their own language.

And C# iterates at a rapid pace, with lots of language features being added, some of which would would not be possible in TS.

C# is in some ways less shackled by the runtime it has to target, while TS compiles away entirely. The CLR can be changed to suit .net/C# needs, and JS is not under their control.

Reply on news.ycombinator.com