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:

• Some cases would produce very verbose Lutra code because they have special-case syntax in SQL, which makes them terse.
• Lutra does not cover DDL (CREATE, ALTER, DROP, ADMINISTER). That’s because Lutra is conceptually a “run-time” language for dealing with data and not schema modifications. Because of this, Lutra cannot be used for migrations.
• Lutra is still in development, so you are likely to find cases that are not yet expressible. If you do, please report them, so they can be implemented. But I don’t believe that there are cases that would conceptually clash with Lutra language design, like there are with most ORMs.

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:

• curly braces { ... } construct a new tuple (think object, struct, record),
• parenthesis are used for precedence. They are not strictly needed for function bodies, but they do give a better visual guide to multi-line definitions, especially when using pipe operator.

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.

Also computer science, parsing

clap already supports all this: https://docs.rs/clap/latest/clap/struct.Arg.html#method.conflicts_with It’s just a great library, having you could think of and applying the same parse-don’t-validate mentality.

I hate that the pleasant news about standardization of CSV come with the let-down that is using two bytes for new lines.

deleted by creator

deleted by creator

What bugs do you mean? Anything serious i should know about?

Sure, do recommend - I’d need a basic overview, but not too deep, as I don’t have enough motivation for in-depth review of all socialist governments in the last two centuries.

To be honest, I know little about Mao and beginnings of PRC - I’m quite ignorant about how much of an “absolute leader” he was.

But I do believe that idolizing a person and concentration of power are dangerous to democracy.

And it’s interesting how much responses I got on this topic.

I would say that Hungary is currently quite authoritarian. And Serbia too. Nazi Germany and Fascist Italy were too, very much so.

Socialism dies as soon as a single person becomes its absolute leader. From there, it is just a walk toward authoritarism.

Dronies? Is this an evolution of takies? A subspicies?

That’s a good argument. The editing speed is not the limiting factor in my workflow.

Honestly, I think my interest for modal editing is a bit irrational. Maybe I don’t want to be a normie, using the default keybindings :D

Haha. But really what does -R mean?

Or some posts have a bunch of ,…, at the end. What’s that?