simonask

We managed without smartphones before smartphones were a requirement for participating in society. That is, if you’re a millennial or older.

We can’t just pretend that it’s possible to live an adult life without one in 2026. In 2008, certainly, but that’s not the world these kids grew up in.

But we’re talking about kids, which is a whole different matter.

It certainly doesn't say that there is any less love among members of that community.

It would be more correct to say that there is no direct translation for the English word "love". Lots of languages fall in that category. Languages are complicated.

"Vibrant" is certainly one way to describe it...

"Why cook food in 2026 [while McDonald's exists]?"

None of Human civilization would exist if the norm was to share your unfiltered opinions about other people. It has nothing to do with “corporate”.

It’s just so unbelievably immature, and I know of no other industry where this is common.

There is no “authoritarian left” anywhere in the West, outside of a few vestigial Communist parties with close to zero influence.

This can change in the future, as it has before, but in 2026, even libertarians only care about personal freedom for a certain class of people.

I think there were enough attacks already for cargo that one can not call this FUD.

What attacks are you referring to specifically?

It is also obvious that this way to distribute software is susceptible to supply chain attacks. cargo audit is an attempt to fix this retrospectively, but does not fix this fundamentally broken model.

This is the FUD I'm talking about. If you worry about supply chain attacks, it's not harder to be careful just because dealing with dependencies in general is much easier. You have to vet your dependencies no matter what.

The Linux distribution model worked perfectly fine for the 30 years I am using Linux.

The xz scandal was a damn close call. Linux is a forest of distributions, and each distribution is a separate vulnerable organization.

On the other hand, systems like cargo a clearly a supply chain disaster.

I don't think that has been shown to be true. There's a lot of FUD, though. Tools like `cargo vet` and `cargo audit` seem to be pretty good.

I also think that languages should not have their own specific packaging system. This should be done on a distribution level, which provides curated lists of software. This system works well in the Linux world. The problem is the support for the commercial platforms.

I mean, it works until it doesn't. There are really significant drawbacks to this as well, including the knack some distributors have for thinking they know better than the original developer.

Security is not, and in fact can never be, all-or-nothing. An imperfect solution is better than no solution. Developers have the reasonable expectation that opening a project in VS Code does not upload their home directory to a remote server. Performing a full build of a project is a different operation with different associated expectations.

I don't think masochism is a reliable or sound security strategy.

I think it's pretty obvious they are referring to package management functionality as the radiator fluid in this analogy, and the compiler is the fuel tank.

I'm sorry, I have to address this take every time someone brings it up. The lack of a modern, ubiquitous, cross-platform packaging system is an absolutely terrible thing for C++.

I've worked on many large projects in C++, and every single one of them contains a bespoke, buggy, undermaintained JSON parser, URL parser, configuration file parser, async framework, and so on. It used to be the case that almost every large C++ project started out by defining its own friggin' string type.

Dependency anxiety is a variant of NIH syndrome, and it leads to much, much worse quality software in the average case. Most companies are not in the business of writing a bug-free async framework, and yet here we are. The cost of vetting your dependencies is much, much lower than writing and maintaining all these things from scratch.

I think "build systems" is a too broad category in that argument.

Language-specific build facilities, like Cargo's build.rs and Zig's build scripts, typically have a limited scope - generating a bit of source code, discovering some linker flags, stuff like that. These scripts need to be run by LSP servers when opening the project in an editor to get basic features working, so that's a fairly risky thing.

They are also currently doing things like invoking CMake and other build systems, but you could definitely conceive of a world where that was a separate step in the build process, and that world seems pretty attractive to me.

A common pattern in Rust projects is to have a `*-sys` crate representing the C FFI bindings, and they typically also do something like invoke CMake or similar to actually build the C/C++ library underneath. But if you have a larger project that already integrates multiple build systems, this is really quite inconvenient in most cases.

This approach is harder than you might imagine. LLVM can do a lot of things that don't map to C language constructs. You cannot generally roundtrip arbitrary LLVM IR through some C representation. You can emulate most things, but you won't necessarily get the same LLVM IR in the other end.

Interesting read, even as someone who isn't using Zig.

I wonder, these arbitrary-width integers... Is it actually even really worth it? My intuition is to prefer manually packing/unpacking things instead (in any language, even C that has bit width for struct fields), because it gives me a better mental picture of the code that is actually generated. Particularly for something like an signed odd-bit integer - what kind of code gets generated for sign-extension, a presumably common operation?

Does anybody have other experiences with them, one way or the other?

It's weird because... I'm not the customer on either Reddit or HN. I'm the product.

Ruby has both kinds of operators as well, and it's fine. The thing in Ruby, though, is that the English logical operators have lower precedence than the symbolic logical operators, so you can use them in place of parentheses. Sometimes that's confusing, other times it can be used to make code very readable.

In general, I would expect symbolic operators to be desirable in complex boolean expressions, because "loud punctuation" stands out among English words when reading the code.

Driving in Europe would be completely impossible without them. I have no idea what the Greek word for "no parking or stopping between 09 and 15" is, or the Croatian word for "left".

Where I am, I was taught that activating the turn signals means "I have made a decision to change lanes", so the appropriate reaction from surrounding traffic is to either safely accommodate that choice, or indicate using the horn and/or lights that the decision is unsafe and must be cancelled.

I'm in Scandinavia, and it feels like surrounding regions have similar conventions.

From outside the US, nothing about him has really been predictable, except that he consistently lies about everything.

The only predictable thing about this American presidency is the total chaos that has been inflicted on the world by millions of intellectually degenerate Americans. This is what the world sees. Almost nobody is making excuses for him, everybody is trying to move on without the US.

So yeah, in that sense another war is simultaneously an unpredictable outcome and an unsurprising outcome.

The US is a statistical outlier in almost every single metric. Almost nothing about the US generalizes, not to the world as a whole, and not to other Western countries. Certainly not to functioning liberal democracies.

The important thing is that Rust editions affect semantics and name resolution. In such an analogy, JVM bytecode is the equivalent of Rust code - various semantics are baked in, but stuff like name resolution isn't (at least not completely).

The reason is invalid.

As far as I understand, this is purely a result of lack of maintainer resources. Apparently, nobody has been bothered enough by this to contribute the relevant changes.

Keep in mind that all of rustc and libs development takes place on Github.

This works for a while. Then you - the programmer - grow up.

Wise customers know this.

Your story here also illustrates why GUI over the network used to be a much more important use case than it currently is.

These days it’s unbelievably niche, as opposed to more controlled screen sharing scenarios. I think it’s understandable that it doesn’t get a high priority.

Just to let you know, 1000 messages per second over a UNIX socket between two processes is very much well within the capabilities of any recent machine running, say, Linux. That’s not many at all.

FWIW, they have been unfashionable for much longer than Wayland has been usable, on all platforms.

And that’s understandable. It’s not actually good usability.

On general principle, I think 22 years of inactivity is perfectly reasonable for considering any software project perfectly dead.

I don’t think anybody said that Arabic has suffered a complete standstill, and it has doubtlessly evolved significantly.

But if you compare it with basically any other major language, it’s clearly much, much more conservative. If you are a native English speaker, understanding English from 1,000 years ago is like learning a completely different language. If you are a native speaker of Italian, you cannot understand a text in Latin without significant training. This is true for all European languages other than Icelandic.

Chinese is pretty similar, even though the written language is slightly more stable.

So in comparison, Arabic is incredibly conservative.