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.
> 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.
Adding a few borrows and annotations is not "an optimization that complex"; use Arc at first but then find those bottlenecks via profiling then fix them.
> 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).
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.
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 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.
If you use Nim, it's value semantics by default. Everything (and I do mean everything, all types primitive to composite) is managed by the stack, including stuff that needs to hold a heap pointer. All lifetimes are scoped. You only get ref counted types when you opt in.
It's astoundingly easy to build software with that behavior set. Even if the occasional copy is necessary, you're paying a far lower cost for it than for an interpreted language. Slice off a couple important components into stateless executables built like this, and it's clean sailing.
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.
> 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.
I agree. Ironically have inherited a lot of projects where they picked a "type-safe" language but didn't properly type the system boundaries, including RPC and database. Wrong priorities there.
Adjacent to the article... there are a lot of bits from WCF I really liked and miss. I didn't really like a lot of the default way to use it... I generally would combine all the interfaces and a client instance generator into a single library to share (as opposed to the XML config crap the people tended to default with).
Today, there's tooling around OpenAPI/Swagger, but I don't think it's nearly as nice as using WCF for the server and client interfaces directly.
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.
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.
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 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 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();
}
}
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.
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...
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
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?
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've been using Rust mostly at a high level myself... Mostly a few Axum web services, or quick CLI tools. Even if you're a little dirty with it (clone instead of fighting the burrow checker or bringing in arc, etc.), it's pretty small, light, portable and performs as good or better than where I usually reach first, which has been a lot of Deno+TS for scripting.
AI has taken this a step further... I'm pretty good at following along with what is happening in Rust even if I don't always remember the syntax while writing myself. I'd say that AI is better at outputting sane Rust than just about any other language I've tried with it.. and that the more planning time you spend, like anything else, the better the output.
I usually am pretty thorough on designing my interfaces/api surface etc well ahead of the code... so doing similar with more details with an AI agent has been somewhat pleasant to work with.
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.
I partially agree, but C++ is the second best agentic language! (of 6 tested). LLMs are pretty good at reading machine output. My pet theory is that it has more to do with the training data in lower level languages being of a more interesting algorithmic variety, on average.
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.
Java has first class sum types, pattern matching, and compiler exhaustion on types. It's probably far more expressive than C# currently until they get union types.
Well, C# has more powerful pattern matching, only compiler exhaustiveness on types is missing today. In Java, sum types (sealed interfaces/classes) require all members to have the same parent, so they can be used only in very narrow cases.
Their sum types aren't particularly useful since they can never be used to implement union types which I believe c# has plans for following their sum types already in preview. So I guess similarly neck and neck.
Not sure if it's still the case, but C library interop in C# is the main reason I chose to start with the alpha/beta versions of C# over Java around 2000-2001.
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.
I strongly disagree with Kotlin being strictly better than Java. It pretends to fix things that haven't been problems in Java for more than 10 years while introducing a layer of syntactic complexity that's completely unwarranted. It just thrives on hype and Android development.
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.
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'm surprised no one in the comments is mentioning Kotlin. Out of all the languages I've worked with it has been the most enjoyable by far. I agree with the article that there isn't much community but I feel like that's arguably the least important category there. You should definitely give it a shot if you've never tried it before.
Is the DX really that bad? You get a world-class package manager, test suite, formatter, linter, with multi-platform builds out of the box for free. Rust definitely has it's edges, but I think education is the problem, not the DX.
> You get a world-class package manager, test suite, formatter, linter, with multi-platform builds out of the box for free.
Yes. Rust is incredible in all these respects, perhaps the best, however the readability is just not good in comparison with e.g. Swift. This is probably due to language limitations like a lack of variadic generics, one of the reasons there are macros everywhere in Rust codebases, which severely hampers readability.
I don't think macros are all that bad myself... I'd say complex lifetimes are probably the hardest thing to grok when reading rust and that you can avoid a lot of that depending on how your code is structured.
One can just use Lean4 and panic each time it asks proof. 5 of 5. Community is PhDs and geniuses. Types are values, full uniformity = simplicity. Perf > Swift because reference counters eliminated at compile time. AI likes types.
Just panic when Lean4 asks for proofs.
Backed by biggest corps out there.
Macro are best of Rust and Scala.
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.
The tooling is getting better and better, thankfully. Just recently they published their official VSCode extension on open-vsx for instance. It’s getting usable now!
... which is what I thought people were referring to.
Yes - it's ref counting, but it's not like 'Arc' at all - ARC is way more thread aware and most 'access' doesn't have to do thread checking. Much faster.
So - using Rust 'Arc' would not be at all like using Swift 'ARC' in the end.
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.
> 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.
I can agree to that. Gleam as a language is still not the best for these things (currently) but it supports the ability to transpile to Javascript and I feel like there are multiple things that gleam can and might be doing to make things faster, so in a sense I am hopeful about their future!
I feel like gleam can be considered as the modern ruby in some sense if one bets on it and to be honest, ruby wasn't slowed by many of these things and even right now some major projects even backend wise are written in ruby (homebrew comes to my mind) so it depends but yea, personally I am a gopher fan. I really love its simplicity for the most part, There are some interesting projects in the golang world where people are starting to transpile to golang from a more rust-y flavour/feeling. Some were on Hackernews recently, I would recommend checking them out if you might have some free time to tinker around!
And thanks for responding to this comment and have a fun time tinkering, personally I really like to sometimes just print hello world in different languages, I don't know what there is about them but printing hello world makes me happy but as such I just know the very basics of a language and I haven't played with them to a deeper level but just basics and watching videos about new languages etc., I like learning about new languages even if I might not use them personally.
I recommend watching tom delande's video of rating languages as well, that video was one of the thoughts which had come when I was reading the article/the discussion: https://www.youtube.com/watch?v=-MbTj8DGOP0 I think you might enjoy it and have a nice day Sirhamy!
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
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.
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 :)
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.
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.
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.
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.
I also program in tons of languages, including Rust, C#, C, C++, PHP and Java, and, no offense, I think you are full of shit.
Haven't had anymore issues programing in C# on Linux than on Windows (if not less).
Rust certainly isn't as complicated as C++, and the complexity over C is well worth it, specially given the better ergonomics. Writing properly safe code on C or C++, however, will basically have you emulate the Rust compiler through tooling or inside your brain, which bears its own complexity.
Don't get me started on the PHP/Rust comparison, what is even the similarity here?
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.
> 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.
Adding a few borrows and annotations is not "an optimization that complex"; use Arc at first but then find those bottlenecks via profiling then fix them.
Fix them if needed, the OP’s point is that for a lot of applications it is not needed.
For most cases you will still be comfortably in the JVM/golang performance window.
Rust is great language, fighting the borrow checker sucks, don’t do it if you don’t need to.
> 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).
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.
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 could see myself picking Java over Go just cause of the error handling
The go tooling and ecosystem and how it "just works" runs rings around the Java clowncar.
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.
If you use Nim, it's value semantics by default. Everything (and I do mean everything, all types primitive to composite) is managed by the stack, including stuff that needs to hold a heap pointer. All lifetimes are scoped. You only get ref counted types when you opt in.
It's astoundingly easy to build software with that behavior set. Even if the occasional copy is necessary, you're paying a far lower cost for it than for an interpreted language. Slice off a couple important components into stateless executables built like this, and it's clean sailing.
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...
The trajectories of Go and Scala here tell a much different story (and one that matches my personal experience looking at job postings): https://innovationgraph.github.com/global-metrics/programmin...
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.
I agree. Ironically have inherited a lot of projects where they picked a "type-safe" language but didn't properly type the system boundaries, including RPC and database. Wrong priorities there.
Adjacent to the article... there are a lot of bits from WCF I really liked and miss. I didn't really like a lot of the default way to use it... I generally would combine all the interfaces and a client instance generator into a single library to share (as opposed to the XML config crap the people tended to default with).
Today, there's tooling around OpenAPI/Swagger, but I don't think it's nearly as nice as using WCF for the server and client interfaces directly.
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 insideWoah, 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.
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.
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:
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.
You can even get nominal typing with branded types if you need it. (Like for the newtype pattern)
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
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
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?
> 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.
With TypeScript 6.0 and above it is indeed much stricter by default.
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.
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.
I've been using Rust mostly at a high level myself... Mostly a few Axum web services, or quick CLI tools. Even if you're a little dirty with it (clone instead of fighting the burrow checker or bringing in arc, etc.), it's pretty small, light, portable and performs as good or better than where I usually reach first, which has been a lot of Deno+TS for scripting.
AI has taken this a step further... I'm pretty good at following along with what is happening in Rust even if I don't always remember the syntax while writing myself. I'd say that AI is better at outputting sane Rust than just about any other language I've tried with it.. and that the more planning time you spend, like anything else, the better the output.
I usually am pretty thorough on designing my interfaces/api surface etc well ahead of the code... so doing similar with more details with an AI agent has been somewhat pleasant to work with.
> I'd say that AI is better at outputting sane Rust
Which is a recent development. A year ago LLM's really struggled with Rust.
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.
I partially agree, but C++ is the second best agentic language! (of 6 tested). LLMs are pretty good at reading machine output. My pet theory is that it has more to do with the training data in lower level languages being of a more interesting algorithmic variety, on average.
Java have less of a DevEx score than C# is crazy work.
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.
Java has first class sum types, pattern matching, and compiler exhaustion on types. It's probably far more expressive than C# currently until they get union types.
Well, C# has more powerful pattern matching, only compiler exhaustiveness on types is missing today. In Java, sum types (sealed interfaces/classes) require all members to have the same parent, so they can be used only in very narrow cases.
As opposed to C# that doesn't have any form of sum types?
C# will have more advanced sum types this year, it's currently in preview.
Their sum types aren't particularly useful since they can never be used to implement union types which I believe c# has plans for following their sum types already in preview. So I guess similarly neck and neck.
Reified generics, value types, nullable reference types, LINQ are only some of the things that would give C# an edge in DevEx today.
Not sure if it's still the case, but C library interop in C# is the main reason I chose to start with the alpha/beta versions of C# over Java around 2000-2001.
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.
Technically yes, but I don't think it could exist without Java.
You can't even read a file in Kotlin without Java.
thats pretty much what I mean, yes.
I strongly disagree with Kotlin being strictly better than Java. It pretends to fix things that haven't been problems in Java for more than 10 years while introducing a layer of syntactic complexity that's completely unwarranted. It just thrives on hype and Android development.
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?
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'm surprised no one in the comments is mentioning Kotlin. Out of all the languages I've worked with it has been the most enjoyable by far. I agree with the article that there isn't much community but I feel like that's arguably the least important category there. You should definitely give it a shot if you've never tried it before.
Is the DX really that bad? You get a world-class package manager, test suite, formatter, linter, with multi-platform builds out of the box for free. Rust definitely has it's edges, but I think education is the problem, not the DX.
> You get a world-class package manager, test suite, formatter, linter, with multi-platform builds out of the box for free.
Yes. Rust is incredible in all these respects, perhaps the best, however the readability is just not good in comparison with e.g. Swift. This is probably due to language limitations like a lack of variadic generics, one of the reasons there are macros everywhere in Rust codebases, which severely hampers readability.
I don't think macros are all that bad myself... I'd say complex lifetimes are probably the hardest thing to grok when reading rust and that you can avoid a lot of that depending on how your code is structured.
It is absolutely bizarre to not check DevX for Rust, it was literally the most loved programming language for years according to SO surveys.
The 5% who use it love it 95%?
One can just use Lean4 and panic each time it asks proof. 5 of 5. Community is PhDs and geniuses. Types are values, full uniformity = simplicity. Perf > Swift because reference counters eliminated at compile time. AI likes types. Just panic when Lean4 asks for proofs. Backed by biggest corps out there. Macro are best of Rust and Scala.
It is called OCaml.
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.
Once union types land, it will just need first class support for checked errors instead of unchecked exceptions flying around everywhere.
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.
The tooling is getting better and better, thankfully. Just recently they published their official VSCode extension on open-vsx for instance. It’s getting usable now!
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...
I meant 'not like rust-Arc' :)
... which is what I thought people were referring to.
Yes - it's ref counting, but it's not like 'Arc' at all - ARC is way more thread aware and most 'access' doesn't have to do thread checking. Much faster.
So - using Rust 'Arc' would not be at all like using Swift 'ARC' in the end.
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.
> If it gets a decent community / ecosystem I think it would be a frontrunner for sure, especially for web apps.
There is! From my understanding, Check out the gleam discord server and communities around it.
There are some good web frameworks in Gleam like lustre. I feel like you are gonna love this guy's videos: https://www.youtube.com/watch?v=3kr4Ydx6GGU
> 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.
I can agree to that. Gleam as a language is still not the best for these things (currently) but it supports the ability to transpile to Javascript and I feel like there are multiple things that gleam can and might be doing to make things faster, so in a sense I am hopeful about their future!
I feel like gleam can be considered as the modern ruby in some sense if one bets on it and to be honest, ruby wasn't slowed by many of these things and even right now some major projects even backend wise are written in ruby (homebrew comes to my mind) so it depends but yea, personally I am a gopher fan. I really love its simplicity for the most part, There are some interesting projects in the golang world where people are starting to transpile to golang from a more rust-y flavour/feeling. Some were on Hackernews recently, I would recommend checking them out if you might have some free time to tinker around!
And thanks for responding to this comment and have a fun time tinkering, personally I really like to sometimes just print hello world in different languages, I don't know what there is about them but printing hello world makes me happy but as such I just know the very basics of a language and I haven't played with them to a deeper level but just basics and watching videos about new languages etc., I like learning about new languages even if I might not use them personally.
I recommend watching tom delande's video of rating languages as well, that video was one of the thoughts which had come when I was reading the article/the discussion: https://www.youtube.com/watch?v=-MbTj8DGOP0 I think you might enjoy it and have a nice day Sirhamy!
Or you can vibe code 350k LOC https://github.com/space-bacon/my_rust_cms/
Production ready!
That’s just the LLM rambling. Not battle tested yet. I will get to that after I ship the Semiotic-Reflexive Transformer.
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
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.
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 :)
cough OCAML cough
[dead]
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.
> terrible non-functional garbage collector
What garbage collector?
> Most of the Rust code I've read is arc-mutex-slop.
Skill issue
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.
> 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.
It works pretty well with Postgres, SQLite and MySQL. You don't know what you are talking about.
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.
I also program in tons of languages, including Rust, C#, C, C++, PHP and Java, and, no offense, I think you are full of shit.
Haven't had anymore issues programing in C# on Linux than on Windows (if not less).
Rust certainly isn't as complicated as C++, and the complexity over C is well worth it, specially given the better ergonomics. Writing properly safe code on C or C++, however, will basically have you emulate the Rust compiler through tooling or inside your brain, which bears its own complexity.
Don't get me started on the PHP/Rust comparison, what is even the similarity here?
This just reeks of bad faith.