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

221–230 of 332 posts

Re: TypeScript 5.0

#221

Post by kaba0 »

jiggawatts wrote: post #213
spion wrote: post #87

Earlier quoted context omitted.

I used to think so too, until I tried Rust. By comparison, JavaScript (and by extension, TypeScript) is still lacking fundamental features and the library ecosystem situation is pretty bad. I wish there was a modern language that took all the good non-manual-memory-management things from Rust and added a GC and some immutable data structures. Error handling, enums, macros (with compile_error! / diagnostics API), trai…

I've been saying the same thing: We need an ahead-of-time compiled high level, business language. Something as efficient as Rust , but not designed for embedded microcontrollers or systems software. I feel like the entire industry has had a "kneejerk reaction" to C++ and its abysmally slow compile times. Everyone jumped onto the interpreter bandwagon and ended up throwing the baby out with the bathwater. It is defini…

> 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”?

Re: TypeScript 5.0

#222

Post by explaininjs »

benatkin wrote: post #219
explaininjs wrote: post #217

Earlier quoted context omitted.

You asked for isInteger to work as a type guard and I showed you how. If you prefer explicit casts everywhere that's fine, but it isn't a type guard. You could even use the type anonymously if you really want: (n is number & {Symbol(): never}). Whatever floats your boat, as you say.

Oh boy, I never ever asked for a replacement for Number.isInteger! I prefer to use native functions. Have a nice day.

Then alter the type of the ambient native function itself:

    interface NumberConstructor {
      isInteger(n: unknown): n is number & { Symbol(): never }
    }

Re: TypeScript 5.0

#223

Post by jiggawatts »

kaba0 wrote: post #221
jiggawatts wrote: post #213

Earlier quoted context omitted.

I've been saying the same thing: We need an ahead-of-time compiled high level, business language. Something as efficient as Rust , but not designed for embedded microcontrollers or systems software. I feel like the entire industry has had a "kneejerk reaction" to C++ and its abysmally slow compile times. Everyone jumped onto the interpreter bandwagon and ended up throwing the baby out with the bathwater. It is defini…

> 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.

Re: TypeScript 5.0

#224

Post by kaba0 »

theshrike79 wrote: post #170
rrishi wrote: post #166

Earlier quoted context omitted.

How does the verbosity in C# compare to Java's? And are big C# codebases littered with annotations and "dependency inversion" Java Spring boilerplate-y crap? I ask because I have never delved into C# only heard it's Microsoft's Java. And I am no fan of the original Java at all so C# gives me pause.

C# is pretty much Java done right. Speaking as someone who started with Java 1.2 and saw all the crap that happened to it. C# is currently lightyears ahead of Java in every way, especially now that MS is not Micro$oft to people on the internet any more =)

> C# is currently lightyears ahead of Java in every way

Let’s not claim things that can’t be objectively proven. C# does have much more features than Java, but that is not necessarily a plus in case of a programming language. There are features that are definitely better, but I am not bought that the whole would be.

Plus, ecosystem-wise Java is much bigger and much more open-source. The runtime is also better on the JVM-side, though this is offset by C# expressing more low level details.

Re: TypeScript 5.0

#226

Post by WorldMaker »

brundolf wrote: post #80
clarkdale wrote: post #72

Earlier quoted context omitted.

From the release notes, it certainly seems minor / backwards compatible. > 5.0 is not a disruptive release, and everything you know is still applicable. While TypeScript 5.0 includes correctness changes and some deprecations for infrequently-used options, we believe most developers will have an upgrade experience similar to previous releases.

It does have some backwards-incompatibilities, but they're mostly minor/edge-cases

It has one of the largest internal rewrites in TS history (namespaces to ESM switch), so it's somewhat incredible its backwards-incompatibilities list is mostly minor/edge-cases.

(Which is to say that Typescript probably couldn't use semver if it wanted to because it has some extreme views on backwards compatibility, but also that this amount of codebase churn is absolutely semver breaking in the strictest semver senses even if it is mostly backwards compatible.)

Re: TypeScript 5.0

#227

Post by WorldMaker »

eropple wrote: post #157
madeofpalk wrote: post #134

Earlier quoted context omitted.

NestJS uses the previous, incompatible decorators implementation IIRC.

And, because it does so, you can fall down really deceptive holes due to the lack of typing around things that decorators apply to, like parameters. I don't think that changes with stage 3 decorators, unfortunately. It makes NestJS really error-prone, in my experience, and it's a big reason I stopped making tooling for NestJS projects.

Yeah, it's going to be really "exciting" for Angular users as well in the next few years because Angular is drowning in those old "experimental decorators" which are not wholly compatible with today's Stage 3 decorators and the transition is going to be error prone and tedious. Up until TS 5.x it at least gave you a compile error if you tried to use decorators in code without the "experimental" flag, but now they will compile (except where they don't) even if you have the wrong flags but the behavior is so different between the flags it likely won't run. That's going to cause some interesting havoc.

Re: TypeScript 5.0

#228

Post by kaba0 »

throw_m239339 wrote: post #97
endisneigh wrote: post #50

I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a weakly typed language. If we could push JavaScript performance to be another order of magnitude faster it wouldn't be necessary to use other languages, imho. Of course, pushing it that far without effectively creating a new one would be difficult, to say the…

> I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a weakly typed language. Typescript types don't exist at run time, at all. So it's easy to be better when your language is merely about static analysis as it will not enforce any sort of type system during runtime. Java, Go or C++ have different constraints.

To be honest, that’s the “default” way of type systems - without runtime reflection capabilities type erasure is just a normal phase of an AOT compiler, why would you store types?

Re: TypeScript 5.0

#229

Post by WorldMaker »

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 semantics for the browsers themselves and you would still want a type checker, such as Typescript, to actually check the types that are annotated. (Just as you want to run Mypy or Sorbet, respectively, in the cases of Python/Ruby.)

Re: TypeScript 5.0

#230

Post by WorldMaker »

simlevesque wrote: post #18
martypitt wrote: post #4

Congrats to the Typescript team. The rate of innovation from them is really impressive. Fantastic to finally see Decorators shed their "experimental" label (they've been the stable backbone of Angular for years).

It's not the same decorators that existed before that were added. They don't have the same features. The new one are based on the upcoming EcmaScript decorators.

Also, Angular relies on parts of the "experimental" decorators that these Stage 3 decorators do not support, so Angular likely will continue to use the "experimental" compiler flag for some time to come, with the added twist that some uses of decorators will now also compile without the flag but will exhibit different behavior and won't run correctly, which may cause all sorts of new headaches for Angular developers.
Post reply on HN