hyperpape

Even in older versions, if the compiler can see that there are no side-effects, it is free to remove the loop and simply return the value from the first iteration.

I'm actually pretty curious to see what this method does on versions that don't have the optimization to treat hashCodes as quasi-final.

A quick test using Java 17 shows it's not being optimized away _completely_, but it's taking...~1 ns per iteration, which is not enough to compute a hash code.

Edit: I'm being silly. It will just compute the hashcode the first time, and then repeatedly check that it's cached and return it. So the JIT doesn't have to do any _real_ work to make this skip the hash code calculation.

So most likely, the effective code is:

    computeHashCode();
    for (int i = 0; i < 10000; i++) {
        if (false) { // pretend this wouldn't have dead code elimination, and the boolean is actually checked
            computeHashCode();
        }
    }

> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node?

I'm sure you can find other projects that are going to fail, but why do you want to?

Node has lots of problems (I am basing this statement on the fact that it's a major tech project). None of them are sufficient to prevent it from being extremely widely used.

To fix those problems in a product that will be used, it is not sufficient to provide something sort of like Node but without those problems. You either have to:

1. Provide a tool that requires a major migration, but has some incredible upside. This can attract greenfield projects, and sometimes edge out the existing tool.

2. Provide a tool with minimal migration cost, and without the same problems. Maybe this tool can replace the existing one. Ideally there will be other carrots (performance, reliability, ease of use). Such a tool can get people to migrate if there are enough carrots, and the migration cost is low enough.

Deno was a classic example of messing this up. It's not #1 or #2, it has the worst of both worlds. The upside was that it did things "the right way", and the downside was that you couldn't run most code that worked on Node. This is the kind of approach that only attracts zealots and hobbyists.

I’m really stuck on a relatively minor point: why does Joe-E have to ban the finally keyword?

I think the distinction is that if you write a test that reproduces the bug, that's a binary signal and doesn't by itself tell you anything about why the bug is happening.

In contrast, if you write tests that rule out particular causes of a bug you're incrementally narrowing down the potential causes of the bug. So each test gives you information that helps you solve the bug, without directly stepping through the code.

Unfortunately, I don't think the post is a great primer on the subject.

"How dare you judge me for drinking a case of beer. I know for a fact you had two beers this evening!"

I don't have any sympathy for Elon's view, but I don't think this article really does anything to explain why it's wrong. No surprise, it appears to be an op-ed, which is not a format that usually teaches you much.

It's really indefensible to post this without linking to your research to show people what you found.

I'm completely unsure whether to respond "it was stable, he was running a release version of Fedora" or "there's no such thing as stable under Linux".

The insanity is that the Kernel, Fedora and GCC are so badly coordinated that the beta of the compiler breaks the Kernel build (this is not a beta, this is a pre-alpha in a reasonable universe...is the Kernel a critical user of GCC? Apparently not), and a major distro packages that beta version of the compiler.

To borrow a phrase from Reddit: "everybody sucks here" (even Cook, who looks the best of everyone here, seems either oblivious or defeated about how clownshoes it is that released versions of major linux distros can't build the Kernel. The solution of "don't update to release versions" is crap).

(Writing this from a Linux machine, which I will continue using, but also sort of despise).

Yeah, I think this should be seriously investigated, but that detail struck me as not making sense.

> suspending threads in your own process is kind of necessary for e.g. many GC algorithms

I think this is typically done by having the compiler/runtime insert safepoints, which cooperatively yield at specified points to allow the GC to run without mutator threads being active. Done correctly, this shouldn't be subject to the problem the original post highlighted, because it doesn't rely on the OS's ability to suspend threads when they aren't expecting it.

There are profit margins in the thread. They’re a lot lower than what you described.

Brian Goetz, chief architect of Java, once posted a "what they think I do" vs. "what I actually" do tweet. If I remember correctly, 25% - 50% of the "what I actually do" category was something like "get angry at serialization."

So I think it's safe to say "what about serialization?" is always going to be asked.

You may wish to contact compliance and inform them that they are violating legal requirements in the UK (assuming that this is, y'know...true). Without blustering or yelling (getting angry makes you look less credible), simply state the government agency that accepts complaints, and state that you will file a complaint if the matter is not resolved. If there are laws that mandate how fast Google is required to resolve the issue, it is worth mentioning them.

In general, support has the incentive of making tickets go away. Compliance has the incentive of making sure the company doesn't run afoul of regulators. Compliance is also much much more powerful at an organizational level.

Leaving aside the ethics of vulnerability research in server-side software, you're neglecting the fact that atop runs on your own machine.

So it's not like breaking into a factory. It's like noticing that your dishwasher makes the deadbolts in your house stop working (yes...a weird analogy--there are ways software isn't like physical appliances).

Surely you have the right to explore the behavior of your own house's appliances and locks, and the manufacturer does not have the right to complain.

As for server side software, I think the argument is a simple consequentialist one. The system where vulnerability researchers find vulnerabilities and report them quietly (perhaps for a bounty, perhaps not) works better than the one where we leave it up to organized crime to find and exploit those issues. It generates more secure systems, and less harm to businesses and users.

The parent asks "how is it not a file layout" not "can you guess the file layout?" given it.

I am a human, you know I have a kidney, but I am not a kidney.

> but each InnoDB table is a file.

A table isn't a schema, it is a component of a schema, and most databases don't use InnoDB.

It literally does not describe a file, and does not literally describe the data layout of anything on disk (though with enough knowledge, you may be able to infer facts about probable layouts).

> the JVM all but forces on you

I don't think you're wrong, but you're making this sound like it an issue with the JVM. It's certainly not. I guess it could be an issue with the Java language, but I don't really think so.

Mostly it's an issue with the Java ecosystem.

VAT is categorically different--it is applied to both domestically and foreign produced goods.

I believe import duties are similar to tariffs, and open to criticism on the same grounds.

I wasn't kidding about the "biggest fraud" line. It's not an exaggeration, he's just that full of crap.

Direct quote from Musk:

"Yes, there are FAR more 'eligible' social security numbers than there are citizens in the USA.

This might be the biggest fraud in history."[0]

The worst part is that there’s already a public report about these social security numbers. And it genuinely makes the SSA look bad, but it also makes clear that very few of these accounts ever received payments, and of those that did, they were generally cut off around a decade ago.[1] Does Musk know about the report? Does he care?

If someone wanted to come in and clean house and say "you have to do better" I can imagine there's a case to be made there. That's not what's happening, though.

[0] https://x.com/elonmusk/status/1891357918605332965

[1] https://oig.ssa.gov/assets/uploads/a-06-21-51022.pdf

It's not obvious to me why you'd ban those shoes during training.

You ban doping during training because it gives an advantage at race time. I don't see the analogous reasoning for shoes.

That sure sounds like (2), just restated.

It would still be incredibly dishonest for Musk to say based on these numbers that this is the largest fraud in history.

> In 2010, the Japanese government announced that 82 percent of its citizens reported to be over 100 had already died.

> In 2012, Greece announced that it had discovered that 72 percent of its centenarians claiming pensions – some 9,000 people – were already dead.

Those numbers are three to four orders of magitude smaller than the ones we're discussing. Even factoring in the US being 30 times larger than Greece, we would have less than half a million pensioners if the proportion is similar.

The fact is, Elon found a number and waved it around like a red flag. And both of us are smart enough[0] to know that it doesn't mean what he says it means. But for some reason, you're insisting on defending the original deceptive tweets.

[0] I mean that genuinely! I've read your posts on garbage collection. And in this discussion I take it you're recognizing that those millions of records are likely overwhelming not fraudulent.

Right. A significant part of the reason open source wins so handily isn't that the money for a proprietary solution is always more than it's worth, it's that you can just pull open source dependencies without going through purchasing.

It does seem to me that logically, you have two choices:

1) Take the numbers at face value. In that case, you are predicting millions of accusations of fraud and an enormous number of prosecutions in the next year or two.

2) the situation is somehow more complicated, and most of those millions of records with 140+ ages do not represent fraudulent activity.

P.S. Mentioning the blue zones is incredibly silly. Those regions have modest numbers of individuals being reported in the 100-120 age range, which probably are fraudulent. None of those areas have millions being reported to be 140+. For instance, Sardinia had 13 reported centenarians per 100,000 population, which would be equivalent to ~39,000 centenarians in the US. So it's orders of magnitude less than this database shows.

> the stock is valued as if it will keep growing at that rate for years to come and no one will challenge them.

If it were valued that way, the P/E would be over 100.

Feel free to say Nvidia is overvalued, but you have to get the financials right.

You are right. If that’s the query you need to write, you’ll be ok.

That said, I don’t think I’ve ever had occasion to write a query quite like that. I’ve written

  select * from blah where id in (1,2,3…) and condition

or

  select * from blah where condition1 and condition2

but never a query quite like this. Do you know of use cases for it?

Given that most queries don't look like that, I think my criticism is reasonable. For most use cases, this query will have performance downsides, even if it doesn't for some very narrow use-cases.

The recommended approach is to generate SQL that looks like:

    SELECT \* FROM users
    WHERE id = $1
        AND ($2 IS NULL OR username = $2)
        AND ($3 IS NULL OR age > $3)
        AND ($4 IS NULL OR age < $4)

It's worth noting that this approach has significant dangers for execution performance--it creates a significant chance that you'll get a query plan that doesn't match your actual query. See: https://use-the-index-luke.com/sql/where-clause/obfuscation/... for some related material.

I read this and think "where are the fucking adults?"

Why are juniors just tripping over dumb tickets, when management has projects they want done?

If you want your projects done, assign a team (or multiples) to them, have senior folks on the team and someone who's willing to do project management work[0], and have them prioritize the work. Have the team meet daily and divide the highest priority tasks (individually, pairing or mobbing, as appropriate). The team does not work on other things, unless there's a collective decision they're more important than project work, and the fact that the team is interrupted is communicated to the people who want the project done.

If something comes up that isn't prioritized (and it will, you're not psychic), then discuss it. Slot it in near the top if it's important, start on it right away if it's blocking high priority work. Put it in a deep backlog of "things we'll do someday" if it's low priority.

Make sure there are always high priority tasks to pull, otherwise a junior might trip over a low priority ticket in your backlog. Ideally, the high priority tickets are already on your Jira board with a status like "Ready".

Realistically, the danger is that you overfocus on project work, in a way that's frustrating to your employees, and loses you the opportunity to have people do high-impact non-project work.

But the premise here is that you're the kind of manager who doesn't care about that sort of thing, and only wants to reward employees for shipping projects. So grow up and start telling people what to do.

[0] This person might not be a project manager per se, depending on the project, it might work a lot better if they're a former developer. We did a database migration for my company (7 figure annual savings that were very time sensitive, because a certain database vendor likes to negotiate multi-year contracts), and a developer who moved into management worked well because she knew enough about what we were doing to participate in the prioritization discussions.

That said, it's still better if the project manager role is not dictating what tickets go first. If the team says "we really gotta do X", you need to defer when you have a healthy team. The project manager's job is to make sure everyone's in agreement about how to prioritize, and there's no better way to coach that than by having the whole team make decisions together.

I'm so tired of rants like these. Both the pro and anti-dependency versions. It's just impossible to express an opinion on the issue without looking at specific applications.

What I want to see is someone actually break down a real application and its dependencies and argue through what's included and what's omitted.

At least there's one example. I just think it's wrong (and I'm not the only one...https://news.ycombinator.com/item?id=42813003). The terminalsize crate has special behavior for illumos. The average developer should never have to think about illumos.

(Note in case Bryan Cantrill walks by: no slight towards illumos or you--you seem great, loved the Oracle rant. Illumos seems cool. It's just that most developers should not think about it).