From C++ to Clojure: Jank language promises best of both

Maybe I should play some advent of code games with it to get comfy!

For example, I’ve always thought that the interesting part of Erlang is Beam & the uninteresting part was a niche language. Beam with JS as the language is much more approachable & leverages a rich existing ecosystem of tooling & libraries. Indeed, if you look at it the right way Cloudflare Workers is exactly that; isolated virtual processes within a single OS process that communicate with each other using a message based IPC & if they crash just the microservice is taken down & transparently relaunched.

So from that perspective, why Clojure instead of the same features on a different more popular language?

Emacs is easily programmable (and in lisp), more unixy than modern Linux, like a whole operating system. Lispers make tools for it because it's very easy for them. Lisp tools have been far advanced of others; LSP wasn't initially adopted in Lisp communities because better tools (swank) were already around.

Does vim display inline graphics in a repl, with editing capabilities?

This is one of the basic features of classical graphical Lisp environments from the 1980's, IPython and Jupyter notebooks, or better, Mathematica are only building upon this.

Emacs and vim are not quite at the same experience level.

As an Emacs user that has to work in teams of non-Emacs users, the answer to this boils down to culture and ecosystem maturity.

Purely technically, there's nothing that Emacs allows me to do with REPL Driven Development that _couldn't _ be done in another editor. Practically? I still haven't been able to even get (sufficiently) started with any editor.

I often have to work on a Rails codebase that takes tens of seconds just to start. Dev cycles in the traditional Edit-Restart flow were so painful that I wished badly to burn this codebase down and rewrite it all in a language and style that supports a Lisp-style REPL. Then I discovered inf-ruby.el in Emacs. It allows me to just edit the code and reload only what's changed. It automatically inserts the correct `module Xyz; ...; end` etc. No more restarts.

I showed it to my coworkers. They shared the pain with restarts. And yet, to this day, none of them have an equivalent to inf-ruby in their editors.

inf-ruby.el is less than 1400 lines of code. It's easy enough to implement in Vim, IntelliJ, VS Code, anything really. But it exists only in Emacs, so far. Why? I'm sure because some Emacs user, once upon a time, wished similarly to have a more Lispy REPL for their Ruby dev work, and just built it. Because they were used to it, from having used Emacs or other Lisps with Emacs.

Compare that to when I first tried to support Common Lisp development on VS Code. A language that already has full support for REPL Driven Development with an interactive debugger built-in. Nope, we aren't gonna use any of that, because in VS Code land, we use LSP. A model that really only works for languages that can be statically analyzed. You want Go To Definition on a method that's included from a module and called on a receiver that's a dynamic variable? Well, sucks to be you, I guess.

So, while people make do with the severe limitations of Solargraph or Ruby-LSP, I use robe.el — which adds lisp style code intelligence by running inside your Ruby process — and get code intelligence that actually works with a language as dynamic as Ruby. Again, robe.el was just there for me to use. Again, there's nothing about Emacs that makes robe.el possible in Emacs but not in other editors. Again, there's no equivalent to it (that I've found) in the ecosystems of other editors.

It's not a "prerequisite" per-se, although I guess you just never stumbled upon the fundamental truth about Emacs. In fact, it's not just an ordinary editor, it's a "Lisp Machine". Of course Emacs is far from the actual implementation of a Lisp machine, therefore the quotes.

Emacs feels like a Lisp REPL with a built-in editor, and not the other way around. Once you immerse yourself into the world of Lisp, sooner or later you will realize - Emacs is far from the ideal implementation of a Lisp machine, yet it's the best practical one we have today.

Chords, shmords, modes, modality, non-modality, keymaps, keybindings, etc. - that all is just "higher-level interface" you can change to your liking. I consider myself a die-hard Vimmer, never ever thought about switching to Emacs, until one day I woke up with realization that Emacs actually vims better than Vim and Neovim.

There's something "magical" about Lisp - coders either love it or hate it with passion, but anyone who accepts it, with all its flaws and powerful features, those who embrace the dynamism, the malleability of the structure - they may open a beautiful world of countless fascinating ideas. And once someone opens their heart to Lisp, either with sadness or with joy they sooner or later realize - Emacs is just the best practical tool to work with Lisp, there's simply nothing better. Even though "the best" doesn't mean "the best possible", it just means "the best today".

I've been debating trying my hand at making a simple game engine...it would be great if I could use a Lisp to do it.

In particular, whether it is restricted in practice to types that are std::is_trivially_relocatable.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p11...

https://fennel-lang.org/

I.e. if you're not tracking ownership in new-lang, you're probably doing it very wrong.

My point was that ownership has become a language feature that I expect, like lexical scope has become a language feature that most people expect.

It complements persistent immutable data-structures extremely well, especially in terms of performance via automatic transient-ication, and if you're operating in the native space I can't imagine that performance isn't on top of the list.

So in that sense, great language, please consider evolving beyond Clojure (archaic?) ownership model, because I'm pretty tired of Rusts bloated syntax and lovecraftian macro system.

You are right in that immutability or more precisely the persistence that copy-on-write brings somewhat solves many of the issues that ownership also solves.

Persistence allows you to not care as much about who owns what, because whenever something is modified it is simply copied (with structural sharing), so you know that whatever you have is local anyways, not because you are the only one who has exclusive access to the thing, but because you make a copy of it at the point where answering that question would matter.

But you miss out on two things from that:

- Performance: Those copies are cheap but not free. Borrowing complements _persistent_ immutability in that regard extremely well, because it allows you to check if you're currently the only one using something and modify it mutably in that case. Clojure has a concept called transients, where you create an intermediately mutable version of an immutable thing to perform batch updates, but you still have to manage that yourself, with ownership it happens magically behind the scenes.

- Exclusive types: The other comment I wrote contains an example of this. I have an `ExclusiveID` type in my Database that is similar to a `row_id`. I can recover a lot of the capabilities of transactions and software transactional memory from these, simply because a user can rely on `ExclusiveID`s existing only at a single point at a time in their code. And `ExclusiveID` itself is a completely immutable thing, but the "contract" on how it can be used is what makes it powerful.

Immutability on a domain logic level also does not help you when it comes to dealing with inherently immutable things like devices and networks, whereas ownership does.

So I would argue that those two concepts are complementing each other extremely well, both implementation wise, but also in terms of a the mental model of how your code works.

Being immutable isn't some "best-practice" like eating your veggies, where the more you eat, the healthier you are, and occasional sugar is OK.

I either can reuse the result of getFoo() or I can't. If getFoo() is 99% immutable - as the caller, it's my job to consider taking locks and/or making defensive copies.

If I want to publish library code that calls getFoo(), now my callers will need to consider taking locks and/or making defensive copies.

Your question was about Rust ownership, and I answered about Haskell immutability - but they're both the same in that they're pretty strict compiler rules, and you have to stray into unsafe territory to violate them.