Amazing article! Will save for later reading. I jumped straight to the video to get an overview how it's working, and it seems to reload the contents of the file when it changes, which is cool and surely an improvement. Do people use this when they write web servers? Was trying to find if there is any lib/tool you can include/run to get the functionality, but seems very involved right now.

Seems to be missing the vital functionality of being able to evaluate snippets though, which is the biggest feature missing in Rust.

How exactly do you evaluate snippets in some environment even with REPL? I mean most code in a large system is part of a context that is required at the very least to generate the inputs for your functions. Can't imagine how you could evaluate the these snippets outside of this program environment except in the most trivial cases when dealing with some simple pure functions with only few simple parameters.

Using Clojure as an example (with no regard to quality, not production code and so on). You might have a piece of code like this:

    (defn people-in-scenes [scenes]
      (->> scenes
           (map :subject)
           (interpose ", ")
           (reduce str)))

You could evaluate the full function and then afterwards you evaluate `(people-in-scenes [{:subject "Test"}])`

But, usually you want to evaluate just a piece, in this case we want to evaluate `(->> scenes ...)` but `scenes` is not in scope?

So we evaluate `(def scenes [{:subject "Test"}])` first and now we have scenes in scope wherever we are, with our test data, and we can select arbitrary snippets around the codebase that depend on `scenes` being in scope.

Repeat for all vars that are expected to be in scope, and you can jump around freely.

Sometimes I leave a statement that defines common data-structures to various names within a `comment` block so it's easy to jumpstart this interactive development when you're in a namespace.

There are other ways as well, but normally this is the easiest to get started with and does the trick for most cases.

(I am not OP and I never done lisp.)

>How exactly do you evaluate snippets in some environment even with REPL? I mean most code in a large system is part of a context that is required

This is a bad smell for me. You should always try to split your code in small pure functions that do one thing, it will help you with readability, with refactoring, with testing and depending on environment you could just replace the function with an different one at runtime.

But you still need the types that are required and you need to define the functions that your snippet calls. Those in turn could require their own types and functions and so on. Unless you don't have much in the name of types and so you can easily define whatever you need. That still leaves the functions that snippet depends on.

I try to create new types if needed instead of passing to a function too many parameters. Also say a function needs the user email you don't pass it the big User object you pass only the email.

The issue I hit though is with code that evolves over years, it starts simple and then each team member had to add some new feature and the simple functions get larger and alrger , the number of parameters increases etc , the solution is to take the time and re-analyze the updated problem and refactor or rewrite the solution to be again composed from simple parts that do one thing.

let me know If I misunderstand the thing you said about types, or you referring mainly about REPL

I don't know how close you could get in rust to the kind of productivity lisp development has.

You would need the ability to keep your program running while inside a debugger while you were able to patch memory on the fly (not just replace instructions in a function body - which I reckon I could figure out with the help of that hot reloading in rust link I shared) but replace function signatures at debug-runtime and be able to serialise the image state to disk and arbitrarily resume it later... It just feels like square peg round hole.

Rust has a different development experience than lisp. It doesn't lend itself to stuff like structural editing (which is really fun to watch an experienced dev doing - Emacs lisp videos on yt are a good source for some mind bending productivity)

You do need custom support to do this in Rust, but it's in the works - see https://github.com/google/evcxr for what seems to be the most current effort.

Wow, that looks really cool! Thanks for sharing, gonna give it a try.

Although, the repository seems a bit... Weird. The README ends with:

> This is not an officially supported Google product. It's released by Google only because the (original) author happens to work there.

Why would Google release it if it's not their product/project? Why is it under github.com/google? Do Google own projects that people happen to work on in the free time just because you otherwise work at Google? Something smells fishy here, but wouldn't be the first time Google does fishy stuff.

Google releases lots of projects like this, and yes many software developer contracts hand over all IP: https://news.ycombinator.com/item?id=2208056 (discussion is good but original link is dead).

Google is the legal copyright holder, but that does not mean they want to or have to consider it a product.

Holy fuck, I had no idea. How are developers still working at Google if this is true? Giving up ownership of all projects you do in your free-time?

My understanding (based on second-hand knowledge) is that employees have two "choices" available to them:

* Have a "fairly flexible arrangement" to work on side projects when they want & potentially using Google hardware on work time but in exchange Google holds the copyright & it has to be published under the Google repo with the quoted disclaimer.

* Deal with a bunch more paperwork on per-project basis.

If people don't have a particularly strong attachment to their side-projects the first option is the "low hassle" option for flexibility to do side projects at work.

I would agree it is unfortunate developers don't push back harder against such a wanton "IP" grab by their employer--but hey, I guess that's what we get without collective representation or respecting our own value as developers.