I think it’s good for people to have children. At least one and preferably no more than two.
If we contain population growth, the riches already created are for the taking for generations to come and the planet finally gets a rest.
It does require a reckoning with the capitalist elite that would like to produce anyway, but I feel that may be coming regardless of our feelings towards children.
I’m a fiction author in addition to my philosophy blog 😉
But if you’re asking what my inspiration is… I dunno, too much to list here.
But in case you’re wondering, it’s not AI 😅 I hate LLMs. And the only way to fight what you hate is through love, or so I’ve found.
Happy Nextcloud user here. It has its ups and downs, but overall I vastly prefer it over Google Docs.
I’m hoping early 2026, but I’m looking to hire a platform owner for Android, since I don’t use it myself. So it’s 🤞
I absolutely agree with you. If I can avoid NPM I will indeed do so. Sometimes that means using Deno, but sometimes it can be a valid reason to avoid using the language altogether. And sometimes we have to suck it up 🤷♂️
Ah, fair :) then yeah, I’d say it’s pretty aligned with emerging architecture, just that I’m trying to define the values (and in the next post, technical guidelines based on those values) to (hopefully!) help you make the right decisions as you’re working on an emerging architecture.
I assume you're referring to this blog series: https://medium.com/prospa-technology/emerging-vs-intentional-architecture-385071ae5d75 ? I wasn't aware of it, and it seems to have some insightful observations! There's definitely some overlap, but by the looks of it, I think I will diverge quite a bit with my next post. I think I'm pretty aligned on the "One-Way Decisions" vs "Two-Way Decisions" part. A One-Way decision in my mind would be, which programming language or framework do we use? Do we use REST or GraphQL?
But it doesn't really go into how to deal with Two-Way decisions, apart from saying to trust your developers. And I think it kinda glosses over the part that things that may appear to be Two-Way decisions initially may actually be closer to One-Way decisions if you continue to build on them. So where that blog still focuses quite a bit on the process, I think I want to shift the focus a bit more to the technical side (so far I've mostly laid down the values that inform the technical direction), especially when it comes to Two-Way decisions. I wasn't thinking about covering One-Way decisions much, but rather on how to shape everyday coding to be more in alignment with Post/Emerging architecture so that you can avoid the Two-Way decisions that in retrospect aren't as much of a Two-Way decision as you'd hope.
Hope that makes sense :D
It’s limited to JS runtimes, but this discussion might be of use: https://github.com/biomejs/biome/discussions/2467 I think you may find Boa fits your criteria, except for the JIT part.
can you define physical for me?
The distinction I tend to make is between physical using the classical definition of physics (where everything is made of particles basically) and the quantum mechanical physics which defies “physical” in the classical sense. So far we’ve only been able to scientifically witness quantum physics in small particles, but as you say, there’s no reason it can’t apply at a macro scale, just… we don’t know how to witness it, if possible.
it doesn’t require an observer to collapse the wave function
Or maybe it does? The explanation I have for us being unable to apply the experiments at a larger scale is that as we scale things up, it becomes harder and harder to avoid accidental observation that would taint the experiment. But that’s really no more than a hunch/gut feeling. I would have no idea how to prove that 😅
I agree performance is much more about architecture than language performance at the bare metal. But especially in security-conscious environments C and C++ lose in performance because architecture decisions include mitigations that need to compensate for the languages’ lack of safety. I know of several projects where C or C++ code is either delegated to separate processes with reduced permissions or to WASM sandboxes. Firefox even famously used to compile C++ code to WASM and then used a WASM ahead-of-time compiler to turn it back into native code that still maintained properties of being sandboxed. Such measures gravely impact performance however, so in those instances C is far removed from having a performance lead.
Go is almost memory safe, but it does suffer from an issue with its thick pointers (type + address) that can cause race conditions to misrepresent the type of a data structure. This can lead to true segmentation faults and out of bound memory accesses, though it will probably be quite difficult (but not impossible) to exploit them.
There’s a lot of levels at which I could reply to this comment, because it’s quite a philosophical topic, but let me clarify what I meant at the end of my last comment, before writing a wall of text here :)
As I said in my previous comment, faith is largely a means to make sense of our subjective experiences. We can refine our faith by talking about our experiences with other people.
So the most basic fallacy I was alluding to, from people who believe you can refine your faith by talking with an LLM is this: An LLM has no subjective experiences, because it doesn’t experience anything at all. This is one way how using the output from an LLM as a source of inspiration for your faith sets you up for psychosis. You start believing things that have no basis in reality or anyone’s genuine experiences. Rather, you may start believing in machine-generated approximations from which coherence has been lost.
But it seems your understanding was slightly different, in that people might develop their own sense of faith from experiences with an LLM itself rather than through the exchange of presumed experiences with the LLM. Do I understand correctly that you think some people attribute godlike qualities to the LLM, maybe through the presumption that it is an AGI? That would be a bit of a different discussion indeed :)