I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box. If you use swift, everything is ref counted, why subject yourself to so much pain for marginal gain.
Tutorials and books should be more open about that, instead of pushing complex lifetime hacks etc., also show the safe and easy ways.
The article gives Java a worse devx rank than Go and I can't agree. Java is at least on par with go in every aspect of devx, and better in IDE support, expressiveness, and dependency mgmt.
Pretty sure by devx they mean something like syntax ergonomics. Because otherwise rust's devx first class (cargo, clippy, crates.io) so kind of a nonstandard definition.
I think it's fair to say Java's "syntax ergonomics" are a little below the rest / somewhat manual like rust or C++ by default.
go's type system is significantly more limited in what it can do for you, as opposed to rust or ts. Limited syntax seems to be one of the overarching design decisions for that language, making it more like C with better concurrency primitives. It can feel a bit limiting at times, but at least they have generics now and you can almost do things like union types by constructing interfaces that mimic them, but it isn't exactly ergonomic.
> I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box
As usual, this depends heavily on what you do. I had written a program where Arc reference counting was 25 % of the runtime. All from a single instance as well. I refactored to use borrows and annotated relevant structs with lifetimes. This also enabled additional optimisation where I could also avoid some copies, and in total I saved around 36% of the total runtime compared to before.
The reason Arc was so expensive here is likely that the reference count was contended, so the cacheline was bouncing back and forth between the cores that ran the threads in the threadpool working on the task.
In conclusion, neither extreme is correct. Often Arc is fine, sometimes it really isn't. And the only way to know is to profile. Always profile, humans are terrible at predicting performance.
(And to quite a few people, coming up with ways to avoid Arc/clone/Box, etc can be fun, so there is that too. If you don't enjoy that, then don't participate in that hobby.)
For the use cases outlined in the OP, a 36% performance gain for an optimization that complex would be considered a waste of time. OP was explicitly not talking about code that cares about the performance of its hot path that much. Most applications spend 90% of their runtime waiting for IO anyway, so optimizations of this scale don't do anything.
> Most applications spend 90% of their runtime waiting for IO anyway, so optimizations of this scale don't do anything.
Again, depends on what you are doing. If you are doing web servers, electron apps or microcontrollers, sure. If you are doing batch computation, games, simulation, anything number crunchy, etc: no. As soon as you are CPU or memory bandwidth bound, optimisation does matter. And if you care about battery usage you also want to go to sleep as soon as possible (so any phone apps for example).
I am not sure the community frowns on these. In fact I use those in almost every Rust code I write. The point is that i can grep for those because Rust does not do it in a hidden way.
There is a significant chunk of the rust community that encourages the use of Arc, clone and Box outside of the hot path. Perhaps you're just hooked up with the wrong part of the community?
You're likely to get more pushback when creating public crates: you don't know if it's going to be someone else's hot path.
But the internal code for pretty much any major rust shop contains a lot more Arc, Box and clone than external code.
F# but not Scala? In TFA F# is only lacking in community and ecosystem. Scala is comparable in popularity to Go or Rust and has access to the entire Java ecosystem and JVM runtime. That should give it the five stars the author is looking for but its not considered.
I think a lot of devs are missing out by not considering Scala 3. I use it with the Zio effect system which brings composable concurrency and transactional memory amongst other features. I don't think there is anything comparable in any of the languages listed in TFA.
Not good ones, and Scala devs are keenly aware they have been going in the wrong direction compared to Go/Rust, in part because of articles like this.
RedMonk shows Scala is comparable to Go and Rust [0] You can see in this chart which plots the number of projects on Github and tags on StackOverflow (ha ha.)
The upper right most cluster has the most popular languages (C++, Java, Python, JS, PHP, TypeScript) then the next cluster has Scala with Rust, Go, Kotlin, R, Swift, etc... That cluster is clearly separate from the next less popular one which has Haskell, Lua, Ocaml, Groovy, Erlang, Fortran, etc... and then you can see the long tail is a big cluster covering the entire lower left half of the chat with a clear gap between it and the upper right half.
I don't think it is a "very, very wrong" statement.
I also kind of wish Rust had a two-tier system where you could opt into (or out of) the full thing.
The lighter version he describes would make some assumptions that reduce not just the mental overhead but importantly the _syntax_ overhead. You cant have Arc<dyn Animal> if what you describe is an Animal and the readability is infinitely more important than performance. But if you could create a system where in the lighter Swift/C#-like syntax things are automatically cloned/boxed while in the heavier Rust they aren’t, then maybe you could use Rust everywhere without a syntax tax.
Based on your description, I think a good library for data structures that are intended to be used immutably would help with some pain points. Something with copy on write support or something like that. It's a powerful style, used it in haskell and it prevents a large class of bugs, almost down to just business logic bugs, which is what you want.
I like the style you're describing, thanks for sharing.
I would disagree with C# having a (-) at Types. The Type system is indeed the most impressing part of .net/C#. having written static analysers for many languages i find the c# type system the most logical and most easy to parse
That might land with native unions but it's not there yet. There's workarounds with OneOf and Dune but those are kind of messy.
I think expressive types on dotnet are possible - I am a big fan of F# and those types are very good. So I think C# will get there but I can't say it's there yet.
Since programming is increasingly offloaded to LLMs and English is the main way engineers interact with code, it's interesting to see how LLMs reason in different programming languages.
In our benchmarking, we've found LLMs perform comparably between languages for one-shot coding submissions, slightly favoring more popular languages. But if you give frontier LLMs a harness and let them iterate / fix compilation errors, they actually significantly outperform in Rust. Meaning, they come up with more insightful ideas when developing Rust, than for example Javascript.
Anecdotally I think AI is quite good at langs with lots of training data: C#, TypeScript Rust.
I also think it's much better with languages with more guardrails and clear syntax: think expressive types (sum types), brackets, and linters / compile checks.
Rust has expressive types and lots of compile checks to avoid classes of bugs via ownership / lifetimes and I think makes it a very good tool for agents to use.
> 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 important requirement most of the time and it's given undue importance by some.
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 return either unknown or a recursive union that defines all valid JSON structures.
I believe it’s largely because of these defaults that the idea that TypeScript isn’t really checking types persists. Without the any type, or loose undefined and null checks, your types are as validated as they can be. The only failure point is deserialization or an import which doesn’t type check. And deserialization has this problem in every language.
When you compile C to machine code the executed binary isn’t checking types. This is no different from Typescript that’s been compiled to JavaScript.
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.
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
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.
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.
That would be the sound way to do things, but it's also surprisingly common for arrays for some reason. It also doesn't get checked compile time in Java, although it does throw an exception because the arrays are type-enforced at runtime at least.
This compiles fine:
class A {}
class B1 extends A {}
class B2 extends A {}
public class MyClass {
public static void main(String args[]) {
A[] array = new B1[1];
array[0] = new B2();
}
}
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...
"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...
Yikes. I've only been using ts for about a year, I had no idea this was considered a "valid" case. Seems like a type error to me. I wonder how they justify this?
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.
Crystal lang deserves a look given the article writer’s preferred language attributes. It has OO paradigms, elegant composability, efficient codegen etc.
I really wish the ruby maintainers had gone with optional inline types like python3 did. Then crystal would simply be a "strict" type mode of ruby. Now we have two basically identical languages with separate communities and libraries. To me it seems... Not ideal.
That said, I laud crystal for doing what ruby would not. It's a great language, but I doubt it'll ever make it to even ruby usage numbers.
I think devx is being misused in this article a bit. Obviously the tooling for java is second to none, aside from maybe the travesty that is gradle.
What they apparently mean is how "ergonomic"/"expressive" the actual syntax and type systems of those languages are. In that case c# is ahead of java by a decent margin. Luckily java is still evolving, usually by stealing many of the good ideas from other languages like kotlin. But overall those are less language and more runtime features like project looms green threads etc.
I agree that rust devx is a bit lacking (not much though tbh), and that as the article suggests, structuring your project in a way to ensure invalid states simply cannot be represented is "the way." However, the assessment of other languages limitations seem a bit off to me, or at least I'm not grokking what they're claiming (a "me" problem in that case.)
What does "types in typescript are lies" even mean? Typescript from my experience has a fairly robust typing system with union types etc that many other languages called out lack (java, etc)
Is it a "lie" because it compiles to js? Compiler guarantees still stand regardless of whether you target IR, bare metal CPU instructions, etc. "any" types are definitely a foot gun, sure, but it I wouldn't call ts' type system a "lie" and not explain what that means. The ts language and ecosystem definitely has it warts, but in general those warts aren't the type system.
EDIT: correction, turns out I was fooled by ts lies all along. They allow clear type violations in several cases by design as pointed out elsewhere in this thread. Shame on them I guess. That said I've been using typescript in strict mode heavily for a year and it's good enough. Apparently there are some knarly edge cases hiding around several corners...yikes
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's not Java.
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) folded back onto Java. Even Scala wasn't worth it, though that's a different question.
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.
When someone mentions High-level rust, gleam comes to my mind. Although the language is functional and not OOP, but at-least from the perspective of type-system its well written and it can also hook into the elixir/erlang ecosystem.
Agree that the types accomplish basically exactly what I want.
If it gets a decent community / ecosystem I think it would be a frontrunner for sure, especially for web apps.
One potential issue is that the runtimes it targets are not that great at processing - they fanout well on BEAM but may not be the best for heavy processing. Not a deal breaker but smth that others like F#, OCaml, Rust can outperform in if the other attributes do well.
If you want to see high level rust, check out Dioxus. It's a web framework, and it's extremely React-like both in architecture but also ergonomics. I actually had AI migrate a JS project to Dioxus and I think it was something like 75% of the code. Pretty decent for a "low level" language.
Most of the Rust code I've read is arc-mutex-slop.
What this optimizes for is not actually having to deal with the pain in the ass that proper Rust is, but still allowing you to be in the cool kids club writing "blazingly fast software", all while writing what's pretty much Java or C#, but with a terrible non-functional garbage collector instead of a state of the art one.
Is this another AI article? What is said about Rust here has been said over and over again, and this brings nothing new to the table. They also always seem to be writing from a place of ignorance. If you're writing "high level Rust" the use of clone or Arc or whatever is negligible. If you're writing an HTTP service, your clone will be so fast it will make literally zero difference in the scope of your IO bound service.
Another observation is developer experience. Again, have you written _any_ Rust? I would argue that the reason Rust is such a joy to use is that the compile time errors are amazing, the way docs are handled are amazing, and so on. I know the eco system for something like Typescript is worlds better, but have you ever tried to _really_ understand what shenanigans are going on behind the scenes on some random hook from say, React? Their docs are so dismal and sparse and make assumptions on what they think you should know. Rust? You go to the doc gen, read what they think you should know as an overview, and if it isn't enough, I can click on "source" to dive deeper. What more could I possibly want?
Perhaps I'm just triggered. The discussion on Rust always seems to be fad or hype driven and almost always have very little to do with how it is to actually use it. If I have to read about compile times, again, I'm going to scream. Of all the languages I've used, it is one of the best in terms of a mature project needing new features or refactors. This is mentioned in some articles, but mostly we hear about "velocity" from some one dimensional perspective, usually someone from the web space, where it is arguable if the person should even bother trying to use Rust in the first place.
Apologies for the rant, but at this point I think Rust as a buzz word for article engagement has become tiring because it seems clear to me that these people aren't _actually_ interested in Rust at all. Who gives a shit what someone on Reddit thinks of your use of clone??
What triggered me was the proposed Arc<dyn TRAIT> as a quick fix. I was highlevel rustin along the learning curve as the article describes until i stumbled uppon dyn-compatible types and object safety.
It is too easy to trap yourself in by sprinkling in Sized and derive(Hash) ontop of your neat little type hierarchy and then realize, that this tight abstraction is tainted and you cant use dyn anymore. As a follow up trigger: This was when i learned derive macros :)
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 of C++ that solved memory problems the most recent versions of C++ don't have anymore, and only survives by aggressive marketing, full of grouping things together that don't belong together, like C/C++. And memory safety / use-after-free.
If C and C++ are basically the same because they have access to manual memory allocation then Rust/PHP are also basically the same.
And Rust's borrow checker only solves use-after-free which statistically are 10% of memory related vulnerabilities. Not "memory safety" of which 60-70% is just array out of bounds.
Really the worst two languages that both only survive in aggressive marketing.
You do not write Rust yet will make blanket absurd claims about Rust being overcomplicated or not solving your problems. The additional comparison of Rust to PHP is also ridiculous for so many reasons it might not be worth even discussing, because it just seems bad faith from the start.
You're missing a very fundamental point here, and this is usually something I find with long time C programmers. C is a great, but old language, with decades of overhead on context, tooling, and lib understanding that make getting in to writing C substantially more difficult than say, Rust. We are still humans, and Rust isn't entirely trying to solve C from a fundamental paradigm of handling memory from a technical point of view, but more from a programmer one. Your comment about solving memory bugs is predicated on perfect human usage of C to not write the bug in the first place, which is precisely one of the many problems Rust is looking to solve.
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.
I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box. If you use swift, everything is ref counted, why subject yourself to so much pain for marginal gain.
Tutorials and books should be more open about that, instead of pushing complex lifetime hacks etc., also show the safe and easy ways.
The article gives Java a worse devx rank than Go and I can't agree. Java is at least on par with go in every aspect of devx, and better in IDE support, expressiveness, and dependency mgmt.
Pretty sure by devx they mean something like syntax ergonomics. Because otherwise rust's devx first class (cargo, clippy, crates.io) so kind of a nonstandard definition.
I think it's fair to say Java's "syntax ergonomics" are a little below the rest / somewhat manual like rust or C++ by default.
Yeah, but worse than Go?
go's type system is significantly more limited in what it can do for you, as opposed to rust or ts. Limited syntax seems to be one of the overarching design decisions for that language, making it more like C with better concurrency primitives. It can feel a bit limiting at times, but at least they have generics now and you can almost do things like union types by constructing interfaces that mimic them, but it isn't exactly ergonomic.
> I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box
As usual, this depends heavily on what you do. I had written a program where Arc reference counting was 25 % of the runtime. All from a single instance as well. I refactored to use borrows and annotated relevant structs with lifetimes. This also enabled additional optimisation where I could also avoid some copies, and in total I saved around 36% of the total runtime compared to before.
The reason Arc was so expensive here is likely that the reference count was contended, so the cacheline was bouncing back and forth between the cores that ran the threads in the threadpool working on the task.
In conclusion, neither extreme is correct. Often Arc is fine, sometimes it really isn't. And the only way to know is to profile. Always profile, humans are terrible at predicting performance.
(And to quite a few people, coming up with ways to avoid Arc/clone/Box, etc can be fun, so there is that too. If you don't enjoy that, then don't participate in that hobby.)
For the use cases outlined in the OP, a 36% performance gain for an optimization that complex would be considered a waste of time. OP was explicitly not talking about code that cares about the performance of its hot path that much. Most applications spend 90% of their runtime waiting for IO anyway, so optimizations of this scale don't do anything.
> Most applications spend 90% of their runtime waiting for IO anyway, so optimizations of this scale don't do anything.
Again, depends on what you are doing. If you are doing web servers, electron apps or microcontrollers, sure. If you are doing batch computation, games, simulation, anything number crunchy, etc: no. As soon as you are CPU or memory bandwidth bound, optimisation does matter. And if you care about battery usage you also want to go to sleep as soon as possible (so any phone apps for example).
I am not sure the community frowns on these. In fact I use those in almost every Rust code I write. The point is that i can grep for those because Rust does not do it in a hidden way.
There is a significant chunk of the rust community that encourages the use of Arc, clone and Box outside of the hot path. Perhaps you're just hooked up with the wrong part of the community?
You're likely to get more pushback when creating public crates: you don't know if it's going to be someone else's hot path.
But the internal code for pretty much any major rust shop contains a lot more Arc, Box and clone than external code.
F# but not Scala? In TFA F# is only lacking in community and ecosystem. Scala is comparable in popularity to Go or Rust and has access to the entire Java ecosystem and JVM runtime. That should give it the five stars the author is looking for but its not considered.
I think a lot of devs are missing out by not considering Scala 3. I use it with the Zio effect system which brings composable concurrency and transactional memory amongst other features. I don't think there is anything comparable in any of the languages listed in TFA.
> Scala is comparable in popularity to Go or Rust
Do you have any numbers to back you up? That statement sounds very, very wrong to me
Not good ones, and Scala devs are keenly aware they have been going in the wrong direction compared to Go/Rust, in part because of articles like this.
RedMonk shows Scala is comparable to Go and Rust [0] You can see in this chart which plots the number of projects on Github and tags on StackOverflow (ha ha.)
The upper right most cluster has the most popular languages (C++, Java, Python, JS, PHP, TypeScript) then the next cluster has Scala with Rust, Go, Kotlin, R, Swift, etc... That cluster is clearly separate from the next less popular one which has Haskell, Lua, Ocaml, Groovy, Erlang, Fortran, etc... and then you can see the long tail is a big cluster covering the entire lower left half of the chat with a clear gap between it and the upper right half.
I don't think it is a "very, very wrong" statement.
[0] https://redmonk.com/sogrady/files/2025/06/lang.rank_.125.wm_... which comes from https://redmonk.com/sogrady/2025/06/18/language-rankings-1-2...
I also kind of wish Rust had a two-tier system where you could opt into (or out of) the full thing.
The lighter version he describes would make some assumptions that reduce not just the mental overhead but importantly the _syntax_ overhead. You cant have Arc<dyn Animal> if what you describe is an Animal and the readability is infinitely more important than performance. But if you could create a system where in the lighter Swift/C#-like syntax things are automatically cloned/boxed while in the heavier Rust they aren’t, then maybe you could use Rust everywhere without a syntax tax.
Based on your description, I think a good library for data structures that are intended to be used immutably would help with some pain points. Something with copy on write support or something like that. It's a powerful style, used it in haskell and it prevents a large class of bugs, almost down to just business logic bugs, which is what you want.
I like the style you're describing, thanks for sharing.
I would disagree with C# having a (-) at Types. The Type system is indeed the most impressing part of .net/C#. having written static analysers for many languages i find the c# type system the most logical and most easy to parse
C# is missing expressive types for me.
That might land with native unions but it's not there yet. There's workarounds with OneOf and Dune but those are kind of messy.
I think expressive types on dotnet are possible - I am a big fan of F# and those types are very good. So I think C# will get there but I can't say it's there yet.
C# has indeed finally gained sum types this year… in preview. We’ll see if anything makes it into C#15 but they’re closer than they’ve ever been.
Type unions only at first, but there's more being planned.
Since programming is increasingly offloaded to LLMs and English is the main way engineers interact with code, it's interesting to see how LLMs reason in different programming languages.
In our benchmarking, we've found LLMs perform comparably between languages for one-shot coding submissions, slightly favoring more popular languages. But if you give frontier LLMs a harness and let them iterate / fix compilation errors, they actually significantly outperform in Rust. Meaning, they come up with more insightful ideas when developing Rust, than for example Javascript.
Scroll down to the language comparison chart: https://gertlabs.com/?agentic=agentic
Anecdotally I think AI is quite good at langs with lots of training data: C#, TypeScript Rust.
I also think it's much better with languages with more guardrails and clear syntax: think expressive types (sum types), brackets, and linters / compile checks.
Rust has expressive types and lots of compile checks to avoid classes of bugs via ownership / lifetimes and I think makes it a very good tool for agents to use.
Or you can vibe code 350k LOC https://github.com/space-bacon/my_rust_cms/
Production ready!
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 important requirement most of the time and it's given undue importance by some.
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 return either unknown or a recursive union that defines all valid JSON structures.
I believe it’s largely because of these defaults that the idea that TypeScript isn’t really checking types persists. Without the any type, or loose undefined and null checks, your types are as validated as they can be. The only failure point is deserialization or an import which doesn’t type check. And deserialization has this problem in every language.
When you compile C to machine code the executed binary isn’t checking types. This is no different from Typescript that’s been compiled to JavaScript.
Even with strict flags on, there are failures. A trivial example:
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'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
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.
That’s barely scratching the surface.
In TypeScript the following is also valid:
class Something{
}
class SomethingElse{
}
function AddSomething(v: Something)
{
}
var ex = new SomethingElse{
};
AddSomething(ex);
Why does it work? Because in TypeScript as long as you have a “shape” that fits, it’s the “same type.”
Complete and utter insanity to me, to pretend there’s any real type checking, when types are entirely fake and made up.
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.
That would be the sound way to do things, but it's also surprisingly common for arrays for some reason. It also doesn't get checked compile time in Java, although it does throw an exception because the arrays are type-enforced at runtime at least.
This compiles fine:
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
Yikes. I've only been using ts for about a year, I had no idea this was considered a "valid" case. Seems like a type error to me. I wonder how they justify this?
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.
> 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.
Crystal lang deserves a look given the article writer’s preferred language attributes. It has OO paradigms, elegant composability, efficient codegen etc.
I really wish the ruby maintainers had gone with optional inline types like python3 did. Then crystal would simply be a "strict" type mode of ruby. Now we have two basically identical languages with separate communities and libraries. To me it seems... Not ideal.
That said, I laud crystal for doing what ruby would not. It's a great language, but I doubt it'll ever make it to even ruby usage numbers.
Java have less of a DevEx score than C# is crazy work.
Reified generics, value types, nullable reference types, LINQ are only some of the things that would give C# an edge in DevEx today.
I think devx is being misused in this article a bit. Obviously the tooling for java is second to none, aside from maybe the travesty that is gradle.
What they apparently mean is how "ergonomic"/"expressive" the actual syntax and type systems of those languages are. In that case c# is ahead of java by a decent margin. Luckily java is still evolving, usually by stealing many of the good ideas from other languages like kotlin. But overall those are less language and more runtime features like project looms green threads etc.
I agree that rust devx is a bit lacking (not much though tbh), and that as the article suggests, structuring your project in a way to ensure invalid states simply cannot be represented is "the way." However, the assessment of other languages limitations seem a bit off to me, or at least I'm not grokking what they're claiming (a "me" problem in that case.)
What does "types in typescript are lies" even mean? Typescript from my experience has a fairly robust typing system with union types etc that many other languages called out lack (java, etc)
Is it a "lie" because it compiles to js? Compiler guarantees still stand regardless of whether you target IR, bare metal CPU instructions, etc. "any" types are definitely a foot gun, sure, but it I wouldn't call ts' type system a "lie" and not explain what that means. The ts language and ecosystem definitely has it warts, but in general those warts aren't the type system.
EDIT: correction, turns out I was fooled by ts lies all along. They allow clear type violations in several cases by design as pointed out elsewhere in this thread. Shame on them I guess. That said I've been using typescript in strict mode heavily for a year and it's good enough. Apparently there are some knarly edge cases hiding around several corners...yikes
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's not Java.
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) folded back onto Java. Even Scala wasn't worth it, though that's a different question.
There definitely is Kotlin without Java, and you can compile Kotlin code for use in jvm, ios/ipados/macos, android, wasm/js, and native.
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.
can you point to documentation or articles that explain this closed-by-default concept in more detail?
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...
It is called OCaml.
It is absolutely bizarre to not check DevX for Rust, it was literally the most loved programming language for years according to SO surveys.
When someone mentions High-level rust, gleam comes to my mind. Although the language is functional and not OOP, but at-least from the perspective of type-system its well written and it can also hook into the elixir/erlang ecosystem.
Big fan of Gleam! I am keeping my eye on it.
Agree that the types accomplish basically exactly what I want.
If it gets a decent community / ecosystem I think it would be a frontrunner for sure, especially for web apps.
One potential issue is that the runtimes it targets are not that great at processing - they fanout well on BEAM but may not be the best for heavy processing. Not a deal breaker but smth that others like F#, OCaml, Rust can outperform in if the other attributes do well.
No code examples? Wtf?
If you want to see high level rust, check out Dioxus. It's a web framework, and it's extremely React-like both in architecture but also ergonomics. I actually had AI migrate a JS project to Dioxus and I think it was something like 75% of the code. Pretty decent for a "low level" language.
Most of the Rust code I've read is arc-mutex-slop.
What this optimizes for is not actually having to deal with the pain in the ass that proper Rust is, but still allowing you to be in the cool kids club writing "blazingly fast software", all while writing what's pretty much Java or C#, but with a terrible non-functional garbage collector instead of a state of the art one.
> Most of the Rust code I've read is arc-mutex-slop.
Skill issue
> terrible non-functional garbage collector
What garbage collector?
Is this another AI article? What is said about Rust here has been said over and over again, and this brings nothing new to the table. They also always seem to be writing from a place of ignorance. If you're writing "high level Rust" the use of clone or Arc or whatever is negligible. If you're writing an HTTP service, your clone will be so fast it will make literally zero difference in the scope of your IO bound service.
Another observation is developer experience. Again, have you written _any_ Rust? I would argue that the reason Rust is such a joy to use is that the compile time errors are amazing, the way docs are handled are amazing, and so on. I know the eco system for something like Typescript is worlds better, but have you ever tried to _really_ understand what shenanigans are going on behind the scenes on some random hook from say, React? Their docs are so dismal and sparse and make assumptions on what they think you should know. Rust? You go to the doc gen, read what they think you should know as an overview, and if it isn't enough, I can click on "source" to dive deeper. What more could I possibly want?
Perhaps I'm just triggered. The discussion on Rust always seems to be fad or hype driven and almost always have very little to do with how it is to actually use it. If I have to read about compile times, again, I'm going to scream. Of all the languages I've used, it is one of the best in terms of a mature project needing new features or refactors. This is mentioned in some articles, but mostly we hear about "velocity" from some one dimensional perspective, usually someone from the web space, where it is arguable if the person should even bother trying to use Rust in the first place.
Apologies for the rant, but at this point I think Rust as a buzz word for article engagement has become tiring because it seems clear to me that these people aren't _actually_ interested in Rust at all. Who gives a shit what someone on Reddit thinks of your use of clone??
What triggered me was the proposed Arc<dyn TRAIT> as a quick fix. I was highlevel rustin along the learning curve as the article describes until i stumbled uppon dyn-compatible types and object safety.
It is too easy to trap yourself in by sprinkling in Sized and derive(Hash) ontop of your neat little type hierarchy and then realize, that this tight abstraction is tainted and you cant use dyn anymore. As a follow up trigger: This was when i learned derive macros :)
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 of C++ that solved memory problems the most recent versions of C++ don't have anymore, and only survives by aggressive marketing, full of grouping things together that don't belong together, like C/C++. And memory safety / use-after-free.
If C and C++ are basically the same because they have access to manual memory allocation then Rust/PHP are also basically the same.
And Rust's borrow checker only solves use-after-free which statistically are 10% of memory related vulnerabilities. Not "memory safety" of which 60-70% is just array out of bounds.
Really the worst two languages that both only survive in aggressive marketing.
You do not write Rust yet will make blanket absurd claims about Rust being overcomplicated or not solving your problems. The additional comparison of Rust to PHP is also ridiculous for so many reasons it might not be worth even discussing, because it just seems bad faith from the start.
You're missing a very fundamental point here, and this is usually something I find with long time C programmers. C is a great, but old language, with decades of overhead on context, tooling, and lib understanding that make getting in to writing C substantially more difficult than say, Rust. We are still humans, and Rust isn't entirely trying to solve C from a fundamental paradigm of handling memory from a technical point of view, but more from a programmer one. Your comment about solving memory bugs is predicated on perfect human usage of C to not write the bug in the first place, which is precisely one of the many problems Rust is looking to solve.
> 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.