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

61–70 of 122 posts

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

#61

Post by saghm »

clownstrikelol wrote: post #57
fainpul wrote: post #44

Earlier quoted context omitted.

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.

That’s barely scratching the surface. In TypeScript the following is also valid: class Something{ value: Number } class SomethingElse{ value: Number foo: String bar: SomeOtherThing[] } function AddSomething(v: Something) { v.value += 1; } var ex = new SomethingElse{ value: 3, foo: “TypeScript is fake types”, bar: [] }; AddSomething(ex); Why does it work? Because in TypeScript as long as you have a “shape” that fits,…

That's because it's structurally typed (as opposed to nominally typed). I don't happen to prefer it, but I don't think it's fair to conflate that with unsoundness like the example given above; it's totally possible to have a sound structural type system. TypeScript doesn't happen to be sound, but it's not because of that.

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

#62

Post by stratos123 »

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

Woah, that's quite an issue. The equivalent code in Python doesn't typecheck, since `list` is invariant and hence list[str] doesn't fit list[str|int]. Unusual for TS to handle types worse than Python.

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

#63

Post by saghm »

teaearlgraycold wrote: post #42
sargunv wrote: post #39

Earlier quoted context omitted.

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?

Yes, that's correct. If you're curious for a slightly more concrete source, Wikipedia covers this reasonably well (although citing one often decried source to validate another might not be particularly convincing to some people): https://en.wikipedia.org/wiki/Type_variance#Arrays

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

#64

Post by drzaiusx11 »

drzaiusx11 wrote: post #54
rav wrote: post #50

Earlier quoted context omitted.

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...

Key sentence in their justification seems to be: "allowing this enables many common JavaScript patterns" Honestly at this point they should make a new strict "no js" mode, as the ecosystem likely has reached a tipping point where you can get by without mixing typed and untyped js at compile time. Wonder if targeting wasm directly would help ensure those boundaries are ensured...

https://www.assemblyscript.org/ is pretty darn close, but it would probably be better to converge and not split communities

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

#67

Post by teaearlgraycold »

saghm wrote: post #61
clownstrikelol wrote: post #57

Earlier quoted context omitted.

That’s barely scratching the surface. In TypeScript the following is also valid: class Something{ value: Number } class SomethingElse{ value: Number foo: String bar: SomeOtherThing[] } function AddSomething(v: Something) { v.value += 1; } var ex = new SomethingElse{ value: 3, foo: “TypeScript is fake types”, bar: [] }; AddSomething(ex); Why does it work? Because in TypeScript as long as you have a “shape” that fits,…

That's because it's structurally typed (as opposed to nominally typed). I don't happen to prefer it, but I don't think it's fair to conflate that with unsoundness like the example given above; it's totally possible to have a sound structural type system. TypeScript doesn't happen to be sound, but it's not because of that.

Structural typing is great. It's the verified version of duck typing.

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

#69

Post by jurschreuder »

PhilippGille wrote: post #32
jurschreuder wrote: post #11

I program almost all languages except C# and Rust haha. So someone looking for the perfect languages while actively using the only two languages I actively avoid is very strange to me. C# has close to zero community and only really works properly in Windows which is far past its glory days. Except for Microsoft aggressively pushing it as a Java alternative it has no right to exist. Rust is an overcomplicated subset o…

> C# [...] only really works properly in Windows What do you mean with this? Maybe you are thinking of the old ".NET Framework" runtime, which only runs on Windows? Nowadays there is ".NET Core" which runs on macOS and Linux as well.

Even om Windows .NET does not work properly with mySQL and Postgres it only really works properly with Microsoft MySQL-Clone or I don't know the official name.

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

#70

Post by yearolinuxdsktp »

loglog wrote: post #29
bluegatty wrote: post #27

Java is a fine language and has sufficiently expressive types. It's the most consistently overlooked language and frankly it's completely annoying. Java is a powerhouse. If you can live with a VM, it's an amazing language. The disdain for Java is honestly just weird. The boiler plate is only marginally annoying to write and makes it considerably easier to read. The 'enterprise ecosystem' is definitely bloat, but that…

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’s closed-by-default design choice makes it worse than Java, and thus not strictly better than Java. It’s premature optimization, and a design-up-front-influenced paranoia/fear of any extension in not-designed-for places. But when I write code, I prefer to keep it open to extension, and in practice, I found a lot of value in extending decently written code, that would not be possible with Kotlin without having to go back and modify things to be open.
Post reply on HN