diarrhea · HackerTrans

أول أمسdiscuss

Yeah. I don't think PG could even come close. Column-oriented is fundamentally different, and pairs well with all the SIMD acceleration ClickHouse is also doing. There's just no comparison. If a Postgres rewrite came close to that, it must've sacrificed something else.

diarrhea

قبل 3 أيامdiscuss

But do the markets care about a Postgres in Rust? Probably not, or at least not right away. It is a long way towards commercial success.

> I suspect rather than hire less people we will just produce more code changes.

Why? Towards what end? Code changes are output, not outcome. It also needs to be connected to someone willing to pay you hard cash. That is the hard part, a race to the bottom, and the reason I also believe there will be downwards pressure on salaries and even employment.

diarrhea

قبل 8 أيامdiscuss

> People still learn math, despite the calculator existing. Accounts still learn accounting, despite Excel and accounting software existing.

They do, but you need far fewer or none of the original workers whose full-time job this sort of stuff was.

Raw math does not matter, but what you do with it. Similarly, you could earn a (modest) living knowing nothing but raw HTML, JavaScript and a bit of browser tech not too long ago. That is no longer possible.

Programming and software engineering will be devalued. These occupations won't disappear overnight, but you will see compensation and growth stagnate until equilibrium is reached again. Currently, supply outstrips demand, and I do think it is structural, not just hype.

I'm certainly not creative enough, but I currently do not see demand picking up sufficiently; Gen Z is bearish on social media, VR was a bust, blockchain was a bust, software has already penetrated almost all walks of live and lines of work. There is no next big thing (Internet, ...) on the horizon, to unlock the next order of magnitude of demand. There is certainly more work to do still, but it very suddenly does not require the same headcount, but something like 5%-30% less. Lots of the remaining work will be around integrating LLMs into existing software, which does not sound exciting either.

diarrhea

قبل 20 يومًاdiscuss

Yes, my point was not related to null. For all I care you can have `&T` and `Option<&T>` in your language, but allow `&T` to be null. In Rust, that would be `Option<*const T>`. Is that useful? I don't know. But it still separates the two orthogonal concepts. Go conflates them, rolling them into one, permanently removing useful expressivity.

diarrhea

قبل 20 يومًاdiscuss

No, because RateLimiter is then copied on passing it around (pass by value).

That is problematic for two reasons: it might be a large type, so copying might be expensive. Second, more likely, it might violate invariants in your domain. For a rate limiter, this might mean accidentally copying around some internal state like a mutex, which then exists n times instead of 1 time, which can represent a problem (e.g. if you want to internally limit whole-app concurrency toward Redis).

diarrhea

قبل 21 يومًاdiscuss

This is the mess a language lands on when it conflates optionality (a semantic concept) with references/pointers (purely a machine concept). In Go, the requirement "need (non-optional) a reference to an object" is simply not expressible. This is a solved problem in other languages, for example `&T` vs. `Option<&T>` in Rust.

diarrhea

قبل شهرينdiscuss

As a fan and believer of obscurity in support of security, I do not understand why

> that step didn't add any security.

It is a decision that’s part of the entire process. A branch of many in the decision tree. Other branches are deciding which characters to type for the password; ASCII characters can be as little as 1 bit apart. Deciding between left and right is also 1 bit apart.

I think it boils down to what people commonly understand to be publicly knowable information versus understood-to-be-secret information.

One example: I self-host my password manager at pw.example.com/some-secret-path/. That extra path adds as much to security as a randomly picked username in HTTP Basic Auth: arguably none. Yet, it is as impossible for attackers to enumerate and find that path as it is with passwords.

The difference is that the path leaks easier. It’s not generally understood to be a secret. Yet I argue it helps security. (Example: leaking the domain name through certificate transparency logs AND even, say, user credentials means an attack is still unsuccessful; a strictly necessary piece of the puzzle is missing).

diarrhea

قبل 3 أشهرdiscuss

Just this month Google shipped what I understand as hard limits in AI Studio/Gemini/whatever it's called this week. I had existing billing alerts (best you could do before IIUC), but set these new hard limits up immediately. Feels good!

diarrhea

قبل 3 أشهرdiscuss

https://news.ycombinator.com/item?id=47677483

diarrhea

قبل 3 أشهرdiscuss

Interesting, though I disagree on basically all points...

> No Silver Bullet

As an industry, we do not know how to measure productivity. AI coding also does not increase reliability with how things are going. Same with simplicity, it's the opposite; we're adding obscene complexity, in the name of shipping features (the latter of which is not productivity).

In some areas I can see how AI doubles "productivity" (whatever that means!), but I do not see a 10x on the horizon.

> Kernighan's Law

Still holds! AI is amazing at debugging, but the vast majority of existing code is still human-written; so it'll have an easy time doing so, as indeed AI can be "twice as smart" as those human authors (in reality it's more like "twice as persistent/patient/knowledgeable/good at tool use/...").

Debugging fully AI-generated code with the same AI will fall into the same trap, subject to this law.

(As an aside, I do wonder how things will go once we're out of "use AI to understand human-generated content", to "use AI to understand AI-generated content"; it will probably work worse)

> just ask AI to rewrite the code

This is a terrible idea, unless perhaps there is an existing, exhaustive test harness. I'm sure people will go for this option, but I am convinced it will usually be the wrong approach (as it is today).

> Dijkstra on the foolishness of programming in natural language

So why are we not seeing repos of just natural language? Just raw prompt Markdown files? To generate computer code on-the-fly, perhaps even in any programming language we desire? And for the sake of it, assume LLMs could regenerate everything instantly at will.

For two reasons. The prompts would either need to raise to a level of precision as to be indistinguishable from a formal specification. And indeed, because complexity does become "exponentially harder"; inaccuracies inherent to human languages would compound. We need to persist results in formal languages still. It remains the ultimate arbiter. We're now just (much) better at generating large amounts of it.

> Lehman’s Law

This reminds me of a recent article [0]. Let AI run loose without genuine effort to curtail complexity and (with current tools and models) the project will need to be thrown out before long. It is a self-defeating strategy.

I think of this as the Peter principle applied to AI: it will happily keep generating more and more output, until it's "promoted" past its competence. At which point an LLM + tooling can no longer make sense of its own prior outputs. Advancements such as longer context windows just inflate the numbers (more understanding, but also more generating, ...).

The question is, will the market care? If software today goes wrong in 3% of cases, and with wide-spread AI use it'll be, say, 7%, will people care? Or will we just keep chugging along, happy with all the new, more featureful, but more faulty software? After all, we know about the Peter principle, but it's unavoidable and we're just happy to keep on.

> Jevons Paradox

My understanding is the exact opposite. We might well see a further proliferation of information technologies, into remaining sectors which have not yet been (economically) accessible.

0: https://lalitm.com/post/building-syntaqlite-ai/

diarrhea

قبل 3 أشهرdiscuss

uv supports it, https://docs.astral.sh/uv/reference/settings/#exclude-newer

diarrhea

قبل 4 أشهرdiscuss

This take was accurate about 2 years ago, up until perhaps one year ago. Current capabilities far exceed what you are outlining, for example using Claude Opus models in a harness such as Claude Code or OpenCode.

diarrhea

قبل 4 أشهرdiscuss

I use unbound (recursive resolver), and AdGuard Home as well (just forwards to unbound). Unbound could do ad-blocking itself as well, but it's more cumbersome than in AGH. So I use two tools for the time being.

The upside is there's no single entity receiving all your queries. The downside is there's no encryption (IIRC root servers do not support it), so your ISP sees your queries (but they don't receive them).

diarrhea

قبل 4 أشهرdiscuss

I have the same question, I am confused by the premise of this article. Now you're recording everything twice?

diarrhea

قبل 4 أشهرdiscuss

Agree. I am note sure I understand the premise of the article. You're now recording encountered errors twice, which can look like

    cancel(fmt.Errorf(
        "order %s: payment failed: %w", orderID, err,
    ))
    return fmt.Errorf("order %s: payment failed: %w, orderID, err)

Not only that, isn't this a "lie"? You're cancelling the context explicitly, but that's not necessary is it? Because at the moment the above call fails, the called-into functions might not have cancelled the context. There might be cleanup running later on which will then refuse to run on this eagerly cancelled context. There is no need to cancel this eagerly.

Perhaps I'm not seeing the problem being solved, but bog-standard `return err` with "lazy" context cancellation (in a top-level `defer cancel()`), or eager (in a leaf I/O goroutine) seems to carry similar functionality. Stacking both with ~identical information seems redundant.

diarrhea

قبل 4 أشهرdiscuss

Feldera speak from lived experience when they say 100+ column tables are common in their customer base. They speak from lived experience when they say there's no correlation in their customer base.

Feldera provides a service. They did not design these schemas. Their customers did, and probably over such long time periods that those schemas cannot be referred to as designed anymore -- they just happened.

IIUC Feldera works in OLAP primarily, where I have no trouble believing these schemas are common. At my $JOB they are, because it works well for the type of data we process. Some OLAP DBs might not even support JOINs.

Feldera folks are simply reporting on their experience, and people are saying they're... wrong?

diarrhea

قبل 5 أشهرdiscuss

I have been using nixos-rebuild with target host and it has been totally fine.

The only thing I have not solved is password-protected sudo on the target host. I deploy using a dedicated user, which has passwordless sudo set up to work. Seems like a necessary evil.

diarrhea

قبل 6 أشهرdiscuss

In thermodynamics, ultimately you need to input work to remove entropy from a system (e.g. by cooling surroundings). Humans do the same for software.

I am an avid user of LLMs but I have not seen them remove entropy, not even once. They only add. It’s all on the verge of tech debt and it takes substantial human effort to keep entropy increases in check. Anyone can add 100 lines, but it takes genuine skill to do it 10 (and I don’t mean code golf).

And to truly remove entropy (cut useless tests, cut useless features, DRY up, find genuine abstractions, talk to PM to avoid building more crap, …) you still need humans. LLM built systems eventually collapse under their own chaos.

I think your analogy is quite fitting!

diarrhea

قبل 6 أشهرdiscuss

Randomly fail or (increasingly) delay a random subset of all requests.

diarrhea

قبل 6 أشهرdiscuss

Interesting attack on my person!

The things I want to get done on my computer are so much richer than moving files back and forth in a terminal all day. Simple things should be simple. Tools should enable us. Moving files is a means to an end and these commands having so many sharp edges makes me unhappy indeed.

But yes, of course I am an IDE toddler and cannot even tie my shoes without help from an LLM, thanks for reminding me.

comments