Decorators - the kiss of death for any programming language.
I encourage anyone who disagrees with this to give Nest.js a try (note: not Next.js)
TypeScript 5.0
261–270 of 332 posts
Re: TypeScript 5.0
#262Earlier quoted context omitted.
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.
You're asking Microsoft to undo a very Microsoft oddity that Microsoft seems to use just about everywhere. Good luck!
> undo a very Microsoft oddity
I don't think Microsoft are the reason why JS uses UTF-16 strings.
Re: TypeScript 5.0
#263Earlier 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 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. This basically describes all of the recent ML – perhaps more specifically OCaml – influenced languages like Kotlin, Swift, F#. (Rust is also heavily influenced by OCaml but its distinguishing feature is manual memory management with lifetimes.) I do wish we had a…
Its not quite that simple. Some of the things that Rust gets right are subtle, but typically punted by many other languages. Documentation containing fully working examples due to thos examples being run by doctests, for example, is kinda rare.
Here is another more subtle but important example: flexible API for error conversion, powerful language features and macros together enable the language, in conjunction with libraries like https://docs.rs/anyhow/latest/anyhow/ which gets you the best of all worlds in error handling: concise `?` operator for writing error handling code, eas to add additional message context (using `with_context` from anyhohw), differentiating between functions that can and cannot throw in the types (Result), and the ability to get exception style backtraces from Result, too (that last one seems to be rare)
Another subtle QoL which is often overlooked when implementing macros: `compile_error!` (and soon even more powerful diagnostic API). With that, macros can report custom errors back to the programmer via the compiler and language service, rather than becoming an incomprehensible mess. For example, the peg parser macro will mark errors with infinite left-recursive rules that don't have caching set up with custom error messages.
Re: TypeScript 5.0
#264Typescript is a good try, but ultimately our favourite JS runtime errors still happen, even with all the strictest ts settings. Syntactically it is quite clumsy, you can see the uninspired mix of C++ and Java in there. The typings now although people are doing lots of cute things with them, don't do some really fundamental things. For example there is currently no sensible way to type a non empty array in Typescript.…
> there is currently no sensible way to type a non empty array in Typescript
If we remove the "sensible" requirement:
type NonEmptyArray = [any, ...any[]]Re: TypeScript 5.0
#265Without 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…
AtScript was always stillborn, and the Angular team absolutely could not have made a competitor to TypeScript.
Wonder why they didn’t go with the other google language Dart
Too foreign to frontend audiences? It has a lot of fans in flutter
Re: TypeScript 5.0
#266Earlier quoted context omitted.
AtScript was always stillborn, and the Angular team absolutely could not have made a competitor to TypeScript.
Wonder why they didn’t go with the other google language Dart Too foreign to frontend audiences? It has a lot of fans in flutter
There was AngularDart, don't know what happened to it.
Re: TypeScript 5.0
#267Without 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…
One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow. Years later I had the opportunity to use Typescript and it was so nice comparatively. I've enjoyed it ever since. Of course, that was with years of development in its belt so maybe the experience wouldn't have been as nice if I went with it originally.
> One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow.
What caused you to choose Flow over TypeScript?
Re: TypeScript 5.0
#268Earlier quoted context omitted.
One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow. Years later I had the opportunity to use Typescript and it was so nice comparatively. I've enjoyed it ever since. Of course, that was with years of development in its belt so maybe the experience wouldn't have been as nice if I went with it originally.
Interestingly, both flow and typescript have roots in OCaml/F# respectively. Flow was written in OCaml and the creator of Typescript was on the F# team at Microsoft.
> creator of Typescript was on the F# team at Microsoft.
I actually think the bigger driver for TypeScript was Anders' history of working on C# and Delphi before that.
Re: TypeScript 5.0
#269It's easy to miss, but I'm most excited for "--moduleResolution bundler" ( https://devblogs.microsoft.com/typescript/announcing-typescr... ) My understanding is it should allow you to finally have TypeScript files that import other TypeScript files and include the file extension. This is important because, for one, it means Deno TypeScript modules and non-Deno TypeScript modules are now compatible (can import each ot…
Interesting. I don't like all the build-tooling around front-end/Typescript. It's a common complaint I know.
I recently tried to modularize some code into a package that used Typescript import-path aliases. I don't know which step(s) I got wrong since there's multiple tools/packages, each with different versions, each with a different package needed for the appropriate build tool (x-for-webpack, x-for-rollup, etc). When building and re-using the module in some other project with a different build config I couldn't get it to build properly and wanted to just get back to working on my actual project.
I eventually just went and looked at the typescript repo for a reference build config thinking they'd have something easy to follow, but I just decided since they don't use import path aliases I won't either.
I hope all the tools go away that require me to look up things like: "is it an X type of module? if so export/bundle it this way" or "are you using an X type of module? if so import it in Y fashion and use build-pipeline plugins A B and C"
Re: TypeScript 5.0
#270Earlier quoted context omitted.
The jankiness of JS combined with the correctness of TS really is a powerful combo. Especially stuff like string keys and const arrays as enums make safe and readable code without a lot ceremony. The big problem is the gap between TS and JS. User defined typeguards are a usable work around but it would be nice to be able to use a native isMyType function. Also would be nice to have constraints natively in types. Like…
You can do all you list with effect-ts/schema. Arguably the highest quality TS lib out there. https://github.com/Effect-TS/schema
this looks like a better documented io-ts