sephware

That sounds similar to Wirth’s Law. In general the more efficient a computer’s hardware is, the more bloated its software will be, so the slower the whole system will run.

Here's a comparison between Molten and Hug by the author of the former: https://old.reddit.com/r/Python/comments/8ta3ve/molten_a_mod...

> Go is also flexible in that it does not enforce a particular style of programming

That’s actually kind of a main theme of Go, that it’s very opinionated about what the right way to program is, and doesn’t do you any favors if you try to use it to do things in a way it doesn’t think aligns with that.

The title says NoSQL and the first paragraph on the page confirms that it's more than just a KV store:

> UnQLite is a in-process software library which implements a self-contained, serverless, zero-configuration, transactional NoSQL database engine. UnQLite is a document store database similar to MongoDB, Redis, CouchDB etc. as well a standard Key/Value store similar to BerkeleyDB, LevelDB, etc.

That one seems straight forward: when you want SQL use SQLite, when you want NoSQL use UnQLite

Also, there are many classes of errors that Rust doesn't help solve, but which people seem to get the impression that it does aim to solve, which can be confusing and counterproductive when choosing a language because of the classes of errors it aims to solve (often a big motivator in both designing and choosing a language; see Swift and Go).

Thanks for that. So far Zig sounds amazing. They should have something like this on their home page.

Can anyone with more experience/understanding of Zig give an elevator pitch about why and when I would use Zig? I love the concept of a low level language that's not C, but the home page doesn't paint a clear picture to me about what its strengths are and in what situations it really shines, and what trade-offs it makes to get there.

> Reading values from Workers KV is designed to have the same reliability as reading static files, making it much less likely to become unavailable than a traditional database. It’s designed to have the same performance as reading a file cached within our network, close to your users, giving it the speed of serving a static file as well.

I wonder how this kind of speed is achieved with an API that has to go over the network? Even if the round trip is short such as between two AWS services, there's always at least some latency.

For years I remember their about page offering an explanation of how they scrape the web and score links, and a phrase something like “this might sound a bit recursive; that’s because it is!” But I haven’t been able to find it on archive.org or this site.

The first two situations where he recommends avoiding lambda I would agree with. But when he assigns `colors_by_length`, that's a perfectly valid usage of lambda. It's actually an ideal example of why it exists. His `length_and_alphabetical` is not an improvement. The tuple unpacking is something that destructuring in lambda syntax would improve, as it did with JavaScript. In ES6 it would be:

    const points = [[[1, 2], 'red'], [[3, 4], 'green']]
    const points_by_color = points
      .sort(([point, color]) => color)

I know it's kind of futile to argue against a point using what-ifs, but personally I wish Python embraced this style of functional programming a little bit more and adapted its syntax to it, rather than coming across articles where people recommend against this style just because the language isn't (currently) as suitable to it.

Nim is fantastic, I especially like that it takes a pragmatic approach to all its features, so that it doesn't get bogged down in theory but lets you get productive with it right away. One example is that even though it says it's a systems (and application) language, it has GC (ref counting + cycle detection), which means you don't have to worry about memory management and can focus on the core of your application. Honestly I think Nim is comparable to Go, so if you're thinking of adopting Go, look into Nim, you might like what you find.

One thing I think CSS frameworks got wrong is mixing layout with style. At the time, maybe it was justified due to lack of layout options. But today, especially with grid, but even flexbox, layout can entirely be done by the framework's consumer, and should probably not be done by the framework itself, which should focus probably mostly on style. Unless of course it's a layout framework, but grid is so flexible and easy to work with that you probably don't need a layout framework. I'll just leave this here https://learncssgrid.com/