justsomeuser

How long does it take to resume a VM?

I don’t think it is that serious of an issue:

- The API is likely to be simple (JSON in and out, or something similar). Those devs already know they domain well.

- The Rust compiler enforces only valid programs, so you won’t get runtime errors for things you would in dynamic languages.

- This leaves just getting the logic right, which the developers know how to do in general, and Rust is a c-like language so it’s familiar.

How do you manage changing state overtime? Do you re-render the whole template?

Can templates be nested?

> What does this prove about SQL being inferior to other languages

My point is that I think it is inferior for general application/business logic programs. For queries that filter large datasets to small result sets, SQL is probably better as it has the built in indexes and query planner (plus ACID).

I am pointing out that the current environment (better text editors and package managers) favours general languages, so they are a better current choice (to use in combination with SQL) over just writing everything, including application logic, in SQL.

> Type systems

Sure SQL has types, but they are checked at runtime, not compile time. Also you cannot define function input and return arguments with types that are checked before you run the program.

> compilers

If you want efficient and/or portable code. They will check your code for type errors before you run them. They give you coding assistance in your editor.

> debuggers

Being able to break a program and see its state and function stack is useful. The quality of the tools for real languages are much better than SQL.

I agree that databases do concurrency better than most languages with their transactions (I mentioned I would use the db for ACID).

> text editors, package managers.

Editor support of real languages is much better than SQL.

Package managers enable code re-use.

> C FFI

Take for example Python. A huge amount of the value comes from re-using C libraries that are wrapped with a nice Python API.

You might be able to do this in SQL, but you'll have to wrap the C library yourself as there is no package manager, and no one else is doing the same thing.

I think general programming languages are better for general programs than SQL.

Specifically they have: Type systems, compilers, debuggers, text editors, package managers, C FFI etc.

But I agree that having the data and the program in the same process has benefits.

Writing programs in SQL is one way.

Another way is to move your data to your general program with SQLite.

I like using SQL for ACID, and queries as a first filter to get the data into my program where I may do further processing with the general language.

Of course. This is just a simplification that I find useful.

Software is less like traditional engineering as there are no "right" ways to do things.

I sometimes simplify social interactions by dividing them into two sets: friendly-social and engineering.

In friendly-social environments, it is all about avoiding overly negative topics. It is not lying, but just keeping the conversation track on things that are positive and interesting.

In engineering environments, logic is king. You need to be able to tell an engineer that their rocket designs will not fly and put ego's aside.

You are right, I did not realise it was the compiled code.

I thought it was the comparable hand written JS.

I think it is more to do with the so called "Object–relational impedance mismatch", which I guess is related to schema migrations.

NoSQL would still have migration issues as the types change over time, much like the table schemas. You would need to be able to read/write older objects stored, or transform them all to the newer object schema in one go.

I remember when Mongo DB first came out, it seemed the most liked feature was that you could just JSON.stringify and JSON.parse things into and out of the db.

I personally prefer SQL tables, as the act of designing the tables and their relations seems to half way solve a problem, and removes the issue of "which tree structure should this value live in, how do I copy it to both of these types?".

Under "Everything is an Expression":

        items = (() => {
          const results = [];
          for (const item of items) {
            if (item.length) {
              results.push(item.toUpperCase());
            } else {
              results.push("<empty>");
            }
          }
          return results;
        })();

Seems like they are purposely making the JS version extra long. It could be:

        items = items.map(x => x.length > 0 ? x.toUpperCase() : `<empty>`)

Edit: Just realised the code on the right is the compiled code, not the "equivalent hand written JS".

I think CSS and the domain of laying out things in 2d (and responding to state changes) with code is actually inherently complex, so which ever layout system you use is going to have a steep learning curve.

Many of the newer CSS features prevent you using JavaScript to achieve the same thing, which is better as it results in better performance and easier to understand code.

I would rather have newer standardised selectors than see the same pattern re-implemented with JS differently in every codebase.

I like the way you use a combination of <textarea> for editing and <pre> for DOM elements.

I actually have come to the same solution for a transcription web app.

I have found that <textarea> manipulation from JS is not really possible without `Document.execCommand` which is deprecated. Some edits will clear the undo history.

Do you have any notes you can share?

My notes on this:

- <dialog>.showModal() is an indirect API to `top-layer`.

- `top-layer` is kind of like a sibling to the root <html>, elements can be placed into the top-layer from any position in the existing DOM (it is like they have two positions). This allows co-locating your <dialog> next to the relevant elements in the tree.

- There is only one `top-layer` but it can have many children. Last opened === current element on top.

- Z-index has no effect in the top-layer. No need to compete for a higher z-index.

- ::backdrop is a pseudo element that you can style behind the <dialog>. It is always below the last <dialog> opened.

- Not supported in Safari <= 15.3