bvrmn

Even 10x speedup would be amazing. Just imagine current 1min check would be performed in 6s.

TLA+ has its own quirks, you could add sugar here and there, but from semantic standpoint you couldn't do much. It's "unreadable" because requires some mental model most of developers don't have. My point: you either provide "simple" tools which could do nothing for real models or they become on same level of "unreadableness" really fast.

Sticking to an library style is a way to go. It's so much friction to use python library wrappers which try to hammer original style into a snake_case.

It's literally stated in the PEP: https://peps.python.org/pep-0681/

Also: https://github.com/python/mypy/blob/501a07b45af8e44eda665e53...

Also did you know mypy ignores typing of class decorators? You simply can't return a different type other than type[thisclass].

It's not mypy issue. Comparing to TS python typehints (spec wise) are a joke. It's started as bolted on adhoc solution and evolved quite chaotically. For example [1]. TS doesn't require a special decorator (sic!) to make your custom classes to be picked up by type checkers.

Or how make a wrapper function with args and kwargs to pass through?

[1]: https://docs.python.org/3/library/typing.html#typing.datacla...

450W is ~£100 monthly. It's a luxury budget to host hobby stuff in a cloud.

My wording is bad, I agree. Original thought was: complicated edit makes TPSV adoption as nearly impossible.

I think spec tries and fails to translate code implementation into human language. In code cell separator is `\t|`.

1. It's quite easy to miss a tab and use only `|`.

2. Generated TPSV would look like an unreadable hard to edit mess. I doubt any tool would calculate max column length to adjust tab count for all cells. It basically kills any streaming.

Strict YAML has only strings, lists and maps. TBH it has much more nicer syntax as well.

According to spec it's nearly impossible to correctly edit files in this format by hand.

> No hidden control-flows

It's so much fun to `return err` through every layer. Explicit no-op attached to every call, yeah!

> No unexpected uncaught exception logs blowing up your terminal (aside from actual program crashes via panics)

A great opportunity to search a code base for logging messages and reconstruct traces by hand. A real true craft!

> full-control of errors in your code as values you can handle, return, and do anything you want with

Yes, it's a real engineering marvel. Exceptions are so bad at this, you could only catch it and, wait...

> Rust, for example, has a good compromise of using option types and pattern matching to find error conditions, leveraging some nice syntactic sugar to achieve similar results.

Thank you for mentioning Rust, I guess. It's very saddle not to include `try` on the table.

Yep. I prefer Vue myself — no need to stay on toe tips full time. It's really a question of available ecosystem and quite phenomenal React's backward compatibility which ties very agile in other circumstances FE devs to the framework.

It's React thing. In maintenance context it's always better to not extract component instantiation. They could start to use hooks or they could be wrapped in conditions in a parent component and it would lead to severe quite hard to find issues.

This approach is a classic footgun for beginners in the context of "hook rules". In general it's quite fragile.

> That is the code.

Good code consists of easy to use abstractions. In general Chris's blog is dedicated to poking bad abstractions and giving good examples. `substring` is objectively bad.

You (and other commentators) literally arguing that keeping staff in the head or making some documentation or notes or forcing yourself or others check low level implementation details are better than making one trivial fix and forget about it. I find it really amusing.

> It is called in one (1) place in a small program.

> This isn't some 100k line long program

It could use `str*` functions without any issues then. Nul-terminated strings are perfectly safe with assumptions to follow.

Anecdote: I fixed 3 reported segfaults and another 2 after fuzz-testing in a small 500 line lib. Original author had the same cowboy mindset about keeping all stuff in his head. It's always last words before getting into CVE database.

It would reduce number of assumptions, especially ones laying only in your head. Generally it's a good thing, isn't it? Literally large portion of C code bugs is due to broken assumptions. WTF man?

For this particular case it's trivial to fix substring function and extend possible inputs. It seems your proposition: "do nothing because it's futile". It's simply wrong.

> Still, this function is called only once, and in that call, its i argument is always <= length, so it's perfectly fine (it's only UB if you actually pass it a bad argument).

This very mindset is a source of bugs and vulnerabilities. The author has high marks from me on safety and "make it hard to use wrong" and it's quite surprising to see such code.

> Str substring(Str s, ptrdiff_t i)

The function has quite questionable implementation. It fails miserably for strings with length < i.

Returning static "hello world" response for slowest python framework is easily not bigger than 1ms (for fast frameworks it's 0.1ms or lower). Good luck to make the rest of your app to make something comparably fast if db or network is involved.

Actual bottleneck in examples is sqlalchemy, like 10x overhead easily. I find it quite funny. There is no real difference in web frameworks for real apps in terms of overhead.

> The elections aren't known to be broken yet

Sweet summer child. Let me unfold a very precise prediction:

* By the end of 2nd-3rd year. Trump/congress/republican party would propose an amendment that president could rule two consecutive terms. It would be accepted.

* Trump would be elected to the next term.

* By the end of 6th-7th year there would be proposal to extend presidency to three terms.

* Rinse and repeat.

If you think it's unreal I have very bad news for you: how often it happens in real world.

> the most powerful person in the country can do literally whatever they want with little to no pushback

"President is the main person end has exceptional power". That's the mental model for most people. There is no any internal conflict with law violation and any space for reflection what's wrong with it.

Bless compilers able to catch wrong format specifiers.

Amazing project!

> I built this mainly around the habit of budget tracking at the end of the day.

I've built 3 personal financial trackers. 2 CLI based and last a web-based to be able to serve it in termux as a local android app.

Anecdote: the only thing which make it usable in the end is a joint account (most transactions are happened there) which reduced monthly transaction count to low acceptable level and did not become a chore without fancy importing from bank statements. Joint account allows to record only transfers and not individual expenses. It easily could be a separate account for small expenses, it has a low value to know which kind of grocery takes most of money.

I clearly don't understand something about implications. Could you please elaborate or give a link to read about it? What is branch correctness? How could it be exploited? How does sanitization prevent it?

sqlx looks like a usual builder, I don't see nothing criminal about it.

In this case it's hard to make something fancy :)

    from sqlbind import WHERE, FIELDS, join_fragments

    q = Q()  # a QueryParams factory
    fields = []
    joins = []
    filters = []

    if some_condition:
        fields.append('sub_table.field')
        joins.append('INNER JOIN sub_table ON (subid)')
        filters.append(q.sub_table.date > since)

    sql = f'''\
    SELECT {FIELDS('table.field', *fields)}
    FROM table
    {join_fragments(' ', joins)}
    {WHERE(*filters)}
    '''

Personally I prefer this explicitness to ORM for complex queries which include recursive or multiple joins to the same table.

But I agree ORM shines with simple joins especially if models include proper relationship and there is no need to specify 'ON' condition every time.