I'm not quite sure how that follows - I commit things all the time that cause either the main build or tests to fail. And a faithful representation of what was on my machine at a certain time in the past doesn't help me find bugs.

What helps is when each commit represents a single atomic change that I can easily understand, it has a clear commit message and it builds and the tests pass. To acheive this I often need to rewrite history, but doing so doesn't diminish my ability to find where I introduced bugs later on.

So I feel that rebase workflows are better for both readability _and_ bisection.

What I think is problematic is rebasing entire branches weeks after their commits have last been touched. The more you rely on manually looking through commit histories, the more you're encouraged to do this.

EDIT: something I forgot to mention in my original comment as well is that it rebasing makes collaboration harder. Basically, overall, we spend a lot of effort working around the drawbacks of rebasing, when we should be trying to eliminate the need to rebase in the first place.

Doesn't the focus on immutable data make most of the ownership stuff redundant? My understanding was that ownership lets you be sure that you're the only mutable owner of a resource, or otherwise that you share the resource immutably. If data is (almost) always immutable, which seems to be a founding principle of Clojure, then what does ownership/borrowing buy you?

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.

Java interop breaks things of course, much like unsafe Rust breaks guarantees of that language.

  getFoo() = getFoo()

Immutability guarantees if I call getFoo(x) I can trust that nothing happens to x (assuming x is proper Clojure data and not some unsafe other thing like a Java Object). And getFoo can likewise return anything without there being any risk that anyone else modifies that thing. It does not matter who owns x or who owns the return value from getFoo, since no one is able to modify those things anyway.

* Database request was a bad example as, as far as I know, there is nothing built-in for supporting that, so that would already be in unsafe Java territory. But there are non-pure functions built into the Clojure standard library that getFoo could call to return different results on the same input, like slurp or deref, and probably many other ones (I have not used Clojure for a long time).

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.

Some data from a U.K. funded study suggested the median was 2.44 here in winter and 2.8 not in winter.

I couldn't see a single idea or wordplay that actually made sense or elicited anything like a chuckle. The model _nearly_ got there with 'krill' and 'kill', but failed to actually make the pun that it had already identified.

Also I can't help but think that if it had written out a few example jokes about animals rather than simply "thinking" about jokes, it might have come up with something better

I guess one might argue that 1-based indexing could cause beginners to get confused when they move to another language. But maybe it's good for them to get used to the idea that things like this can be different across languages.

The main struggle people have learning to code is getting over the initial frustration hurdle where they can't actually accomplish anything yet. What they have to get them through this is excitement about their actual goals. With lua you burn too much goodwill and beginner spark on debugging string manipulation functions that don't seem important to the actual interest or goal that brought them to programming. Or figuring out how to use luarocks so you can make http requests, or regex, or whatever.

> 1-based indexing could cause beginners to get confused when they move to another language.

This is so far from the problems that beginners actually have. You should teach some programming, it's a really fascinating experience that will mess with your intuitions about how people learn this skill, and what's hard about it.

I'm quite interested in this topic, since I would like to write a good book to introduce absolute beginners into the world of programming. I have a good and encompassing knowledge about many different languages, nevertheless I lack teaching experience.

In your opinion, which languages are good candidates as a first choice and what do you think about using a Lua game framework, like for instance Love2D to teach programming (instead of raw standalone Lua)? The idea being that instead of clunky low level awkwardness, like string manipulation, students would instead see geometrical shapes moving on a screen with just a bunch of simple and imperative statements. Would that provide a better motivation?

But when people decide to learn programming now, they usually have a goal in mind so the best language is the one that lets them keep that objective in focus as they learn. Not necessarily do it most easily: love is good because while making a game with it is a huge undertaking for a novice, they can see the whole time that game-making is what they're building up to.

But for example I've seen rank beginners get really fascinated with data visualization, or interacting with their local government's API, or text generation, or audio stuff. All things that are going to be out of reach for a novice in lua. And a lot of people will show up saying they want to make games, but it's because video games are the one programming artifact they have positive experiences with. Once they start to see the broader possibilities other interests develop.

Anyway I have had a lot of success introducing programming with roblox scripting. It adds a lot of the "missing" lua library features and the script editor is a decent basic IDE that simplifies tooling, another huge pain point for novices.

For non-game focused beginners I've had the best results in ruby. Python works as well once you get going but the whitespace is a frustrating time sink in a classroom environment. In these the strength is being able to grab a library for any API they'd want to work with, and build something that feels like an actual useful tool to them.

I've had some success introducing programming in Lua to kids (ages 7-12) by way of the OpenComputers Minecraft mod. They were all already into playing modded Minecraft, and getting in-world feedback from running various commands (turning on/off redstone signals, moving around blocks, attacking monsters, etc.) meant that the "boring" time between "hey, let me show you how to program" and something exciting happening was <5 minutes. Beyond Minecraft-specific libraries, the computers in the mod also come with a HTTP client library, an editor and a shell that directly runs Lua scripts.

My friend was like "no way. im gonna start him with something simple like html."

Within seconds he realized he had to explain what paths were, and his brother struggled so much with them. My friend took for granted what he had already spent time learning. He was unable to guess what would be difficult to understand without priors.

Walled gardens like Processing seem to be better for education.

Downloading archives with a web browser and extracting them and just doing manual file management is vastly preferable in such an environment. That is a vastly simpler process which is impossible to break, and odds are the student will already be familiar with most of the process.

Managing archives is not easier in my experience, for the format I teach. Students are not necessarily using the same packages, not all on the same OS, and familiarity with manually managing files cannot be assumed. Probably the majority of middle schoolers I teach do not have that skill coming into my class, high school maybe 50/50.

The creator of Lua once visited my university, he told us about the 1-indexing (it looked like this is the thing that everybody asks him). Lua was created in a time that 0-indexed languages wasn't so dominant over the 1-based languages.

Lua is older than Java and JS, and a few years newer than Perl and Python. Before those, as far as I remember about more popular languages: C and C++ are 0-indexed; COBOL, MATLAB and FORTRAN are 1-indexed; Pascal can be 0 or 1 indexed, but its for loop is better suited for 1-indexed.

This way, there wasn't a strong bias to use 0-index in a new language as we have today, they could use what made more sense. Since it was created for engineers used to math notation (sum, products and matrices generally are 1-indexed) and without background in programming, they have chosen to start in 1.

*However*, about using Lua for studying algorithms and data structures, some books use 1-indexed arrays in their pseudocode, notably CLRS' Introduction to Algorithms. When I was studying algorithm analysis using CLRS I used Lua to implement them. I still prefer 0-indexed languages, though.

Indeed the 1-based indexing, which often generates heated discussions, could be a source of confusion later on. However, like you mentioned, it can also prompt the beginner to quickly understand the languages are just tools, which have slightly different ways to be used, depending on what they're trying to solve.

In fact, this 1-based indexing is by convention (although everyone uses it), once again showing how flexible and "hackable" Lua is.

    > array = {"A", "B", "C"}
    > array[1]
    A

But at inference time it’s not referring to that data at all. Some of the data is aliased and encoded in the model’s weights, but we’re not sure exactly what’s encoded.

It may very well be that vague concepts (like man, woman, animal, unhealthy) are encoded, but not details themselves.

Further, at inference time, there is no kind of “referencing” step. We’ve just seen that they can sometimes repeat text they were trained on, but sometimes they just don’t.

The LLM based systems you’re probably using do some RAG work to insert relevant information in the LLM’s context. This context still is not being referred to per se. An LLM might have a document that says the sky is red, but still insist that it’s blue (or vice versa)

So while the info an LLM may have available is limited by its training data and the RAG system around it, none of that is guaranteed at inference time.

There’s always a significant chance for the LLM to make up bullshit.

An AI tourguide which presents the nearest geotagged Wikipedia pages to the user's location and then produces an entertaining summary of your chosen topic on request. It's just a simple mashup of Wikipedia, MaxBox and OpenAI APIs.

A "leaving the house" dashboard for my wife. It's displayed on a tablet near her mirror, and shows weather and live public transport information to reduce the "I missed the bus and I didn't realize it's raining" disasters that get her day off to a bad start.

I've had a lot of fun making these with Gleam. It has the "if it compiles, it usually works" factor that people love about Rust, with none of the complicated borrow-checking rules. It's very simple - once you're up and running, there's not a lot more to learn about the language and you can just focus on modelling your problem.

If you write JavaScript like it’s Java and really lean into OO, then Elixir will be more alien and force you to learn some new patterns.

The only major difference between them is the typing and the syntax I'd say.

If I were to try to make the argument for you, I'd point to some of Elixir's more powerful abstractions like protocols and macros as a reason Elixir might be harder for JS devs. In reality, though, I found it very straightforward to learn as a JS dev, and that was back in 2016 when the documentation was much worse.

I agree this loses some of the spirit of the original rave scene, but as an older person now it fits better for me. If the original late-night scene is dying it's because the younger generation doesn't care very much for this kind of night out.

  It's 5pm on Sunday
  No one knows we're dancing
  Outside the sun is blinding
  No one knows we're dancing