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

311–320 of 332 posts

Re: TypeScript 5.0

#311

Post by rrishi »

cutler wrote: post #176
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#11 defaults to nullability and has top-level functions giving it a big advantage over Java. The idiomatic Pascal case takes some getting used to but it's worth it.

Thanks for the overview. Hopefully I can give the language a shot when time permits.

Re: TypeScript 5.0

#312

Post by schwartzworld »

Zuiii wrote: post #253
alcuadrado wrote: post #250

Earlier quoted context omitted.

You can use typescript as jsdoc annotations

Can you please expand further? If I annotated my js, how would the browser check and enforce my types? Would the checks include js-to-js code? What is the js script that I should include at the top of my ?

> how would the browser check and enforce my types?

If this is what you're looking for, you aren't going to get it with TypeScript, even if you could parse it in the browser. It might be possible to port or build a TypeScript parser that runs in the browser (it might even be done already) but this would mean sending a LOT of code over the wire for something that was designed as a static analysis tool.

You can use runtime validation libraries like https://zod.dev/.

JS will eventually include its own type system so that you will be able to write typed code and have it run in the browser. However, even then the types won't be checked at runtime. You'll still have to rely on a tool like `tsc` to type check your code.

Re: TypeScript 5.0

#313

Post by liminal »

TOGoS wrote: post #158
TOGoS wrote: post #71

Earlier quoted context omitted.

Good take if you ask me. When I want to flesh out an ontology, I find that TypeScript's type syntax more natural than anything else. Generally I find it to do an amazing job of bridging between a very expressive and flexible type system and a language that at runtime knows nothing about your types. Want structural/duck typing? No problem; that's the default. Define new interfaces that old classes happen to implement…

Addendum to my nominal types: For the 'fake' nominal types (you can't put a symbol on a number!) I like to make those fields optional, which makes the type less of a lie. "If this number did have a [unit symbol] property, the value would be 'USD'". That will still prevent accidental USD CAD conversion, but allows converting to/from regular numbers without explicit casting. A pile of thoughts on the subject from back…

This is really great. I once spent a little time thinking about how to better represent RDF in Type/Javascript. These approaches seem like a good direction to go in. Would love to see these ideas developed further.

Re: TypeScript 5.0

#314

Post by matt_kantor »

prmph wrote: post #292
lmm wrote: post #232

Earlier quoted context omitted.

> 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 wit…

Scala.js seems interesting, and I will look into it more. But if it is so nice, why hasn't it taken off like TypeScript?

I think a big part of TypeScript's success is because it's just "JavaScript with types".

Re: TypeScript 5.0

#315

Post by maxloh »

amaranth wrote: post #161
maxloh wrote: post #123

Earlier quoted context omitted.

How does that work?

web-sys[1] generates the binding code using the same IDL files that browsers use to generate their JS bindings to the C++ doing the actual work. [1] https://github.com/rustwasm/wasm-bindgen/tree/main/crates/we...

You still need to run JavaScript functions to manipulate the DOM. "without ever touching JS/TS" seems misleading as that implies "no JavaScript code is executed".

Re: TypeScript 5.0

#316

Post by triyambakam »

NoInkling wrote: post #264
throwaway09432 wrote: post #252

Typescript 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[]]

Or better:

    type NonEmptyArray = [unknown, ...unknown[]];
    const nea: NonEmptyArray = [];
    //    ^^^ Type '[]' is not assignable to type 'NonEmptyArray'.
    //        Source has 0 element(s) but target requires 1.

Re: TypeScript 5.0

#317

Post by HeavyFeather »

schwartzworld wrote: post #308
HeavyFeather wrote: post #153

Earlier quoted context omitted.

I mean, that could be changed. Currently: either string OR number Possible: either string | number OR just number

> The OR doesn't indicate | in TypeScript, it indicates the result of the possible future type guard. Are you implying in your other comment (that HN won't let me reply to) that Typescript has an "OR" operator that is distinct from "|"? Can you link to documentation on that?

"OR" was just my (bad) way to explain it. In plain English:

if isInteger(x) is true, x is definitely a `number`

if isInteger(x) is false, x is unknown/unaltered (it remains `typeof x`)

Current type guards can't express "yes versus maybe", so isInteger cannot be a type guard at all.

Re: TypeScript 5.0

#318

Post by quonn »

silasdavis wrote: post #129
quonn wrote: post #84

The missing feature I want most is type narrowing across chained functions like: arr.filter(a => a.kind === „bar“).map(a => /* a should now be of type Bar just like in a branch */)

It was would be nice for this to be automatic but filter does work like this it you pass a type guard as the predicate: ``` arr.filter((a: A): a is A & { kind: 'bar'} => a.kind === 'bar') ``` If you define: ``` function isKind (kind: K): (a: A) => a is A & { kind: K } { return (a): a is A & { kind: K } => a.kind === kind; } ``` Then you can write: ``` arr.filter(isKind('bar')) ``` and get a properly narrowed return t…

Nice, thank you

Re: TypeScript 5.0

#319

Post by chatmasta »

iainmerrick wrote: post #298
epolanski wrote: post #205

Earlier quoted context omitted.

You can do all you list with effect-ts/schema. Arguably the highest quality TS lib out there. https://github.com/Effect-TS/schema

At first glance this looks similar to Zod (which is listed as an influence). What does @effect/schema do differently/better? I feel like the name could use a bit of work for a start! "schema" is way too generic.

In our project at work, we've been using superstruct since 2021, but if we started today we'd probably choose Zod. We also use fp-ts, and it looks like effect-ts is a recent project by the same author, which certainly gets my attention.

Re: TypeScript 5.0

#320

Post by spion »

spion wrote: post #263
laurencerowe wrote: post #259

Earlier quoted context omitted.

> 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 l…

And yeah I totally agree with you regarding `cargo`, in my mind thats also one of the things that don't seem to be related to the language but the quality of life improvements end up being huge.
Post reply on HN