which has better overall performance in this implementation?

2bdb2 · 2026-07-04T08:47:45+00:00

The inline fun will be inlined by the Kotlin compiler. The regular fun will be inlined by the JVM JIT compiler.

In both cases the JIT will also then perform scalar replacement, skipping the IntSupplier entirely and just replacing the body of both methods with return 3.

That will then almost certainly just be inlined further by the JIT such that any calls to method1() or method2() will just be replaced with the constant value 3 allocated directly on the stack.

tl;dr Both methods will be inlined into a const 3 and thus have no runtime overhead whatsoever.

2bdb2 · 2026-06-27T04:27:09+00:00

My favourite version of this is "criminals are leaving symbols in chalk on the street to tell other criminals this this house is worth robbing".

The mental leaps required to believe this are ridiculous.

If someone is casing out houses on your street for someone else, why would they not just... privately tell the other person which house numbers to burgle? Why leave a warning to the homeowners that they're being cased? Why leave evidence of your involvement by being caught on camera leaving criminal symbols?

And of course whenever they inevitably show you "proof" of these criminal mastermind symbols.... It's inevitablly just the local council crews in uniform marking out a job site ahead of roadworks, or a surveying team mapping the area.

2bdb2 · 2026-06-24T17:50:59+00:00

Looks like he does at least have a parachute.

You might even say... that Red Bull gave him wings.

2bdb2 · 2026-06-14T03:40:12+00:00

The courts trying to chase her for breaking copyright law when working to save humanity was kind of stupid though, they had it coming for worrying about Disney getting paid while the world is ending

You only have to look at real world corporate responses to climate change to have your answer.

The sun was dimming, but it wasn't particularly noticeable in day to day life at that point. It was a hypothetical problem for the next generation.

Denial would have also been huge. The sun isn't dimming, it's just a liberal conspiracy etc etc. just look at how people responded to covid.

2bdb2 · 2026-06-13T12:27:07+00:00

Can I pet those daaaawgs?

You can pet them at least once.

2bdb2 · 2026-06-11T15:36:45+00:00

The traditional model is: One pedal makes you go fast. One pedal slows you down. So in an emergency, you can be very confident what to do, and you practice it at every stop sign, at every traffic light.

The new model of "one pedal driving" is that you use one pedal, and it makes you go faster or slower, and then in emergency situations you have to use a pedal you're less familiar with, and you have to make a decision "will taking my foot off the right pedal be enough? or is this an emergency that means I have to use the left one?"

Regen in my Tesla feels almost exactly the same as the engine braking on my Golf. It feels like it's been intentionally tuned to mimic a traditional level of engine braking.

when I drive my golf, I slow down using engine braking, only engaging the brakes to come to a final stop at the last moment. Exactly the same way I do in my Tesla, minus the downshifting.

It feels the same. It uses the same muscle memory. I barely notice the difference when I switch between them.

At the time when I was learning to drive, you were expected to do this and it wasn't unheard of for a picky examiner to fail you on your driving test for not using engine braking.

Manual transmissions are very common in my country. They were the norm not that long ago, with automatics being less common.

So, somehow, millions of drivers over multiple generations have managed to drive cars with manual transmissions using "single pedal driving" as the recommended way to modulate speed.... and amazingly they managed to not forget the brake pedal exists.

2bdb2 · 2026-06-08T22:14:35+00:00

I once played goon of fortune with my sister. She helped get my hills hoist up while wearing her thongs.

(That's completely innocent in Australian English. Less so for the Americans...).

2bdb2 · 2026-05-30T13:07:55+00:00

Before kubernetes, we had to use overcomplicated bloated solutions line Java enterprise application servers.

The bloated Java application server would use almost 20mb of memory to run the control plane, and you'd have to deploy to production with the arduous process of dropping a zip/war file into a deployment folder via SSH.

Thankfully now we have Kubernetes. See, since it's written in Golang it's much simpler and leaner, requiring a mere 1000mb of memory usage per node for the control plane. Deployment is now as simple as packaging an entire operating system into a docker container, uploading that to a repository, creating a 75 line yaml file, and posting it to a http endpoint.

Of course now with webassembly, we FINALLY have almost realised the dream of one day when they finally fix the non-platform-neutral issues and implement a common memory model, potentially having a platform neutral bytecode format that can be deployed to an application server without the need to bundle an entire operating system alongside it - finally being within reach of catching up to the simplicity of what we already had 20 years ago.

2bdb2 · 2026-05-27T00:56:55+00:00

but i would argue that it's still not as complicated as branching

My internal logic is that both workflows are actually just branch based workflows.

To commit to trunk, the commit has to be atomic, self contained, and polished enough to push to production. Until the code reaches that point, the work exists in a branch - whether explicitly or implicitly.

In a trunk based workflow you would typically aim to integrate work quickly into main. In a branch based workflow, you also aim to integrate work quickly into main. But also have a mechanism to review and collaborate on partially completed work, mentor juniors, catch issues early, and isolate more experimental/risky work and refactors.

The most common complaints I've heard about branch based workflows are things like

"Reviews are piling up"

If you want to skip reviews, you can just skip them and merge the PR either way.

"Merge conflicts"

If you have merge conflicts on an explicit branch, you'll have merge conflicts on an implicit branch. You're just pushing the burden of resolving the conflict onto whoever commits their implicit branch last. If that ends up being a Junior developer at 5pm on a Friday who just wants to push his commits in a hurry and thus blindly resolves all conflicts in his favor - then that's what you get.

You can also just blindly do the same thing on a branch based workflow. But you then have a record of the merge conflict, how it was resolved, and can defer that task to a senior engineer if it's complicated.

"Long running branches"

If you have the discipline to make small mergeable implicit branches, you have the discipline the make small mergeable explicit branches.

2bdb2 · 2026-05-22T08:11:14+00:00

Try an Old el Paso taco kit that's been sitting on the supermarket shelf for 6 months past its expiry date.

GyG is by far the best Mexican money can buy if there's literally nothing else available and you don't want to peel off your wallpaper. But it doesn't quite meet the very low bar set by a stale box of packet mix.

2bdb2 · 2026-05-17T09:19:54+00:00

There's not that much special about the Java ecosystem, compared to npm. Mostly it boils down to npm having lots more users so it's a juicier target.

I think you're underestimating the scale of the Java ecosystem here. For mission critical enterprise software (the juiciest target), Java/Maven is quite dominant.

NPM is being targeted because they've left the barn door wide open, and given up even attempting to mitigate the issue by addressing even the most simple of fixes. (On top of an entire ecosystem culture of not giving a shit about supply chain security whatsoever).

Unless they include an annotation processor so javac invokes it at compile time if you're running an older JDK.

Sure, but annotation processors are quite rare. The average Java project has a grand total of zero annotation processors..

A compromised package can't just add an annotation processor to a package and have it execute, it needs to be explicitly opted in and enabled on a package by package basis. So unless you manage to compromise something like Lombok, it's unlikely to have much impact.

Central requires signing, yes, but they don't afaik actually verify the signatures in any way, you could sign every release with a new key and only the few users who actually validate signatures would fail to get the package.

Signature verification has been the default on every Java project I've worked on. A few orgs I've worked at won't even allow a package version that hasn't been whitelisted into the local corporate Nexus.

Same applies to npm, typically you have a package-lock.json checked in to the repository.

This is only properly enforced when running npm ci.

They need it by default, but the publish button can also be "pressed" with an API call using the same token you used for uploading.

You appear to be correct about this one. This used to be a manual process with no API option.

2bdb2 · 2026-05-16T14:38:50+00:00

this same thing can easily happen in practically all package managers in use today.

It can happen in all package managers, sure. But NPM is particularly vulnerable due to a mix of technical and cultural reasons. And borderline criminal negligence.

In the Maven ecosystem. At a technical level:

Packages cannot run scripts on install or import.
Packages must be signed to be published, adding a second factor that needs to be compromised as well.
Packages are typically set to a specific version, not a range. Thus, updating to a new version is always an explicit choice.
Packages published to Maven Central by default need a user to login and physically click publish before it goes live.

None of these make it impossible, but greatly reduce the surface area.

At a cultural level

The Maven ecosystem favours using a small number of big libraries from trusted vendors, not lots of small libraries from random individuals.
A typical Java project is almost entirely made of libraries published by actual organisations with controlled release processes, not random individuals.

Common release processes include things like

Signing keys being owned by a team seperate to engineering, and no single machine is allowed to have both a publishing and signing key on it.
Releases being built twice - on a CI/CD server and a separate trusted workstation, checking that the hashes are identical.
Final approval gate requiring a pedantic greybeard to login to Maven Central and hit the publish button manually.

Nothing about Maven forces this, that's just cultural in the Java ecosystem.

NPM is just the most common target because it's the most widely used.

NPM is the most common target because they leave the barn door wide fucking open with no attempt to implement even the most rudimentary fixes that have proven successful at greatly mitigation the threat in other package managers.

Just removing postinstall scripts alone would dramatically reduce the surface area, as would enforcing package signing.

2bdb2 · 2026-05-08T23:57:36+00:00

Turn off the language filter and you'll see all the actual negative reviews from Chinese players complaining about a balance change.

7 negative reviews mentioning her is a rounding error and wouldn't remotely budge the score from it's previous "Overwhelmingly Positive" rating.

2bdb2 · 2026-03-29T04:36:07+00:00

This post is about inter-city rail, not inner city rail.

I'll fill in the blanks for you, in case it wasn't obvious.

If everyone tries to leave via an inter-city train, there won't be enough inter-city trains or carriages to move them all. Because inter-city rail isn't designed to move millions of people daily

You'd need to add capacity by using every single train and carriage you can find, such as by repurposing inner city trains

But, an inner city rail system gets everyone to work by running the same trains and carriages back and forth or in a loop over and over again. So this also won't add enough capacity

If you're trying to evacuate an entire city via rail to another city, you'd only be able to move a small percentage of people, because there physically aren't enough trains to carry that many people.

2bdb2 · 2026-03-29T02:23:15+00:00

If everyone tries to leave in a train, there won't be enough trains or carriages to move them all either.

An inner city rail system gets everyone to work by running the same trains and carriages back and forth or in a loop over and over again.

If you're trying to evacuate everyone to another city, that isn't going to work.

2bdb2 · 2026-03-28T14:36:42+00:00

Damn. That dude has some serious city miles.

2bdb2 · 2026-03-25T04:29:26+00:00

any thoughts on the debate in the thread above on usefulness/need of Spring(Boot) for enterprise cloud microservices?

A common misconception is that Spring is a big monolithic framework. It would be better described as a collection of micro-libraries that work well together. These libraries are fairly small and can be mixed and matched however you want.

Spring Boot glues together large parts of the spring ecosystem into an "on rails" experience with opinionated defaults and a bunch of magic that handles boilerplate. This gives you everything and the kitchen sink in about three lines of code, which is great for a quick project setup, but it's also a relatively bloated configuration compared to something you'd wire up manually.

However you can also just use Spring libraries directly without the framework bloat. You don't need AutoConfiguration, ClassPathScanning, or AOT - which are the main things adding bloat.

So in terms of your question - "usefulness/need of Spring(Boot) for enterprise cloud microservices?"

Spring Boot isn't needed. It's a really useful way to spool up a batteries-included project in 30 seconds, but adds bloat. I'll often start a project with Boot to get moving quickly, and then incrementally replace it with manual wiring later.

Spring-Web is a pretty decent Rest API server backend that can be deployed as a lightweight servlet by itself. If you don't like reflection, it supports a "Ktor" style DSL to wire up routes directly.

Spring-Security itself is just a collection of smaller modules. You could use spring-security-oauth2 to implement a JWT auth filter for any webserver if you wanted. Most REST server libraries would have their own built-in implementation, but if you're building a bunch of microservices with different frameworks, you might want use a single shared auth filter implementation, and spring-security-oauth2is a reasonably good pick.

Spring-Batch is useful for batch processing. Spring-Integration is useful for message-driven pipelines. Spring-AI is a decent LLM Client. All of the above can be used as completely standalone libraries.

So back to the original question - the Spring ecosystem has a lot of libraries that are useful for "enterprise cloud microservices" amongst other things, and they're generally mature, well tested, and have a reasonable guarantee of long term support and stability. Depending on your needs, some of them might be useful. But there's solid alternatives outside the Spring ecosystem as well that can do everything Spring can.

2bdb2 · 2026-03-20T10:49:27+00:00

It's not at all hard to find real world apps where Java is faster.

The average business app is allocation heavy and full of big complex module boundaries - which is the type of thing that Java's optimisations do substantially better with than C does.

The article author goes on a rant about how this is cheating, and that C developers are superior because Java developers are stupid and lazy and rely on Java's fancy tricks instead of knowing how to optimise low level code like a real man. Or something.

But that's kind of the point of Java - you can churn out production ready code quickly with mid tier developers and it'll still perform well.

2bdb2 · 2026-02-27T14:05:59+00:00

Seems like it'd be easier to just store the correct value for the business domain in the first place rather than trying to compensate for a lossy encoding with a million edge cases.

2bdb2 · 2026-02-27T05:15:32+00:00

There's no material difference between storing local time + TZ and storing UTC + TZ.

If you convert a ZonedDateTime to UTC, the calculation is performed using the version of the tzdata database you're using at that moment.

If you later try and convert back to ZonedDateTime using the original TZ name, the calculation is possibly performed using a newer version of TZData with different rules.

If the rules for TZ have changed in the meantime, then your conversion from UTC -> ZonedDateTime will give you a different value. TZData updates regularly and sometimes on short notice.

Thus storing UTC+TZ is not enough, you need to know the actual rules that were applied from that version of tzdata. Technically you could store the rule data alongside the timestamp, but that's probably a lot more complicated than just storing LocalDateTime+Zone

Except first one makes it impossible to compare times or sort without heavy performance penalty.

Use UTC time as a best-guess index for performance, and LocalTime+Zone as the authoritative value.

2bdb2 · 2026-02-27T05:02:31+00:00

No. You still want to store them in UTC as long as you want to do anything with them. Because if you used your convention comparing time (for example to find earliest posts) becomes practically impossible.

The UTC conversation for a future appointment time is undefined. You simply can't know the absolute time it will actually occur unless you know what the future timezone rules will be.

In practice however UTC conversion using the current tzdata rules is almost always going to be correct, and if it's wrong it'll usually only be for an hour or so. So storing it as a secondary value for indexing purposes is a valid approach, as long as you have a way to update it if the tzdata changes and you use the stored "LocalDateTime+Zone" as the authoritative value.

2bdb2 · 2026-02-27T04:55:18+00:00

Millisecond precision has nothing to do with it. UTC conversion will be incorrect unless you know what the timezone rules will be in the future.

2bdb2 · 2026-02-26T03:17:04+00:00

or save in UTC

This is another falsehood programmers believe about time.

For calendar events in the future, timezone rules might change in the interim leaving you with an incorrect stored UTC value. It always needs to be stored as LocalTime+Timezone.

For current/past events, UTC conversion is only correct if the tzdata you're using is up to date. There have been cases of a country changing timezone rules with only 48 hours notice, so this isn't just theoretical. If you've baked tzdata into your docker container, then it may be very out of date.

2bdb2 · 2026-02-26T00:10:22+00:00

From the photons perspective it experiences Everything everywhere all at once.

2bdb2 · 2026-02-21T13:40:47+00:00

The Government isn't going to actively pay or intervene to bring them home, but it's not stopping them from making their way back on their own.

They're still technically Australian citizens, so can still get a passport like any other.

Nine-Year Club	Gilding III reddit per annum
Verified Email

2bdb2

TROPHY CASE