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

TypeScript 5.0

devblogs.microsoft.com

Post reply on HN
Print view View original

231–240 of 332 posts

Re: TypeScript 5.0

#231

Post by eropple »

wnolens wrote: post #126
i_am_toaster wrote: post #115

I’m always surprised by how much others like typescript. Out of all the languages I have to use, typescript is the one that feels the most like pulling teeth. Maybe I just don’t know how bad it truly was to work with a really large JavaScript project without types and that’s why people love it, but without that experience it just feels like all the hassle of types without most of their benefits.

I feel the same, but when I complain I get blamed. Or someone chimes in with an illegible type/interface definition that solves my issue but is completely out of reach for all but language experts, which in other languages is not an issue.

Can you provide an example of something you'd see in common use that is 1) not provided by an existing library (such that you are consuming a complex type rather than writing it) and is 2) "out of reach for all but language experts"?

Re: TypeScript 5.0

#232

Post by lmm »

prmph wrote: post #125

I wish MS will fork Typescript into a new language altogether that transpiles to JS or compiles to WASM. In that case, they can remove all JS weirdness from it, simplify it, add a proper standard library, and add other good parts from other (especially functional) languages to it. My wish list for such a language (in addition to what is already in Typescript), in no particular order: - Generic object literals (Why sh…

> In that case, they can remove all JS weirdness from it, simplify it, add a proper standard library, and add other good parts from other (especially functional) languages to it.

Have you tried Scala.js? It's pretty much what you're asking for - a first-class functional language with all the things you'd expect from that, with compile-to-JS as something that works and feels fully first-class (and good integration with TypeScript types via ScalablyTyped).

Re: TypeScript 5.0

#233

Post by halfmatthalfcat »

dmix wrote: post #194
prmph wrote: post #125

I wish MS will fork Typescript into a new language altogether that transpiles to JS or compiles to WASM. In that case, they can remove all JS weirdness from it, simplify it, add a proper standard library, and add other good parts from other (especially functional) languages to it. My wish list for such a language (in addition to what is already in Typescript), in no particular order: - Generic object literals (Why sh…

> Deep support for an alternative to exceptions using a Failable type Is there a good library for this currently? I've been looking for one and a Maybe library. The Maybe one I use is pretty small.

fp-ts (and most functional libraries) have a handy Either type just for this: https://gcanti.github.io/fp-ts/modules/Either.ts.html

Re: TypeScript 5.0

#234

Post by kaba0 »

jiggawatts wrote: post #223
kaba0 wrote: post #221

Earlier quoted context omitted.

> Everyone jumped onto the interpreter bandwagon I can only think of Ruby and Python that use a strictly interpreter mode (in their most common runtime). Java, C# use a hybrid solution, but for all practical purposes they are running as extremely efficient machine code, how is it not “efficient business language”?

They're both JIT compiled, not ahead-of-time compiled. This severely limits the type of optimisations that they can perform, because they have to do it "on the fly" during runtime.

Being pedantic, both have AOT compilers readily available.

But sure, though I don’t really buy the argument that JIT compilers would “severely limit” the type of optimizations - there is no significant performance difference - if any - between AOT compiled managed languages and JIT-compiled ones. Sure, there are more constraints in case of a JIT, but it’s not like going in the other direction and letting gcc/clang chew 10x time more on the same program would give you a significant speedup, if any. Speculations (which are not possible AOT) may even reverse the fields.

D, Haskell, OCaml, Go are all in the same ballpark as Java and C#, and even JS, hell, they may be better.

Re: TypeScript 5.0

#235

Post by WorldMaker »

tgv wrote: post #168
christophilus wrote: post #138

Earlier quoted context omitted.

Yeah. I never use them. They don’t offer enough benefits vs unions.

You can export enums as objects to javascript. And it's easier to change string enums than string unions.

The typescript language server does a great job supporting rename refactors for string unions. It doesn't get much easier than that and is no harder than string enums, in my view.

(I've done crazy things like use emoji named types in string unions and then used F2 to rename refactor them to a different emoji or name and not needed to worry if it missed any emoji literals.)

The only thing missing from both string enums and string unions is something to support [Symbol.iterator]() to iterate through the available options, but at this point I find that easier to write DRY with string union types (especially with typeof/keyof meta-magic) rather than string enums.

Re: TypeScript 5.0

#236

Post by harel »

WorldMaker wrote: post #229
harel wrote: post #225

What happens to TypeScript when ECMAScript brings it's core elements to the language?

Typescript for a while has focused on Stage 3 and Stage 4 proposals, so its "core elements" are almost all already in the language. Unless you mean the type annotations itself? The good news there is that there is a Stage 1 proposal to take the Python/Ruby approach of bringing them into the language: https://github.com/tc39/proposal-type-annotations Were that to happen, that proposal doesn't apply any type checking s…

Yes I meant type annotations. To be honest, given a choice, I opt for JavaScript. I personally don't find the benefit of TS is worth than all the extra work it requires, to make what is a dynamic language, not so dynamic. Why go for Python/JavaScript/Ruby if the first thing one does is to eliminate what makes it Python/JavaScript/Ruby? (Well, in the case of JavaScript, granted there's little choice available).

Re: TypeScript 5.0

#237

Post by lewisl9029 »

mirekrusin wrote: post #169
latchkey wrote: post #19

Earlier quoted context omitted.

I'm curious what criteria you used to pick Flow vs. Typescript.

Flow still has some better sides: * first class opaque type support * exact object type * correct variance, sound liskov oop * no transpilation support (/*: */ and /*:: */) - so simple, so powerful; jsdoc ts doesn't compare, you can't import type star, when consuming libraries you have to increase maxNodeModuleJsDepth and other shenanigans; in flow you simply have access to all flow type language; why they don't want…

Great list!

Related to your point on supporting 0-transpilation workflows as a first class citizen, is the fact that Flow was explicitly just type annotations & checking, and aimed to introduce 0 runtime constructs.

This is something Flow did from the beginning and TypeScript eventually established as a non-goal after already implementing several runtime constructs that they can no longer afford to remove for backwards compat [1].

Though interestingly enough, Flow themselves recently announced they're going to start introducing runtime constructs, which is an interesting plot twist [2].

[1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

[2] https://medium.com/flow-type/clarity-on-flows-direction-and-...

Re: TypeScript 5.0

#238

Post by WorldMaker »

harel wrote: post #236
WorldMaker wrote: post #229

Earlier quoted context omitted.

Typescript for a while has focused on Stage 3 and Stage 4 proposals, so its "core elements" are almost all already in the language. Unless you mean the type annotations itself? The good news there is that there is a Stage 1 proposal to take the Python/Ruby approach of bringing them into the language: https://github.com/tc39/proposal-type-annotations Were that to happen, that proposal doesn't apply any type checking s…

Yes I meant type annotations. To be honest, given a choice, I opt for JavaScript. I personally don't find the benefit of TS is worth than all the extra work it requires, to make what is a dynamic language, not so dynamic. Why go for Python/JavaScript/Ruby if the first thing one does is to eliminate what makes it Python/JavaScript/Ruby? (Well, in the case of JavaScript, granted there's little choice available).

I think tools like Typescript/Mypy/Sorbet exhibit is that there's a lovely "gradually typed" spectrum between "no type information/purely dynamic typed language" and static typing. "Gradual typing" has a lot of best of both worlds to it: write the raw and fast "no types" notebook code to proof of concept, then gradually add types as you test and productionize the same code. Production code can have lots of additional type checking and type testing that adds to robustness, while development and early code still have the benefits of a type system that can move fast and easily break things. It's nice to be able to move across that spectrum as a project matures. It's no longer a "hard binary" between dynamic typed languages and static typed languages, and you can choose much more interesting positions between 0% static types and 100% static types depending on your risk profile and interest.

Re: TypeScript 5.0

#239

Post by harel »

WorldMaker wrote: post #238
harel wrote: post #236

Earlier quoted context omitted.

Yes I meant type annotations. To be honest, given a choice, I opt for JavaScript. I personally don't find the benefit of TS is worth than all the extra work it requires, to make what is a dynamic language, not so dynamic. Why go for Python/JavaScript/Ruby if the first thing one does is to eliminate what makes it Python/JavaScript/Ruby? (Well, in the case of JavaScript, granted there's little choice available).

I think tools like Typescript/Mypy/Sorbet exhibit is that there's a lovely "gradually typed" spectrum between "no type information/purely dynamic typed language" and static typing. "Gradual typing" has a lot of best of both worlds to it: write the raw and fast "no types" notebook code to proof of concept, then gradually add types as you test and productionize the same code. Production code can have lots of additional…

That's a sensible way to look at it.

Re: TypeScript 5.0

#240

Post by djur »

rcme wrote: post #51
swatcoder wrote: post #43

Earlier quoted context omitted.

> almost becomes a DSL of sorts For mature projects with experienced, cohesive teams, that’s a good thing. You want a DSL that blends right in with your fully capable base language. But yeah, just like with any powerful feature, people can get excited and carried away.

I think some people want things to be DSL-like. However, I don’t think, long-term, using a DSL-like syntax wins. Ruby was famous for abusing Ruby’s unique syntax to make everything into a DSL and it turned off newcomers. Similarly, Java’s DI frameworks meet a lot of resistance because of their heavy use of annotations. Ultimately, DSLs are separate languages. Most people don’t want to learn a new language.

In my experience as someone who has worked with dozens of new Ruby developers, I think the ability to create expressive DSLs was a significant net positive. It was much more likely to be a source of excitement than something that turned newcomers off. I don't think DSLs are or were a problem for Ruby (nor do I think they count as "abusing syntax").
Post reply on HN