

This looks … great.


This looks … great.
Ha. Lol. That’s bad
Context: this happens if you use patch(1) with patches generated by git format-patch. If you do, you should be using git am instead.


I wouldn’t call it state-of-the-art, but rather maybe most-straightforward or database-agnostic or as-simple-as-they-get


Yes. Highlighting, these selection actions and symbol detection all work with tree-sitter grammars. The whole premise of the editor is a modern-modal-editing with tree-sitter grammars.


I’m a bit surprised helix editor is not mentioned. It is based on tree-sitter grammars and allows for stuff like select-around-function or select-around-argument, to use grammar in the code navigation. Pretty wild and useful.


You are either a crazy nutjob or a genius thinker. Interesting idea


I do believe that it is possible to translate any SQL query to Lutra, that is Lutra can cover that last 1% of cases. There are a few caveats:


Two great questions!
First one comes down to how database query optimization and predicate pushdown in particular. In this case, albums would probably have an index on albums.id column, which would optimize get_album_by_id into a single index lookup. Ideally, I would want to have an explicit function for this, something like sql::from_index("albums", "id", 3), but there is no such thing as explicit index lookup in PostgreSQL right now.
Regarding different function syntaxes:
{ ... } construct a new tuple (think object, struct, record),So:
func something() -> { ... } # constructs a new tuple
func something() -> ( ... ) # returns a value
func something() -> ... # equivalent to ( ... )


I think that ORMs work great for 90% of cases, and abismally for the rest. They are also limited by the syntax and semantics of the language they are embedded in. For example, if you refer to a non-existing column, it would take a call to database to figure that out, and a cryptic error message with non-helpful code span.


Haven’t thought about but yes - it solves a few of the same problems as ORMs. Maybe the front page does not mention it, but with Lutra, you don’t get result.getInt(). You get generated Python classes / Rust structs that reflect the Lutra types.
I’m currently looking into Concourse.
It does have steeper-than-average learning curve, but I really like that it has well-defined fundamentals (resources, jobs, tasks) and isolation with OCI containers. Before I adopt it fully, I want it to run my nix flake dev shell.
Also computer science, parsing


My guy from nsfwlemmy making sure all people, regardless of disabilities or horniness can read git memes. Respect


Nice. I knew something was in the works for Material for MkDocs and it turned out to be exactly what I wanted. Which is a binary executable that you point to a repo and it gives you a static website.


Meanwhile, I’m using Pixel 3a for my main phone (for quite a few years now) and consider it a relatively up-to-date phone.
Ok, good point, most languages I know use “C-style sequential function-calling” paradigm. Is there a specific idea that you have for a language that would better utilize our CPUs?
Notation that treats asynchronous message-passing as fundamental rather than exceptional.
I’m pretty sure there exists at least one research paper about notation for the actor pattern.
You explain pretty well why you don’t think C is a good fit for hardware we have today, but that warrants a proposal for something better. Because I for sure don’t want to debug programs where everything is happening in parallel (as it does in pong).
Pigs is a blanket? Why, americans, why do you invent such strange names for normal food, such as “sausage in bread”[1]?
I wouldn’t say so - it’s not streaming app views from the server, it provides containers for apps, segmented into “grains”. So each open document gets it’s own container. Other than that, it’s just normal web apps (like immich or seafile).
Woah, they take the blame and apologize. This is not often seen and commands respect.