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 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.
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.
Crystal lang deserves a look given the article writer’s preferred language attributes. It has OO paradigms, elegant composability, efficient codegen etc.
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.
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.
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?
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??
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.
> 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.
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.
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.
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!
Swift is a great language, sadly hampered by poor stewardship with terrible compile times, small community outside of apple ecosystems, etc.
I do hope it improves. Having a second compiler vendor that actually cares about making it usable without reaching for 3p compiler caching hacks would go a very, very long way.
I think it's because majority of people using Rust come from C++ where the devx is way worse. But I think what pulls down the devx is the perceived steep learning curve, plus lifetimes.
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.
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.
Overlooked? It's one of the most used languages of all time maybe second only to C.
The distain likely comes from a time period of its history where "Enterprise" patterns had been taken to an absurdist end before the community final regained it sanity. Modern java is quite expressive and ergonomic.
Those in industry in those enterprise days simply got sick of those silly FactoryFactory classes and their like.
Today there's almost no "boilerplate" as they've even made it nice even for scripting use cases and allow floating main methods, var, etc.
However, to actually compete with rust they'd need first class native support and an ARC GC replacement. Iirc they already have "pluggable" gc implementations so it's not out of the question. Java tends to be fairly conservative in features though, so may take a couple decades to get there if they even care to.
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.
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
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
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.
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.
41 comments
[ 3.0 ms ] story [ 86.9 ms ] threadI like the style you're describing, thanks for sharing.
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.
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.
Is that normal? Or does someone just really need to close some stale bugs?
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.
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.
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.
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??
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.
> 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.
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.
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
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.
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.
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.
I do hope it improves. Having a second compiler vendor that actually cares about making it usable without reaching for 3p compiler caching hacks would go a very, very long way.
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.
The distain likely comes from a time period of its history where "Enterprise" patterns had been taken to an absurdist end before the community final regained it sanity. Modern java is quite expressive and ergonomic.
Those in industry in those enterprise days simply got sick of those silly FactoryFactory classes and their like.
Today there's almost no "boilerplate" as they've even made it nice even for scripting use cases and allow floating main methods, var, etc.
However, to actually compete with rust they'd need first class native support and an ARC GC replacement. Iirc they already have "pluggable" gc implementations so it's not out of the question. Java tends to be fairly conservative in features though, so may take a couple decades to get there if they even care to.
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.
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