SPBS

It’s true, the title should have said “Python-like”

I'm firmly in the Go camp too but this just reads as unnecessary glazing

> Go solves this through unyielding consistency.

What? Why is the word "unyielding" used here? What was the point of generating this AI article on the google blog post?

> In a decade or so Go the awkward things about Go will have multiplied significantly and it'll have many of the same problems Python currently has.

The stdlib packages are far better designed in Go than in Python. “The standard library is where packages go to die” is literally not a thing in Go, in fact quite the opposite.

> Early in the development process, when testing the incomplete application, I remembered that Subversion (the version control system after CVS, before Git) had a –dry-run option.

> I remembered how helpful that was, so I decided to add it to my command as well.

He mentions the reason he added it, and it's a compelling enough story to be true.

> 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.

How is C# just not straight-up faster than Java then? Instead of both language punching around the same weight on benchmarks? Doesn't cache locality like, have a huge effect on performance?

the page is really laggy on Edge, kills any interest in wanting to explore more (strangely, it's much snappier on Chrome)

> Amazon / Google / Microsoft offer managed versions of the database and make bank on it. Easily millions in revenue. Original creator / company doesn't get anything, and the hyperscaler isn't obliged to pay.

This isn't what is happening. A company called Garantia Data renamed themselves to Redis Labs and acquired the Redis trademark. They're not the original company, and they used a naming trick to present as if they are official (they are now, and nothing they did was illegal).

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

https://www.gomomento.com/blog/rip-redis-how-garantia-data-p...

No. Scrollbars are besides the content, AI-generated content is the content. An article absolutely deserves to be called out if the author has the gall to AI-generate it and then share it on HN (or elsewhere).

I always do this. There's usually one field that you can put at the start that never changes. But the field at the end will keep changing as you add more fields to the SELECT list.

   SELECT
      a
      ,b
      ,c
      ,d
   FROM
      Customers
   ORDER BY
      b
      ,c DESC

Headers are missing IDs for URL fragments to jump to e.g. https://strongly-typed-thoughts.net/blog/zig-2025#error-hand... doesn't work

> appeals to HN and nobody else

Your argument is that writers do this because of "economics", but to the detriment of readers. I don't see how this extends only to HN readers. It applies to all readers in general.

This is awful. The alternative isn't "no name", it's a full and unambiguous name (even if it's a mouthful). If you can't come up with a good short name, stick with the long one.

> Spaces should be used to line up the code so that the root keywords all end on the same character boundary.

  SELECT file_hash
    FROM file_system
   WHERE file_name = '.vimrc';

This style is annoying and I wish it gained less traction. It looks neat but it puts so much burden on the query writer, especially when you modify the query and all of the sudden you need to indent multiple lines just to make them all align. You know what's neat and still easy to modify/diff? Just indent a new line for each row.

    SELECT
        file_hash
    FROM
        file_system
    WHERE
        file_name = '.vimrc';

Built-in password managers don’t work across apps. They only work for the browsers they’re built into.

Sometimes Software is Done, or Why Hugo Why (2024)

https://commaok.xyz/post/on_hugo/

> When I first used Hugo I loved it. It was fast. It was simple. It just worked, as much as any software does, and it solved a real problem.

> It was done.

> But people kept working on it.

> I’m sure that it has been improved in countless ways. But along the way it has gotten bigger and more complicated, and has broken backwards compatibility repeatedly.

This is null trivia, a lot of it is not worth memorizing because it's not important. Personally I was surprised that NULL AND FALSE does not result in NULL, but who cares?

Too much layering. Code like this makes a huge song and dance around what is ultimately issuing an SQL query to the database and returning the results. The solution must always scale scale scale, never mind that simple problems should have simple solutions. A simple solution can always be refactored into a more complex solution, but not the other way round. It's always a safe bet to start with a simple solution.

entertaining and very true. I will be sending this article to people next time I see them waffling on something.

I almost never used `dir` because `ls` is supported by PowerShell. Is there a reason you have to use CMD?

I think anything other than deferring Close() and then calling Close() again explicitly is overengineering. Like anything that requires creating a cleanup function, capturing a named return value, requires contorting in unnatural ways to handle a very common scenario. Just... defer Close() the soonest you can (after checking for errors), then call Close() again at the end. Most sane providers of Close() should handle being called multiple times (I know os.File does, as well as sql.Tx ).

Wow, that's awful. So they abuse "forgot your password" as a login method, with the added obstacle of having to come up with a random password every time. And they don't see any problem with it. My hunch is that all these people are very non-technical users.

but if he was a scammer, "Adam" didn't have to follow up with a vitriol-filled email chain after abruptly hanging up. This felt personal, he genuinely felt wronged because the small startup calling him back for an interview was not begging to get him on because he was the "best Node/React developer in San Francisco by far" just from looking at his GitHub profile alone.

> KISS to the rescue.

Ha. KISS would be sticking to left joins and profiling their performance (with the appropriate indexes added) and finding alternative solutions only when it’s proven to be a problem, instead of… declaring left joins to be slow and immediately jumping the gun

> But it certainly is not something you'd want for writing the documentation for an enterprise-grade product.

MDN documentation is written in markdown. I’ve always felt this was a resounding endorsement of markdown over other more “powerful” markup languages because if they can do it, why can’t you? (not you in particular, but anyone who thinks markdown is inadequate for docs)

https://developer.mozilla.org/en-US/docs/MDN/Writing_guideli...

Thanks, a lot of these Tech Influencers on Twitter really like to post screenshots without giving source to the original link (and shamelessly promote their stuff once it goes viral)

Hard disagree with the premise. It's disingenuous to pretend there isn't a difference between knowing how to resolve an interpersonal conflict vs knowing the calculations needed to build a bridge. Yes, the skill ceilings may be high, but the skill floor is clearly different.

I'm not downplaying soft skills, by the way. Soft skills are what get you successful in life. And the disdain some people have for soft skills vs hard skills is uncalled for, but that's a separate issue. Technical skills clearly mean something technical.

> meanwhile, a lot of tooling nowadays is written in Go, and I have no idea why

What? Go is used because distributing a static binary without any dependencies is way better than asking each and every user to download an interpreter + libraries.

> You think your surrogate key will save you? It will not. The world has an external reality that needs to be reflected in your database.

Yes, it will. It is precisely because of a messy external reality that you need an unchanging internal ID that is unaffected by changes to the external ID. If the software designer in the article had followed your advice, changing the chassis number would have likely resulted in broken car ownership records.

Whoever is reading this in the future, please don't follow the parent comment's advice. Use surrogate/synthetic keys for your primary key.

I don't understand what you mean by easier way, because it's always going to be a script. Unless you mean some low code/no cool tool that was already tailor made to do this.

If you're worried about data not fitting in memory, then stream the file. It seems like the Java API has support for this, surely other languages do too.

No, I am adamant that "sequel" is worse than "ess que ell". Most people who learned SQL on their own already call it "ess que ell" (a lot of my colleagues at work), because they never had a greybeard over their shoulder saying it be called "sequel". There's zero benefit in insisting it be called "sequel" other than to introduce an additional bump for people learning it all over the world. Reject sequel, join SQL.

Also, anecdotally it seems like the "sequel" preference is relegated to the old-timer Oracle and SQL Server crowd, whereas the newer Postgres/MySQL/SQLite crowd prefer to call it "ess que ell" (simply because it's the obvious way to say it).