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

141–150 of 332 posts

Re: TypeScript 5.0

#141

Post by giraffe_lady »

dimitropoulos wrote: post #2

Without Angular, we may very well not have TypeScript today. The top thing listed in this release (TypeScript doesn't follow semver, btw) is about Decorators. I find the whole story about Angular's role in TypeScript early days to be very fascinating because I don't hear people talk about it anymore (just search "AtScript TypeScript" if you weren't around at the time). It was the Angular team that forced Decorators t…

god just think how good life would be if we had all switched to elm or reason instead.

Re: TypeScript 5.0

#142

Post by benatkin »

explaininjs wrote: post #104
benatkin wrote: post #62

Earlier quoted context omitted.

That seems like an important feature request. I see TypeScript adding fancy stuff without fixing core limitations.

You can get around it pretty easily: const intSymbol = Symbol('integer') type integer = number & {[intSymbol]: never} const isInteger = (n: unknown): n is integer => Number.isInteger(n) function f(s: string | number) { if (isInteger(s)) { const allowed = s.toExponential() } else { // s still string | number } } With this you even get to define functions that must accept integers, which is kinda neat.

That doesn't seem to address my concern. It seems like more of a curiosity. Whatever floats your boat.

Re: TypeScript 5.0

#143

Post by jdlshore »

rr888 wrote: post #130
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 agree TS is great. Not really multi threaded kills it for me though.

Threads are a function of the environment, and are available in TS and other compiles-to-JS languages:

Node.js: https://nodejs.org/api/worker_threads.html

Browser: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

However, threads are very rarely needed. The common use case in other languages is I/O, and JS environments handle that with async I/O—a superior choice, IMO.

Re: TypeScript 5.0

#144

Post by modeless »

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…

If you're breaking backwards compatibility then my number one request is replacing UTF-16 with UTF-8 for strings and nothing else comes close.

Re: TypeScript 5.0

#145

Post by janaagaard »

kypro wrote: post #124
yanis_t wrote: post #56

Your regular reminder, that it’s just a regular release, since typescript don’t follow semver. After 4.9 goes 5.0

Is there a reason for this? Why even have the decimal if 4.9 -> 5.0 is just as significant as 4.8 -> 4.9. Just make it v49 -> v50 and remove the ambiguity. What am I missing?

One downside to having a version 4.10 is that some sorting algorithms put this release between 4.1 and 4.2 and not after 4.9.

But yeah, they should just go ahead and follow semver from now on.

Re: TypeScript 5.0

#146

Post by mtone »

In a monorepo with project references where each symlinked (not paths) package has a src/ and output lib/, I've always had issues with VsCode incorrectly proposing to import from src/ over lib/ from other packages. Never got it to work just right.

Does anyone know if the new package.json resolution settings can help resolve these issues?

Re: TypeScript 5.0

#147

Post by c-hendricks »

claytongulick wrote: post #73

Probably an unpopular opinion, but my favorite thing about typescript is what it's done for the jsdoc community. A bunch of stuff had to be built to support good tooling in vscode for types with JavaScript, and that was leveraged for jsdoc also. I don't use typescript, but I benefit from it in multiple ways, js doc and the occasional .d.ts file have made my life better.

If you use things like `import('some-package').SomeType` in JSDoc I don't think it's fair to say you don't use TypeScript. You do, that's only supported in TS.

Re: TypeScript 5.0

#148

Post by swyx »

deckard1 wrote: post #49
swyx wrote: post #5

> How? There are a few notable improvements we’d like to give more details on in the future. But we won’t make you wait for that blog post. the typescript project continues to set the bar extremely high in terms of changelog and clear communication. love you so much, drosenwasser and co!! > Decorators are an upcoming ECMAScript feature that allow us to customize classes and their members in a reusable way. huh. i tho…

I don't think decorators being a proposal matters at this point. I know I've been using them for 5+ years now, and libraries such as NestJS already use them extensively. If you like them, you're probably already drowning in them. Me, personally, I could take them or leave them.

yeah also feel quite ambivalent about them. theyre opaque syntax sugar. dont provide enough value to me personally but i wont begrudge others

Re: TypeScript 5.0

#150

Post by illiarian »

jdlshore wrote: post #143
rr888 wrote: post #130

Earlier quoted context omitted.

I agree TS is great. Not really multi threaded kills it for me though.

Threads are a function of the environment, and are available in TS and other compiles-to-JS languages: Node.js: https://nodejs.org/api/worker_threads.html Browser: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... However, threads are very rarely needed. The common use case in other languages is I/O, and JS environments handle that with async I/O—a superior choice, IMO.

Neither of those are proper threads, and they have various limitations placed on them.

And the language and the VM has been, and will be for any foreseeable future, single-threaded.

Post reply on HN