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

High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

hamy.xyz

Post reply on HN
Print view View original

41–50 of 122 posts

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#41

Post by sally_glance »

teaearlgraycold wrote: post #38
sargunv wrote: post #36

Earlier quoted context omitted.

Even with strict flags on, there are failures. A trivial example: function mutateArray( arr: (string | number)[] ) { arr.push(1); } const a: string[] = ["one", "two"]; mutateArray(a); a is now a string[] with a number inside

Very interesting. I’m shocked the typescript creators built a system with this failure mode. I guess the solution here is to have tsc change the type of “a” after the call to mutateArray, unless the arr argument is marked as readonly. Is there a name for this failure mode?

I think the problem is the union argument type - intuitively we read "array of strings OR numbers", but actually it means "array of strings AND numbers". Probably generics would be more appropriate here, with the type param constrained to string or number. Then tsc would also complain about pushing a number without checking the item type before.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#42

Post by teaearlgraycold »

sargunv wrote: post #39
teaearlgraycold wrote: post #38

Earlier quoted context omitted.

Very interesting. I’m shocked the typescript creators built a system with this failure mode. I guess the solution here is to have tsc change the type of “a” after the call to mutateArray, unless the arr argument is marked as readonly. Is there a name for this failure mode?

I'm not aware of a name, but I'm also curious if there is one because I had a hard time searching for it. I came across it on ThePrimeagen's YouTube channel: https://youtu.be/u1WmiqlrqL0

I asked an LLM and it described the problem as "covariant typing of mutable collections" or "unsound covariance". I'm not mathematically educated in this area but that sounds right?

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#44

Post by fainpul »

sally_glance wrote: post #41
teaearlgraycold wrote: post #38

Earlier quoted context omitted.

Very interesting. I’m shocked the typescript creators built a system with this failure mode. I guess the solution here is to have tsc change the type of “a” after the call to mutateArray, unless the arr argument is marked as readonly. Is there a name for this failure mode?

I think the problem is the union argument type - intuitively we read "array of strings OR numbers", but actually it means "array of strings AND numbers". Probably generics would be more appropriate here, with the type param constrained to string or number. Then tsc would also complain about pushing a number without checking the item type before.

If it's an "array of strings AND numbers", then it should not be allowed to call the function with a string[], because those are different types.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#45

Post by olcay_ »

bluegatty wrote: post #31
loglog wrote: post #29

Earlier quoted context omitted.

1. Java is mentioned in their comparison table. They just don't use it much. 2. There is really no reason to include Java in the search for your preferred language, since Kotlin is strictly better along every relevant axis.

Kotlin is a few tweaks on top of Java, most of which aren't relevant anymore, and it's not strictly better in most ways other than saving a few keystrokes (and preference). It's a little bit nicer to write but that's almost irrelevant. It also comes with some runtime cruft. In reality there is no Kotlin without Java, which means most projects end up a bit 'dual'; every single Kotlin project we've had (except Android)…

There definitely is Kotlin without Java, and you can compile Kotlin code for use in jvm, ios/ipados/macos, android, wasm/js, and native.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#46

Post by fainpul »

bluegatty wrote: post #28
jackjeff wrote: post #22

Isn’t this “high level rust” idea similar to swift? Everything is ARC. Clones are cheap. But you still have a reasonable sound type system and no garbage collection. I get it. Tooling on swift is meh the further you are from Apple, so I’m not suggesting it’s better. But from a language point of view; is it not essentially a high level rust? Ps. I don’t really know swift. Just asking where/why I’m wrong really.

It's not ARC though. They use fancy threading mechanisms to avoid having to check on every access. Much faster.

"Swift uses Automatic Reference Counting (ARC) to track and manage your app’s memory usage."

https://docs.swift.org/swift-book/documentation/the-swift-pr...

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#47

Post by Tade0 »

teaearlgraycold wrote: post #33
Tade0 wrote: post #16

Regarding TypeScript: > but types lie at runtime (unsound) requiring you to add your own runtime checks. I don't recall doing that outside of situations when data is crossing system boundaries. The vast majority of languages have an unsound type system, yet people are productive in them. Over the years I've come to realise it's a form of nitpicking. You absolutely need it in some applications, but it's not an importa…

The main problem with TypeScript is the default compiler flags are not safe. I understand having things weak when you’re getting the ecosystem up and running, before you have wide adoption. You don’t want to throw too many red squigglies at early adopters and cause them to give up. But these days the default should not allow any. No implicit any. No explicit any. The stdlib should not use it. JSON.parse() should retu…

> You don’t want to throw too many red squigglies at early adopters and cause them to give up.

That's not the reason.

TypeScript's main design goal was to enable developers to gradually introduce types in codebases that spent years being written purely in JS.

There's still demand for this feature and those who start off with TypeScript set their own config anyway.

I've dealt with people using all kinds of escape hatches, but 2/3 of the time it's caused by lack of proficiency in the language.

The rest is either someone being in a hurry or just not serious about their job.

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#48

Post by [deleted] »

sargunv wrote: post #36
teaearlgraycold wrote: post #33

Earlier quoted context omitted.

The main problem with TypeScript is the default compiler flags are not safe. I understand having things weak when you’re getting the ecosystem up and running, before you have wide adoption. You don’t want to throw too many red squigglies at early adopters and cause them to give up. But these days the default should not allow any. No implicit any. No explicit any. The stdlib should not use it. JSON.parse() should retu…

Even with strict flags on, there are failures. A trivial example: function mutateArray( arr: (string | number)[] ) { arr.push(1); } const a: string[] = ["one", "two"]; mutateArray(a); a is now a string[] with a number inside

[deleted]

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#49

Post by [deleted] »

teaearlgraycold wrote: post #38
sargunv wrote: post #36

Earlier quoted context omitted.

Even with strict flags on, there are failures. A trivial example: function mutateArray( arr: (string | number)[] ) { arr.push(1); } const a: string[] = ["one", "two"]; mutateArray(a); a is now a string[] with a number inside

Very interesting. I’m shocked the typescript creators built a system with this failure mode. I guess the solution here is to have tsc change the type of “a” after the call to mutateArray, unless the arr argument is marked as readonly. Is there a name for this failure mode?

[deleted]

Re: High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

#50

Post by rav »

teaearlgraycold wrote: post #38
sargunv wrote: post #36

Earlier quoted context omitted.

Even with strict flags on, there are failures. A trivial example: function mutateArray( arr: (string | number)[] ) { arr.push(1); } const a: string[] = ["one", "two"]; mutateArray(a); a is now a string[] with a number inside

Very interesting. I’m shocked the typescript creators built a system with this failure mode. I guess the solution here is to have tsc change the type of “a” after the call to mutateArray, unless the arr argument is marked as readonly. Is there a name for this failure mode?

In TypeScript it's called "bivariance", which sounds very programming language theory like, but is not a term typically used in academic contexts, since it is unsound almost by default. It's described here: https://www.typescriptlang.org/docs/handbook/type-compatibil...
Post reply on HN