Second this. Their BDFL's personality is not suited for the job IMHO.
Example: Nim's hash table data structures (Python dict, Go map) are called tables. There are several variants of these, including OrderedTable. Deleting a key from an OrderedTable had O(n) performance because Nim built an entirely new OrderedTable, filtering out the key to be deleted. There were a couple of reasons for this:
- the internal list that preserved element order was only forward threaded, making an O(1) delete impossible
- Nim tables allowed the same key to be inserted multiple times, each with different values. I thought this was a bit crazy compared to other languages.
I tried to changed OrderedTable to use a doubly-linked list to allow O(1) deletes, and to get the multiple key feature removed.
What I didn't realize is that Araq, the BDFL, used ordered tables a lot in the Nim compiler, used the multiple value feature, and didn't want to add the memory overhead of a 2nd list to OrderedTable. His main reason was "deletes don't happen too often". At that point it became impossible to convince him that for a hash table to have O(n) delete performance was ridiculous and would be unexpected for anyone using OrderedTable. I gave up, left, and haven't been back.
Andreas is simultaneously brilliant and myopic to needs outside of his own (compiler dev).
It's amazing how many fights he gets into with Status-IM engineers who are the biggest financial supporters of the project and the only noteworthy company that heavily uses Nim.
Has OrderedTable been ported to Nimony? Does it still have this bug?
OrderedTable is now a synonym for Table, ie, both are ordered. To delete a key, the key is looked up to get an index position x in a Seq, the Seq entries after x are shifted left, the Seq is trimmed of the last element, and then the entire table is rehashed because shifting the Seq invalidates the previous hash codes. The performance is better than Nim OrderedTables because at least an entirely new table isn't created, and it probably works fine for small tables, but it still isn't O(1). The performance would be similar to removing an item from a single-threaded sorted list: most painful to remove the 1st element, least painful to remove the last element, but then you still have to rehash the entire table.
I just asked Google AI how LLMs translate COBOL code containing GOTOs into Java, a language that doesn't have GOTO. It gave several examples, one of them being this:
COBOL code:
PROCESS-DATA.
ADD 1 TO COUNTER.
DISPLAY COUNTER.
IF COUNTER < 10 GO TO PROCESS-DATA.
Java translation:
while (counter < 10) {
counter++;
System.out.println(counter);
}
If "counter" is 10 on entry, the COBOL code prints 11 while the Java code prints nothing. So not only keeping old bugs, but apparently introducing new ones too!
I wrote COBOL code for a few years at a job when I was a teenager. What makes legacy COBOL code difficult IMO is it can sometimes be very hard to maintain a mental execution state when examining the code, for several reasons:
1. all variables are global, aka, WORKING-STORAGE. You list all the variables used in the program and they are accessible to the entire program.
2. programs are divided into paragraphs. Control normally flows sequentially top to bottom through paragraphs, one executing after another. Except that the PERFORM statement can drastically alter this normal flow control, and you can't tell by looking at a paragraph how it will be executed. To do that, you have to look at all PERFORM statements that mention this paragraph or any paragraph physically before it, because in COBOL you can say PERFORM PARA1 THROUGH PARA27. If PARA13 is physically between PARA1 and PARA27, it's potentially going to get executed.
3. In true legacy COBOL, before structured COBOL was a thing (circa 1985), the main control flow statement in addition to PERFORM was GOTO. Lots of flag setting, and lots of GOTOs. So in the previous example, you can't tell if PARA13 is going to get executed because any prior statement might be a GOTO PARA14, skipping execution of PARA13. But even worse, you are still under the influence of the PERFORM THRU, so after PARA27 is executed, control returns to the statement following the PERFORM THRU, wherever that was. But if you GOTO PARA27, without being under a PERFORM THRU, then PARA27 is executed followed by the next sequential paragraph. Trying to figure this out statically by looking at the program can be very difficult, especially considering PERFORMs that are nested at runtime but may not be anywhere near each other in a code listing.
Isn't this exactly what every mobile app does when the db is on a phone, and every app where the db is kept on the local machine? I do it with HashBackup and have done 35 db migrations over 17 years without much trouble. There have been 1 or 2 migrations that had a bug, but you fix that by doing another migration.
SQLite has transactional DDL: you can start a transaction, do a bunch of create tables, copy data from old tables into the new tables. If an error occurs during this and a rollback occurs, everything will be just like it was before the transaction started. If a commit occurs, the migration succeeds and everyone sees the new schema on their next transaction.
In rollback mode, only the migration thread can be active because it's a write transaction, but I'm guessing in WAL mode, readers can continue to read during the migration, as with any other write transaction. I don't use WAL mode much because for my application (HashBackup), I don't need db concurrency.
If you can accept downtime and you really don't need db concurrency, then that's great and SQLite is probably a good fit for you. There are many applications for which that isn't the case.
My sister uses Windows 10 in her one-person accounting business. The performance of everything she does is fine as is. The main thing she needs is stability, and the last thing she wants is any kind of upheaval of her computing environment, the processes she uses every day, the software she uses every day, etc. She has all kinds of workarounds for flaky software she has to use every day, and figuring out new workarounds for new flaky software is not something she wants at all.
Microsoft would do much better IMO if it focused on reducing problems and increasing their ability to support users rather than adding features and constantly changing the way people have to interact with their computer. A lot of people simply don't care about that crap.
Seems to me the purpose of all these releases, credits, pricing changes, harness changes, unpredictable token usages for the same task, etc. is to keep customers completely befuddled so that it's impossible to compare AI products. It's like hiring a consultant who sends invoices every month that aren't related to hours worked or project progress, but are whatever the consultant feels like billing, and you're expected to keep quiet and and keep paying.
I compare online marketplaces to ISPs: we don't expect ISPs to filter the traffic going over their network to make sure it complies with all laws, because that would be impossible. Having actually run a marketplace in a previous life, it's a similar situation. How is a marketplace with millions of products supposed to vet each individual product? About the only thing a marketplace can do is provide some kind of customer feedback mechanism, make sure customers can get refunds easily and quickly, and kick off merchants and buyers that have too many complaints (though they will probably just register again under a different name).
To limit inequality, cap the CEO's total compensation to 100x (or whatever) the lowest-paid workers' compensation.
Google says: "at the 100 publicly traded U.S. companies with the lowest median worker pay, this ratio (CEO to worker pay) is much higher, averaging 632 to 1.
Also: "From 1978 to 2024, inflation-adjusted CEO pay grew over 1,094%, while typical worker compensation increased by only 26%"
Consistent hashing helps solve this. You don't divide into shards based on the id, but on the consistent hash of the id. Then when you have to add shards, it's easier to distribute data to the new shards. If you have 3 shards and expand to 4, only 1/4th of the data from each shard gets moved to the new shard.
Second this. Their BDFL's personality is not suited for the job IMHO.
Example: Nim's hash table data structures (Python dict, Go map) are called tables. There are several variants of these, including OrderedTable. Deleting a key from an OrderedTable had O(n) performance because Nim built an entirely new OrderedTable, filtering out the key to be deleted. There were a couple of reasons for this:
- the internal list that preserved element order was only forward threaded, making an O(1) delete impossible
- Nim tables allowed the same key to be inserted multiple times, each with different values. I thought this was a bit crazy compared to other languages.
I tried to changed OrderedTable to use a doubly-linked list to allow O(1) deletes, and to get the multiple key feature removed.
What I didn't realize is that Araq, the BDFL, used ordered tables a lot in the Nim compiler, used the multiple value feature, and didn't want to add the memory overhead of a 2nd list to OrderedTable. His main reason was "deletes don't happen too often". At that point it became impossible to convince him that for a hash table to have O(n) delete performance was ridiculous and would be unexpected for anyone using OrderedTable. I gave up, left, and haven't been back.