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

TypeScript 7

devblogs.microsoft.com

Post reply on HN
Print view View original

281–290 of 321 posts

Re: TypeScript 7

#281

Post by dbbk »

semiquaver wrote: post #87
Exoristos wrote: post #51

Seeing these graphs of astounding performance gains with less memory requirements makes one wonder, Why am I using server-side TypeScript and not Go?

For one, you’re not using TypeScript server-side. Whatever execution engine you are using is executing transpiled or JavaScript. And yeah, I don’t know who in their right mind is starting projects in TS/JS/python these days except when they don’t have an option.

"In their right mind?" I wouldn't start a project in anything other than TypeScript now. My platform is a monorepo across web and native mobile (Expo), and is TypeScript throughout. All my types flow everywhere automatically. Even the shape of a database table is shared with the native app with tRPC. Nothing can break the type contract anywhere. How would you do that with another language?

Re: TypeScript 7

#283

Post by moogly »

Tadpole9181 wrote: post #162
docmars wrote: post #143

Earlier quoted context omitted.

Bun's migration to Rust was nothing more than a marketing stunt to sell more Claude subs under the impression it can perform this kind of work at scale, assuming that most who were convinced by it wouldn't look under the hood at what really took place. It has its merits as a proof of concept that could eventually be cleaned up and released properly later, but I can't see it any other way. Too many see it as this mira…

Not sure I understand. Bun's changes are merged on the dev branch and available for use, no? EDIT: Oh, look, blog post on the front page now. https://bun.com/blog/bun-in-rust > Bun v1.3.14 was the last version of Bun written in Zig. Bun v1.4.0 will be the first version of Bun written in Rust. It's available in canary now. So, yes, it seems it was definitely more than a "marketing stunt" and it's broadly available and…

A minor version bump? Exciting times we live in.

Re: TypeScript 7

#284

Post by dimitropoulos »

mejutoco wrote: post #226
dimitropoulos wrote: post #165

Earlier quoted context omitted.

I answered here https://news.ycombinator.com/item?id=48838629

Are you aware of languages like lean or idris? In that comment you mention doom in ts types.

nope! never heard of them! (note: I'm the guy that did the Doom in TS types thing) what type-level fun do they bring to the table?

Re: TypeScript 7

#285

Post by sharlos201068 »

lelele wrote: post #282

Joel On Software: Rewriting software is the single worst strategic mistake that any software company can make. [1] Microsoft: Take that, Joel! ;) --- [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

To be fair, this wasn't just rewriting the software, it was translating logic in JS largely one-to-one into Go.

Re: TypeScript 7

#286

Post by etaweb »

_flux wrote: post #89
kstrauser wrote: post #42

Earlier quoted context omitted.

I don't recall anyone disliking types . Lots of people disliked static typing , or more directly static, explicit typing . For instance, I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped. That's insane: Python is strongly typed. It's also dynamically typed, which is a different dimension. There are some genuinely untyped languages…

There's a school of thought that consider the term "types" reflect to the properties that exist in programs even before they are run, as in they are a property of the programs themselves, not their state at runtime. This thinking—which is also what type theory talks about—does consider Python untyped: reading a Python program along with its specification, you are not able to assign types to each expression. But what…

Note that Python supports type annotations in its syntax, but the interpreter will just ignore them as they are meant to be used by external tools such as ruff: https://github.com/astral-sh/ruff

I've had a good experience developing small to medium sized Python programs/scripts using type annotations plus ruff connected to my editor through its LSP (Language Server Protocol). It helps a lot, and I don't like to write Python without it.

You can create types from literal values and use union types, which I feel makes it more pleasant than Go's type system for example.

Re: TypeScript 7

#288

Post by _flux »

etaweb wrote: post #286
_flux wrote: post #89

Earlier quoted context omitted.

There's a school of thought that consider the term "types" reflect to the properties that exist in programs even before they are run, as in they are a property of the programs themselves, not their state at runtime. This thinking—which is also what type theory talks about—does consider Python untyped: reading a Python program along with its specification, you are not able to assign types to each expression. But what…

Note that Python supports type annotations in its syntax, but the interpreter will just ignore them as they are meant to be used by external tools such as ruff: https://github.com/astral-sh/ruff I've had a good experience developing small to medium sized Python programs/scripts using type annotations plus ruff connected to my editor through its LSP (Language Server Protocol). It helps a lot, and I don't like to write…

Definitely mypy keeps my sanity in a relatively large Python project I'm working on :). But I don't believe Python actually assigns any meaning to them, and at times mypy and e.g. pyright may disagree on what the types actually are.

Re: TypeScript 7

#289

Post by dismalaf »

trealira wrote: post #222
dismalaf wrote: post #114

Earlier quoted context omitted.

> Lisp is dynamically typed. Ish. SBCL aggressively infers types wherever possible. It can do dynamic typing with tags of course. You can also write it with 100% static types. Dynamic typing isn't a defining feature of Lisp style languages (even GC isn't necessary). Some historic Lisps and modern ones are 100% statically typed.

> even GC isn't necessary Um, isn't it? Don't all Lisp variants have it? IIRC McCarthy's LISP just ran out of memory until the GC was written.

> Um, isn't it?

No. There's been GC-less Lisp's over the years, here's a good paper on one: https://dl.acm.org/doi/10.1145/142137.142162

There was also pre-Scheme, GOAL, nowadays there's Carp and Dale. Zeta Lisp (and now SBCL) had/have arenas and you can manually allocate, etc...

> McCarthy's LISP

McCarthy also envisioned it having M-expressions.

Re: TypeScript 7

#290

Post by bastawhiz »

vlovich123 wrote: post #223
bastawhiz wrote: post #193

Earlier quoted context omitted.

The initial state has no bearing on whether the process was responsible or not. That's measuring along a different axis. If the bun rewrite lands and it breaks someone's app, that's bad no matter whether there's more or fewer bugs in the final state. The important metric in a rewrite of software that's used in production is stability.

inevitable: https://xkcd.com/1172/

It's really not even close to being the same. In the best case, a bug means your app crashes on the new version. In the worst case, something more insidious happens like opening a security vulnerability (say, TLS isn't handled correctly or HTTP headers are mishandled in a way that allows SSRF or request smuggling) or a previously linear time operation is accidentally quadratic (leading to DoS).
Post reply on HN