Then explain Go :-D
Go is a rare specimen: a programming language designed by people who are fundamentally suspicious of the field of programming language design.
Readit Newsameliaquining commented on The Core of Rust jyn.dev/the-core-of-rust/... · Posted by u/zdw
I think an interesting component is that you might also want “semi linear types”: types which are purportedly linear but can be dropped as an unwinding backstop.
For instance if you’re dealing with database transactions you probably want to make it explicit whether you commit or rollback, but on panic you can likely allow the transaction to be cleaned up automatically.
Most Rust ORMs and query builders expose a transaction API that takes a closure and runs it inside the transaction, rolling back on unwind or (in most cases) if it's not explicitly committed. This is the most common idiom in Rust for dealing with situations where you want to pass extra data to or from a cleanup routine. Unfortunately, for the async use case in particular it happens to be unsound: https://tmandry.gitlab.io/blog/posts/2023-03-01-scoped-tasks...
Well no, some objects (notably Cell<>) require Copy, because clone(&self) takes a reference and can do arbitrary things with the Cell (including overwriting the data its ref points to via Cell::set())
I suppose you'd need a Copy-like auto trait to serve as a bound on impl Clone for Cell<T>. It wouldn't have to be magical the way Copy is, though.
ameliaquining commented on Google did not unilaterally decide to kill XSLT meyerweb.com/eric/thought... · Posted by u/bkardell
I have lots of ideas for things that can just be removed.
We could remove framesets and remove var from javascript. Remove the Date object now that there is a Temporal api. Remove tables and flexbox now that there is grid. xhr can go too now that we have fetch. The <center> tag isn't needed anymore. I'm sure we can find support from people disliking onclick and onsomething attributes. Or how about hoisting? Surely we can simply rm that? Removing things doesn't have to be limited to older things. asm.js and web workers weren't really necessary at all.
I'm fountain of good ideas.
The idea is not to just remove things for the sake of removing things, but to engage in a cost-benefit analysis. Most of the things listed above either are very widely used or don't cost much or have other downsides to maintain. By contrast, when things have been removed from the Web platform in the past, it was because they were causing problems out of proportion to the amount of breakage induced by removing them. In the case of XSLT, the problem is the attack surface that it adds.
I think a version of Rust in which catching panics is unsafe would be entirely justifiable and probably should have been more strongly considered.
This is one of many things that could have been done to solve the unwinding-through-linear-types problem, if it were still possible to make backwards-incompatible changes to the language.
I'm actually unconvinced you could do without `Copy`. It's both in the core of the language and essentially required for stuff like shared references to work correctly. Copying could be replaced by a keyword instead of happening implicitly, but that's different from removing the concept entirely from Rust.
The rest, sure, you could do without (reborrowing can't be emulated but I don't think it's strictly necessary to write real code). I'd add catchable exceptions and the use of traits instead of explicit modules as things that I think tremendously complicate the language semantics and are almost certainly not strictly necessary to achieve Rust's language goals.
You can already write a Rust program that never relies on Copy, by explicitly calling .clone() whenever you need to copy something. It's just that this would be insane.
I think we are using different meanings of the term "cohere" and I am not sure how to reconcile them. I agree that Rust with async is a more useful language. I don't think being useful implies anything about how coherent a language is (I would point to bash and perl as examples of useful languages with very little coherence). "Coherence" to me means that all the features fit together tightly and are designed with each other in mind, and I don't think that's the case for async and const in Rust—simply because they aren't finished being designed.
Is it ever possible for removing a feature from a language to make it less coherent?
There are at least workarounds for a surprising number of languages: https://dbohdan.com/scripts-with-dependencies
Read up on the details of each one when proposing the design for Cargo script to see what we could learn.
I would argue that third-party tools don't really cut it, because a lot of the value is being able to include a script inline in, e.g., an email or chat message, and that's undermined if the recipient has to download and install a separate tool. (uv gets half credit because adoption is rapidly rising and it has a shot at becoming a de facto standard, but I'll only award full credit to Python when pip supports this.) They're good for exploring the design space, though.
* Same names: fn, let, mut, pub, println, etc.
* Same everything-is-an-expression style. Blocks evaluate to the last expression in them.
* /// Doc comments
* ML style pattern matching
* Result type
* 'todo', 'panic'
"Whhaaa but you can find those features in other languages! You literally said ML-style you big idiot!!"
Indeed but Rust massively popularised a lot of those features (how many people actually use ML?) and the number of them makes it almost impossible that it isn't at least strongly inspired by Rust.
Interestingly they have fixed the tuple syntax issue - it's #(a, b, c) - but have copied the match pattern matching mistake where you can write what looks like a variable name and it becomes a pattern. That mistake has been known since the 70s.
I think basically everybody who designs programming languages is familiar with ML, even if it's not used in production all that often.
> So what exactly is the "much smaller and cleaner language struggling to get out" of Rust? If I'm understanding the post right, that language still has references, lifetimes, traits, enums, etc., because all of those features cohere; you can't remove just one and expect the rest of the language to still work. Once you grant all those features, your language isn't much smaller or cleaner than Rust; your language pretty much is Rust.
I think there's an argument to be made that you could in fact make a simpler language than Rust while keeping the core concept. This variant of the language would remove:
- the Copy trait
- reborrowing
- deref coercion
- automagic insertion of `into_iter` in loops
- automatic call to drop at the end of scope (instead you'd have to call it by yourself or get an compiler error)
- trait bounds having an automatic `:Sized` bound by default.
- lifetime elision
- no “match ergonomics”
- and likely a few other pieces of “magic” that can be hard for beginner to grasp, but that's what I had at the top of my head.
This language would be much simpler, by having fewer concepts and a lot less “magic”, but it would also be much more cumbersome to use in a day to day basis, as all of the above are clever workaround designed to make common tasks as straightforward as possible, and I don't think anyone would prefer to use it than using Rust itself. It may be useful as an instructional tool when introducing Rust to students though.
Do those features actually cause difficulty for anyone other than compiler engineers, compared to not having them? I haven't personally seen, e.g., newbies stumbling over them; they're actually designed remarkably well to fade into the background and Just Work (i.e., you don't notice they're there, but you definitely would notice if they went away). Yes, there's something to be said for minimalism in language design, but Rust without those features still isn't very minimalistic, so dropping them would seem to bring about most of the costs of minimalism without the benefits.