131–140 of 186 posts
D will get caught into that edition trap too
All it does is fragment a ecosystem, bloat a source tree and makes maintenance a painful task only to please people who think maintainers should cater to their poor tech hygiene
Earlier quoted context omitted.
I think CMake actually has the best default evolution system out there (a bit surprising give how awful the actual language is). Each "policy" they change can be manually set to old or new, and there's a global config to set them all at once based on the version of CMake. https://cmake.org/cmake/help/latest/command/cmake_minimum_re...
I scarcely go a week without encountering issues caused by their huge CMake 4 backward compatibility break. I think CMake has one of the worst solutions out there.
Earlier quoted context omitted.
It’s curious how many people don’t understand what SQLite is and its intended feature set. They get huffy that it’s not a full client server model with multimaster clustering across 8 data centers on 12 continents plus New Zealand with realtime synchronous replication. It’s a product that allows you to do sql like things without a database server. If you need to have database server behavior, you’re using the wrong p…
Well, it goes both ways. You'll see articles saying essentially "you don't need Postgres or any other fancy database, SQlite is enough" while ignoring the fact that some use-cases warrant a more conventional DB server. Different tools for different situations!
- no db user configuration - no installing multiple tenants in the same db - no phpmyadmin (ftp db files) - no remote database hacks - no backup tools
Earlier quoted context omitted.
I scarcely go a week without encountering issues caused by their huge CMake 4 backward compatibility break. I think CMake has one of the worst solutions out there.
Hasn't been an issue at all for me, but in any case that's a separate issue. They removed compatibility with CMake earlier than 3.5, which is 10 years old at this point. Support length is orthogonal to default behaviour evolution systems.
Which makes a lot of sense for those projects! They can be built with CMake 3.2 because they don't need anything introduced in a newer version, so why not declare 3.2 to be the earliest supported version? It's not their fault that CMake interprets "minimum supported version" weirdly?
Who are these tourists? D will get caught into that edition trap too All it does is fragment a ecosystem, bloat a source tree and makes maintenance a painful task only to please people who think maintainers should cater to their poor tech hygiene
The only maintainers it causes a burden for are the compiler developers (and tech debt within the compiler). But this is pretty much unavoidable if the language is to evolve while remaining backwards compatible -- e.g. it's not like the c++ compiler has a lower rate of tech debt accrual.
> I don't think I need to explain why it's a bad idea for a database to be so careless about data validation. Well, loose typing can be extremely useful, and having a type of "ANY" would not replace it. I have built recently an accounting reconciliation system to find discrepancies in data coming from a large variety of sources: some from proper database engines (MySQL MariaDB), but most from proprietary systems that…
Earlier quoted context omitted.
> It's reasonable to suggest that the alternative settings for each of these suggestions is probably the wrong default for 2026. That's the key concept here. When tightening up the defaults, an "edition" mechanism is a good solution. Now we need this for C/C++, which have much legacy stuff which ought to go away for new code. This is more feasible than it used to be, because "Convert this Edition 4 code to Edition 5"…
> Now we need this for C/C++ P1881 Epochs proposed to WG21 (the C++ standards committee) in 2019 by Vittorio Romeo The committee found plenty of problems with this, and made it clear that if Vittorio did all the hard work to resolve those problems they would find more, P1881 was abandoned. There was a Reddit thread https://www.reddit.com/r/cpp/comments/1tja9zr/c_profiles_a_c... which suggested that the "Profiles" ide…
Earlier quoted context omitted.
it would be sorta enough to bundle the wasm binary
That's the idea behind the future file format: https://github.com/future-file-format/F3 Bundle a wasm decoder as a fallback when native decoder isn't available.
For context, I have a game I'm working on where I build stand-alone builds with all dependencies bundled. The app bundle is 14MB right now. If I added sqlite, it would grow to 15MB. If I added sqlite-but-with-wasm, it'd more than quadruple in size to 60MB.
The first two points are deliberate SQLite design decisions so they're unlikely to change.
I think the OP wants duckdb. The first two points are deliberate SQLite design decisions so they're unlikely to change.