Readit News logoReadit News
branko_d commented on Go is still not good   blog.habets.se/2025/07/Go... · Posted by u/ustad
toast0 · 2 days ago
The problem with string length is there's probably at least four concepts that could conceivably be called length, and few people are happy when none of them are len.

Of the top of my head, in order of likely difficulty to calculate: byte length, number of code points, number of grapheme/characters, height/width to display.

Maybe it would be best for Str not to have len at all. It could have bytes, code_points, graphemes. And every use would be precise.

branko_d · 2 days ago
You could also have the number of code UNITS, which is the route C# took.
branko_d commented on Vibe Coding Is the Worst Idea of 2025 [video]   youtube.com/watch?v=1A6uP... · Posted by u/tomwphillips
bitpush · 4 days ago
Here's how Innovators Dilemma plays out.

Step 1: Some upstarts create a new way of doing something. It’s clunky and unrefined.

Step 2: "Experts" and senior folks in the field dismiss it as a "toy." It doesn't follow their established rules or best practices and seems amateurish. They wouldn't recommend it to anyone serious.

Step 3: The "toy" gets adopted by a small group of outsiders or newcomers who aren't burdened by the "right way" of doing things. They play with it, improve it, and find new applications for it.

Step 4: The "toy" becomes so effective and widespread that it becomes the new standard. The original experts are left looking out of touch, their deep knowledge now irrelevant to the new way of doing things.

We're at step 2, bordering on 3.

* Executives at Nokia and BlackBerry saw the first iPhone, with its lack of a physical keyboard, as an impractical toy for media consumption, not a serious work device.

* Professional photographers viewed the first low-resolution digital cameras as flimsy gadgets, only for them to completely decimate the film industry.

branko_d · 4 days ago
The problem is not that the experts have dismissed vibe coding without even trying it.

The problem is that the experts have tried it and found that vibe coding doesn't actually work at scale that they need.

Will it ever? Perhaps, but I'd argue a near-AGI level of intelligence would need to be achieved first. When that happens, we have bigger problems (and/or opportunities?) than a few programmers losing their jobs.

branko_d commented on Good system design   seangoedecke.com/good-sys... · Posted by u/dondraper36
zbentley · 8 days ago
I’m generally pro SQL-as-interface, but this is just wrong.

Not only are there all sorts of bizarre constraints imposed by databases on migration behavior that application code can’t express (for example, how can I implement a transaction-plus-double-write pattern to migrate to use a new table because the locks taken to add an index to the old table require unacceptably long downtime? There are probably some SQL engines out there that can do this with views, but most people solve it on the client side for good reason), but there are plenty of changes that you just plain can’t do without a uniform service layer in front of your database. Note that “uniform service layer” doesn’t necessarily mean “networked service layer”, this can be in-process if you can prevent people from bypassing your querying functions and going directly to the DB.

branko_d · 8 days ago
> Note that “uniform service layer” doesn’t necessarily mean “networked service layer”, this can be in-process if you can prevent people from bypassing your querying functions and going directly to the DB.

You can take it one step further and implement the “uniform service layer” in the database itself - using stored procedures and views.

This has downsides, like strong coupling with the specific DBMS, and difficulty of development in a comparatively primitive SQL dialect, but protects the database from “naughty” clients and can have tremendous performance advantages in some cases.

branko_d commented on Good system design   seangoedecke.com/good-sys... · Posted by u/dondraper36
branko_d · 8 days ago
> Indexes work like nested dictionaries

If the author meant “dictionary” in a sense of a hash map, that’s not quite correct. In relational databases, indexes are usually B-trees, which are ordered, unlike hash maps. A B-tree can help with range-searches, ORDER BY and even merge joins, not just equality-searches.

branko_d commented on 1910: The year the modern world lost its mind   derekthompson.org/p/1910-... · Posted by u/purgator
zkmon · 13 days ago
Let's compare the progress made by the modern world against the life of the tribes on the remote untouched islands.

Unfortunately the stories of success of the modern world were written by the modern world. So what we call as success or progress is only valid in modern world. There is no language or terms that can describe success and agreed upon across these two worlds.

For example, you may be able to wipe out that tribal population within minutes. But that may not mean success or progress, in terms of adaptation to the surroundings. Dinosaurs also ruled the land with their might. But adaptation is something different from being mighty. The context can get much more mightier against you.

Most of scientific and industrial advances were made by people who have no survival struggles and who were greedy for money or reputation. A lot of it was not needed for human adaptation and evolution.

branko_d · 13 days ago
On the other hand, dinosaurs may have survived if they had a space program! :)
branko_d commented on PHP compile time generics: yay or nay?   thephp.foundation/blog/20... · Posted by u/moebrowne
gloryjulio · 14 days ago
Example, Java is using erased generics. Once the code is compiled, the generics information is no longer in the bytecode. List<String> becomes List<>. This is called type erasure.

C# is using reified generics where this information is preserved. List<String> is still List<String> after compilation

branko_d · 14 days ago
And as a consequence, C# can pack the value types directly in the generic data structure, instead of holding references to heap-allocated objects.

This is very important both for cache locality and for minimizing garbage collector pressure.

branko_d commented on US to rewrite its past national climate reports   france24.com/en/live-news... · Posted by u/mdhb
branko_d · 16 days ago
Don't Look Up!
branko_d commented on Writing a storage engine for Postgres: An in-memory table access method (2023)   notes.eatonphil.com/2023-... · Posted by u/ibobev
rubenvanwyk · 17 days ago
I’ve always wondered why OLTP databases didn’t go the route of tiered storage systems: save to memory, cache to NVME, save permanently to object storage, with different levels of guarantees for each level.
branko_d · 16 days ago
Probably because of the "D" in ACID transactions, so the transaction log cannot be meaningfully write-cached.

OTOH, writing to tables/indexes is already done "out of order" and aggressively cached in the buffer pool, and flushed to permanent storage only occasionally (and relatively rarely, e.g. SQL Server does it approximately once a minute).

branko_d commented on The time is right for a DOM templating API   justinfagnani.com/2025/06... · Posted by u/mdhb
wavemode · 2 months ago
I would argue that the proliferation of frontend frameworks is evidence is that we -don't- know what the optimal abstraction is for building frontend applications. We're all still trying to figure that out.

Just look at what happened with Web Components. It didn't take over or become the foundation of everyone's software. It just became yet another competitor [0].

I wish the standards committees would focus their efforts on improving JavaScript the language. That has a much greater and more lasting return on investment.

[0]: https://xkcd.com/927/

branko_d · 2 months ago
I would love to see Web platform become more similar to JVM or .NET CLR - just a bytecode JIT with access to rich layout/rendering engine. Then build whatever you want on top of it.
branko_d commented on Wrong ways to use the databases, when the pendulum swung too far   luu.io/posts/2025-databas... · Posted by u/luuio
luuio · 2 months ago
1. Beyond just querying, the stored proc spent a lot of time processing data. As in, looping through cursors, making business logic decisions, calculating things, etc.

2. Having the business logic (not just loading the data) inside the stored procs meant that a change in business logic that would normally only need to update application code, now invalidates the stored procedure's cached execution plan.

branko_d · 2 months ago
> looping through cursors, making business logic decisions, calculating things, etc.

Interesting. Can you share more details about the "non-data" processing that was done? Were they doing heavy mathematical calculations and such?

> change in business logic that would normally only need to update application code, now invalidates the stored procedure's cached execution plan

As for plan cache invalidation - the most extreme case I saw was on the order of 5-10s. Basically, it depends on the size of that one stored procedure - not on all other stored procedures that may call it or be called by it. What was the actual time that they got?

u/branko_d

KarmaCake day1782May 2, 2017View Original