you could build an emacs frontend for this model! the thing i am trying to describe is “getting out of the box”. imagine a terminal session that is shared between emacs, iTerm, and a mobile phone ssh’d in over the network, that’s my vision.
> Great, now you just need to build and maintain shims for every tool in existence, force your users to use your own custom tools that support these features, and ensure that everything interoperates smoothly.
An article called "A Spreadsheet and a Debugger walk into a Shell" [0] by Bjorn (letoram) is a good showcase of an alternative to cells in a Jupyter notebook (Excel like cells!). Another alternative a bit more similar to Jupyter that also runs on Arcan is Pipeworld.
I was thinking of Arcan and the Lash#Cat9 setup by the end of your second paragraph. I'm very surprised you had not met it: it seems so directly aligned with your interests and goals, but all you seemed to talk about was Jupyter, a tool which I tried and TBH discarded after 10min.
I talked to Bjorn Stahl quite a bit before writing it, but he is so smart he seems to me to find it hard to talk down to mere mortals. There's a pretty good interview with him on Lobsters:
this is really cool omg! i didn't know that, i'll do some research.
one of the strange things to me about the terminal landscape is how little knowledge sharing there is compared to other domains i'm familiar with. iTerm has a bunch of things no one else has; kitty influenced wezterm but otherwise no one else seems to have valued reflection; there's a whole bunch of extensions to ANSI escapes but most of them are non-standard and mutually incompatible. it's weird. if i compare to something like build systems, there's a lot more cross-pollination of ideas there.
i would describe the main idea of the post as opening up the data model of the terminal. the list of wishes are an example of things you can build once you've done that, not the primary reason that opening the data model is useful.
yeah! so i somehow forgot to include this in the post, but one of the thing i would want as part of this is tab complete that integrates with the shell, essentially it would make an RPC call (in the step 3 sense). there’s things that work like this already today, they’re just extremely cursed ^^ but that’s never stopped me before. https://github.com/Aloxaf/fzf-tab?tab=readme-ov-file#differe...
you were reading very closely, well done. yes, that is my claim, Rust was smaller and cleaner before async and const. I was so indirect about it because many of my best friends work on those features and I wasn’t sure how to word it. fortunately Matklad has worded it very well on the other site: 2015 rust was a more complete language that cohered better, but the vision of Rust is not to cohere perfectly, it’s to be an industrial language that is useful even if it’s not beautiful.
Yeah, in that case I think the link to boats's work obscures the point a bit.
I take what might be a slightly different read of matklad's point; I don't think Rust has much compromised its vision in terms of which broad features to support, but it has on a couple occasions chosen to ship something that wasn't perfect because being useful requires taking only a bounded amount of time to iterate on design.
So Rust 1.0 shipped without async, even though it was known to be needed for some of Rust's core use cases, because it was too far from being ready and it wouldn't do to wait forever. Once that decision was made, it had implications for how async could work; in particular, really doing it right requires linear types, but this wasn't appreciated when Rust 1.0 shipped and it's not a backwards-compatible change, so by 2018 it was off the table. The choice was, do async in a way that works with the existing design decisions, at the cost of some elegance, or don't do it at all. The former choice is not just more "industrial", I would argue that it coheres better, because waiting for multiple events at the same time is a core feature that a language for foundational software has to have, and the combinator-based approach that people were using in 2018 cohered poorly with the rest of the language (e.g., requiring unnecessary heap allocations). So this wasn't really a compromise to coherence.
(This also happened on a lesser scale when async/await first shipped—e.g., specific "async" syntax instead of a more general coroutine feature—because of eagerness to ship something that year. boats has claimed that this was a matter of existential survival for the language; I'm not sure I agree. But while async/await is a bit less conceptually pure than fully general coroutines, I don't believe that any of today's common complaints about async are downstream of the decision at that time to try to ship something quickly; there don't seem to have been a lot of obvious mistakes from then.)
(My understanding is that const has a similar story but I'm less familiar with the design space there, because people haven't exhaustively chronicled its history like they've done with async, perhaps because it's not as heatedly controversial.)
> in particular, really doing it right requires linear types, but this wasn't appreciated when Rust 1.0 shipped and it's not a backwards-compatible change, so by 2018 it was off the table.
It was pretty much off-the-table well before that, because a usable implementation of linear types requires being able to ensure the absence of panics. (A panic must unwind the stack, which amounts to automatically running drop implementations.) The two issues are quite closely linked, and hard to address in isolation.
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...
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.
Yes, but unlike most of the proposed solutions to this problem, this one was (1) seriously considered prior to the release of Rust 1.0, and (2) wouldn't have caused major changes to the way most people write Rust programs in practice. i.e. Rust without panic catching in safe code is still essentially Rust.
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.
Your point on coherence is similar to the perspective of an ex-C++ maintainer. This video came out a decade ago https://www.youtube.com/watch?v=KAWA1DuvCnQ&t=2530s and I feel his lesson went unheeded. It's relevant to the bigger and more dangerous concept of Conceptual Integrity by Fred Brooks.
I think so, yes. If you remove any of the things in the “core” I mention in the post, the language hangs together much worse even though it’s smaller; enums without pattern matching is a simple example.
I’m not just saying that I want to go back to the “good old days”, I really do think that those parts of Rust were designed as a coherent whole, in the same way that Uiua is designed as a coherent whole.
> I understand the point they’re trying to make, that being that rust forces you to explicitly deal with the complexity of the problem rather than implicitly
I read it again and understand what you mean. I apologize for commenting like that so quickly, I was on my phone and typed that comment out before I really had time to digest the contents.
