von_lohengramm (u/von_lohengramm)

von_lohengramm commented on The United States and Israel have launched a major attack on Iran cnn.com/2026/02/28/middle... · Posted by u/lavp

ceejayoz · 15 days ago

> armed men wearing balaclavas drive up in vans and abduct people off the street to draft them into the military

Every country with conscription will do this if you refuse to show up.

> Both the west and the east have been pressuring them to hold elections to no avail.

Their own constitution and laws forbids it during martial law.

“Both Putin and Trump want Zelensky to violate the Ukrainian Constitution” is not the grand slam take you imagine it to be.

von_lohengramm · 15 days ago

> Every country with conscription will do this if you refuse to show up.

Was that MP a draft dodger? The issue isn't them picking draft dodgers, it's them picking up anybody that looks like they might be a draft dodger and the tactics they employ to do it.

von_lohengramm commented on Data Processing Benchmark Featuring Rust, Go, Swift, Zig, Julia etc. github.com/zupat/related_... · Posted by u/behnamoh

inkyoto · a month ago

Quality does vary wildly because the languages vary wildly in terms of language constructs and standard libraries. Proficiency in every.single.language. used in the benchmark perhaps should not be taken for granted.

But it is an GitHub repository and the repository owner appears to accept PR's and allows people to raise an issue to provide their feedback, or… it can be forked and improved upon. Feel free to jump in and contribute to make it a better benchmark that will not be «frankly a joke» or «_really_ bad».

von_lohengramm · a month ago

I'm completely alright with just having fun and hosting your own little sandboxes online, but what good does it do to post and share this with others in its current state? The picture it paints is certainly not representative, and this sort of thing has been done a million times over with much better consistency. Again, I think it's great to hack around in every language and document your journey all the way, but sharing this is borderline misinformation. It's certainly not my duty to right the wrongs of this benchmark.

von_lohengramm commented on Data Processing Benchmark Featuring Rust, Go, Swift, Zig, Julia etc. github.com/zupat/related_... · Posted by u/behnamoh

von_lohengramm · a month ago

This entire benchmark is frankly a joke. As other commenters have pointed out, the compiler flags make no sense, they use pretty egregious ways to measure performance, and ancient versions are being used across the board. Worst of all, the code quality in each sample is extremely variable and some are _really_ bad.

von_lohengramm commented on Thoughts on Go vs. Rust vs. Zig sinclairtarget.com/blog/2... · Posted by u/yurivish

kachapopopow · 3 months ago

I could never get into zig purely because of the syntax and I know I am not alone, can someone explain the odd choices that were taken when creating zig?

the most odd one probably being 'const expected = [_]u32{ 123, 67, 89, 99 };'

and the 2nd most being the word 'try' instead of just ?

the 3rd one would be the imports

and `try std.fs.File.stdout().writeAll("hello world!\n");` is not really convincing either for a basic print.

von_lohengramm · 3 months ago

> and the 2nd most being the word 'try' instead of just ?

All control flow in Zig is done via keyword

von_lohengramm commented on Google unkills JPEG XL? tonisagrista.com/blog/202... · Posted by u/speckx

CharlesW · 3 months ago

JXL's war is not with AVIF, which is already a de-facto standard which has near-universal browser support, is enshrined as an Apple image default, will only become more popular as AV1 video does, etc. It's not going anywhere.

That's not to say that JXL is bad or going away. It currently has poor browser support, but it's now finding its footing in niche use cases (archival, prosumer photography, medical), and will eventually become ubiquitous enough to just be what the average person refers to as "JPEG" 10 years from now.

To address selected claims made in the post:

• "AVIF is 'homegrown'" – AVIF is an open, royalty-free AOMedia standard developed by the Alliance for Open Media (Google, Microsoft, Amazon, Netflix, Mozilla, etc.).

• "AVIF is 'inferior'" – AVIF is significantly better than JPEG/WebP in compression efficiency at comparable quality, and comparable with JXL in many scenarios.

• "AVIF is ridiculous in this aspect, capping at 8,193×4,320." — JXL's theoretical maximum image size is bigger. The author cites AVIF's Baseline profile (think embedded devices), but AVIF supports 16,384×8,704 per tile. It HEIF container format supports a grid of up to 65,535 tiles (so logical images sizes up to 1,073,725,440 wide or 283,111,200 tall).

So, JPEG XL is good. Yes, it's far behind AVIF in terms of adoption and ecosystem, but that will improve. AVIF is likely to erase any current JXL quality advantages with AV2, but both JXL and AV1/AV2 encoders will get better with time, so they're likely to be neck-and-neck in quality for the foreseeable future.

von_lohengramm · 3 months ago

> JXL's theoretical maximum image size is bigger.

This is all fine and good until you actually try encoding such an image with libjxl. What an absolute garbage codebase. I'm sure it's gotten better since I've last used it, but it's impressive how unoptimized, memory hungry, and of course wildly unsafe/crashy it was. Many of the options just completely didn't work, either due to exponential performance, crashes, or weird special-casing that breaks the moment you encode anything that's dissimilar from the sample images used in the sham benchmark made by the libjxl creators. I don't even think a high resolution image had ever been successfully encoded on higher effort levels, since I doubt that anyone trying to do so had the terabytes of RAM required.

I was genuinely flabbergasted when there was mass support for reviving it a couple years ago. I don't think anyone advocating for it has actually used libjxl at all and were just internet hypemen. That seems to happen all too often nowadays.

This all being said, I'm mildly optimistic for a retry with jxl-rs. However, seeing much of the same contributors from libjxl on jxl-rs does make me quite cautious.

von_lohengramm commented on Games using anti-cheats and their compatibility with GNU/Linux or Wine/Proton areweanticheatyet.com/... · Posted by u/doener

surajrmal · 3 months ago

Unpopular opinion, but we would be better off with a single open trusted implementation of anti cheat (aka drm) which can attest whatever requirements are desired by the game is met. The only real problem is that it would likely be limited to approved kernel images and someone would need to own that validation and signing infrastructure, but you could imagine having multiple trusted entities have this role.

von_lohengramm · 3 months ago

Imagine wanting tivoization. Horrifying.

von_lohengramm commented on Zig builds are getting faster mitchellh.com/writing/zig... · Posted by u/emschwartz

burnt-resistor · 5 months ago

There is no singular "gold standard".

vlang is really fast, recompiling itself entirely within a couple of seconds.

And Go's compiler is pretty fast for what it does too.

No one platform has a unique monopoly on build efficiency.

And also there are build caching tools and techniques that obviate the need for recompliation altogether.

von_lohengramm · 5 months ago

> vlang is really fast, recompiling itself entirely within a couple of seconds.

Does V still just output C and use TCC under the hood?

von_lohengramm commented on In C++ modules globally unique module names seem to be unavoidable nibblestew.blogspot.com/2... · Posted by u/signa11

1718627440 · 5 months ago

Why do you put in foreign code (excluding declarations) in your translation unit? Isn't a translation unit under the control of a single party/vendor? And you can just undef them and the compiler gives a warning/error about the redefinition.

von_lohengramm · 5 months ago

That might be the case in C land, but C++ land usually has a lot more stuff in headers. For examples, templates are not very useful unless they're defined in headers.

von_lohengramm commented on This website has no class aaadaaam.com/notes/no-cla... · Posted by u/robin_reala

zwnow · 6 months ago

I am sorry but its not the devs who want complexity. Users and Designers want a snappy interactive UI with lots of animations to get the "vibe" right. Devs are usually fine with websites looking like they are straight out of 2003 (considering all the language doc pages I've seen)

von_lohengramm · 6 months ago

>Users ... want a snappy interactive UI with lots of animations to get the "vibe" right

[citation needed]