aeldidi

I'm gonna use this as an opportunity to get some feedback on mine: https://ayman.eldidi.org/articles/unicode-identifiers/

I've had better experience with LLMs translating than any bespoke translation tool, oddly enough. LLMs seemingly have a very good handle on regional varieties. As an example, I've never found a good translator for Lebanese/Syrian Arabic dialects, but ChatGPT was able to easily translate for me, even getting right some lesser used rural accent quirks which I didn't even know how to translate (similar to something like "y'all" in english).

To be fair, I wasn't using it in the way the parent comment described, for me I said: "this person speaking Lebanese/Syrian Arabic said something that sounded like [try my best to replicate the sentence]. What did they most likely mean?" and got a pretty much spot-on answer.

I wonder if this ability translates to other languages, but I wouldn't be able to tell. My Arabic is "good enough" to tell that the translations I got were good, but I'd be interested to here from someone who knows more if, for example fuzhounese translation is any good.

The withpersona.com URL seems to return 404.

The Acid2 test is the benchmark you’re thinking of, for anyone not aware: acid2.acidtests.org

> The C compiler that Anthropic created or whatever verb your want to use should prove that Claude is capable of doing reasonably complex level of making software.

I don't doubt that an LLM would theoretically be capable of doing these sorts of things, nor did I intend to give off that sentiment, rather I was more evaluating if it was as practical as some people seem to be making the case for. For example, a C compiler is very impressive, but its clear from the blog post[0] that this required a massive amount of effort setting things up and constant monitoring and working around limitations of Claude Code and whatnot, not to mention $20,000. That doesn't seem at all practical, and I wonder if Nicholas Carlini (the author of the Anthropic post) would have had more success using Claude Code alongside his own abilities for significantly cheaper. While it might seem like moving the goalpost, I don't think it's the same thing to compare what I was saying with the fact that a multi billion dollar corporation whose entire business model relies on it can vibe code a C compiler with $20,000 worth of tokens.

> The problem is people have egos, myself included. Not in the inflated sense, but in the "I built a thing a now the Internet is shitting on me and I feel bad" sense.

Yes, this is actually a good point. I do feel like there's a self report bias at play here when it comes to this too. For example, someone might feel like they're more productive, but their output is roughly the same as what it was pre-LLM tooling. This is kind of where I'm at right now with this whole thing.

> The "open secret" is that shipping stuff is hard. Who hasn't bought a domain name for a side project that didn't go anywhere. If there's anybody out there, raise your hand! So there's another filtering effect.

My hand is definitely up here, shipping is very hard! I would also agree that it's an "open secret", especially given that "buying a domain name for a side project that never goes anywhere" is such a universal experience.

I think both things can be true though. It can be true that these tools are definitely a step up from traditional IDE-style tooling, while also being true that they are not nearly as good as some would have you believe. I appreciate the insight, thanks for replying.

[0]: https://www.anthropic.com/engineering/building-c-compiler

There's an odd trend with these sorts of posts where the author claims to have had some transformative change in their workflow brought upon by LLM coding tools, but also seemingly has nothing to show for it. To me, using the most recent ChatGPT Codex (5.3 on "Extra High" reasoning), it's incredibly obvious that while these tools are surprisingly good at doing repetitive or locally-scoped tasks, they immediately fall apart when faced with the types of things that are actually difficult in software development and require non-trivial amounts of guidance and hand-holding to get things right. This can still be useful, but is a far cry from what seems to be the online discourse right now.

As a real world example, I was told to evaluate Claude Code and ChatGPT codex at my current job since my boss had heard about them and wanted to know what it would mean for our operations. Our main environment is a C# and Typescript monorepo with 2 products being developed, and even with a pretty extensive test suite and a nearly 100 line "AGENTS.md" file, all models I tried basically fail or try to shortcut nearly every task I give it, even when using "plan mode" to give it time to come up with a plan before starting. To be fair, I was able to get it to work pretty well after giving it extremely detailed instructions and monitoring the "thinking" output and stopping it when I see something wrong there to correct it, but at that point I felt silly for spending all that effort just driving the bot instead of doing it myself.

It almost feels like this is some "open secret" which we're all pretending isn't the case too, since if it were really as good as a lot of people are saying there should be a massive increase in the number of high quality projects/products being developed. I don't mean to sound dismissive, but I really do feel like I'm going crazy here.

I'm becoming concerned with the rate at which major software systems seem to be failing as of late. For context, last year I only logged four outages that actually disrupted my work; this quarter alone I'm already on my fourth, all within the past few weeks. This is, of course, just an anecdote and not evidence of any wider trend (not to mention that I might not have even logged everything last year), but it was enough to nudge me into writing this today (helped by the fact that I suddenly had some downtime). Keep in mind, this isn't necessarily specific to this outage, just something that's been on my mind enough to warrant writing about it.

It feels like resiliency is becoming a bit of a lost art in networked software. I've spent a good chunk of this year chasing down intermittent failures at work, and I really underestimated how much work goes into shrinking the "blast radius", so to speak, of any bug or outage. Even though we mostly run a monolith, we still depend on a bunch of external pieces like daemons, databases, Redis, S3, monitoring, and third-party integrations, and we generally assume that these things are present and working in most places, which wasn't always the case. My response was to better document the failure conditions, and once I did, realize that there was many more than we initially thought. Since then we've done things like: move some things to a VPS instead of cloud services, automate deployment more than we already had, greatly improve the test suite and docs to include these newly considered failure conditions, and generally cut down on moving parts. It was a ton of effort, but the payoff has finally shown up: our records show fewer surprises which means fewer distractions and a much calmer system overall. Without that unglamorous work, things would've only grown more fragile as complexity crept in. And I worry that, more broadly, we're slowly un-learning how to build systems that stay up even when the inevitable bug or failure shows up.

For completeness, here are the outages that prompted this: the AWS us-east-1 outage in October (took down the Lightspeed R series API), the Azure Front Door outage (prevented Playwright from downloading browsers for tests), today’s Cloudflare outage (took down Lightspeed’s website, which some of our clients rely on), and the Github outage affecting basically everyone who uses it as their git host.

Yep, this sums it up perfectly for me. I tend to stay away from the extra stuff since the quality is hit or miss (more often hit than miss to be fair), but really there’s something special about having something like it available. I think as a freely available package Nextcloud is immensely valuable to me. I never say anything bad about it without mentioning that in the same breath nowadays.

That sounds really promising, maybe my family would be better suited to something like that.

I will say though, Nextcloud is almost painless when it comes to management. I’ve had one or two issues in the past, but their “all in one” docker setup is pretty solid, I think. It’s what I’ve been using for the last year or so.

I use my Nextcloud as a general file storage thing, I just emphasized the photo aspect because that’s my family’s main use case.

I have heard of Immich though, perhaps I owe it an honest try someday.

Nextcloud is something I have a somewhat love-hate relationship with. On one hand, I've used Nextcloud for ~7 years to backup and provide access to all of my family's photos. We can look at our family pictures and memories from any computer, and it's all private and runs mostly without any headaches.

On the other hand, Nextcloud is so far from being something like Google Docs, and I would never recommend it as a general replacement to someone who can't tolerate "jank", for lack of a better word. There are so many small papercuts you'll notice when using it as a power user. Right off the top of my head, uploading large files is finicky, and no amount of web server config tinkering gets it to always work; thumbnail loading is always spotty, and it's significantly slower than it needs to be (I'm talking orders of magnitude).

With all that said, I'm so grateful for Nextcloud since I don't have a replacement, and I would prefer not having all our baby and vacation pictures feeding some big corporation's AI. We really ought to have a safe, private place to store files in 2025 that the average person can wrap their head around. I only wish my family took better advantage of it, since I'm essentially providing them with unlimited storage.

There's some truth to this too honestly. At $JOB we prototyped one of our projects in Rust to evaluate the language for use, and only started using Docker once we chose to move to .NET, since the Rust deployment story was so seamless.

Yeah that's becoming increasingly true. I guess it really depends on what your setup is.

There's another idea too, that docker is essentially a userspace service manager. It makes things like sandboxing, logging, restarting, etc the same everywhere, which makes having that multi-line build script more valuable.

In a sense it's just the "worse is better" solution[0], where instead of applying the good practices (sandboxing, isolation, good packaging conventions, etc) which leads to those benefits, you just wrap everything in a VM/service manager/packaging format which gives it to you anyway. I don't think it's inherently good or bad, although I understand why it leaves a bad taste in people's mouths.

[0]: https://en.wikipedia.org/wiki/Worse_is_better

This is a really nice insight. I think years of linux have kind of numbed me to this. I've spent so much time on systems which use systemd now that going back to an Alpine Linux box always takes me a second to adjust, even though I know more or less how to do everything on there. I think docker's done a lot to help with that though since the interface is the same everywhere. A typical setup for me now is to have the web server running on the host and everything else behind docker, since that gives me the benefit of using the OS's configuration and security updates for everything exposed to the outside world (firewalls, etc).

Another thing about packaging. I've started noticing myself subconsciously adding even a trivial Dockerfile for most of my projects now just in case I want to run it later and not hassle with installing anything. That way it gives me a "known working" copy which I can more or less rely on to run if I need to. It took a while for me to get to that point though

That's really interesting, I might actually use that for mine too. Thanks for sharing.

It has downsides and risks involved, for sure. I think the security part is perhaps a bit overblown, though. In any environment, the developers either care about staying on top of security or they don't. In my experience, a dev team that skips proper security diligence when using Docker likely wouldn't handle it well outside of Docker either. The number of boxes out there running some old version of Debian that hasn't been patched in the last decade is probably higher than any of us would like.

Although I'm sure many people just do it because they believe (falsely) that it's a silver bullet, I definitely wouldn't call it part of a "tooling fetish". I think it's a reasonable choice much more often than the microservice architecture is.

I think the "local maximum" we've gotten stuck at for application hosting is having a docker container as the canonical environment/deliverable, and injecting secrets when needed. That makes it easy to run and test locally, but still provides most of the benefits I think (infrastructure-as-code setups, reproducibility, etc). Serverless goes a little too far for most applications (in my opinion), but I have to admit some apps work really well under that model. There's a nearly endless number of simple/trivial utilities which wouldn't really gain anything from having their own infrastructure and would work just fine in a shared or on-demand hosting environment, and a massively scaled stateless service would thrive under a serverless environment much more than it would on a traditional server.

That's not to say that I think serverless is somehow only for simple or trivial use cases though, only that there's an impedance mismatch between the "classic web app" model, and what these platforms provide.

I read it again and understand what you mean. I apologize for commenting like that so quickly, I was on my phone and typed that comment out before I really had time to digest the contents.

EDIT: I’m leaving the comment up so the replies make sense, but I completely missed the point here. That’s what I get for writing dismissive hacker news comments on my lunch break!

I find it kind of hard to take this seriously since the JS snippet has a glaringly obvious syntax error and two glaringly obvious bugs which demonstrate that the author didn’t really think too hard about the point they’re trying to make.

I understand the point they’re trying to make, that being that rust forces you to explicitly deal with the complexity of the problem rather than implicitly. It’s just that they conveniently ignore that the JavaScript version requires the programmer to understand things like how async await works, iterators (which they use incorrectly), string interpolation, etc. Just using typescript type annotations alone already gives the js version nearly all the explicitness of rust.

No kidding. I work with an API at my job that does the following:

1. Instead of omitting optional values or at least setting them to null, optional values are set to an empty string when not present (This is including string fields where an empty string would be valid).

2. Lists are represented in such a way that an empty string means an empty list, a list with one element is simply the element, and only lists with more than one element actually use JSON arrays. For example, to represent a list of points ({ x: number, y: number }):

    // Empty array
    "points": ""
   
    // Single element
    "points": { x: 7, y: 28 }

    // 2 or more elements
    "points": [{ x: 7, y: 28 }, { x: 12, y: 4 }]

3. Everything is stored in a string. The number 5? “5”. A Boolean? “true” or “false”.

What’s funny is I was able to use serde to create wrapper types for each of these so these atrocities were abstracted away. For example, those arrays I described are simply Vec<T> in the actual types with an annotation using #[serde_as(as = “CursedArray<T>”)][0]. Likewise something similar for the string encoded types as well.

[0]: https://docs.rs/serde_with/3.12.0/serde_with/guide/serde_as/...

No he did say he doesn’t want rust in Linux at all. Now I understand that he didn’t say “I won’t allow rust to be in Linux”, which is a useful distinction to make. But let’s not pretend like he didn’t say “rust shouldn’t be in Linux” at all.

https://lwn.net/ml/all/20250204052916.GA28741@lst.de/

It’s important to note that it’s not a matter of effort for Firefox. They’ve decided that the it’s not something they want to implement[1]. The reasoning is that they think it allows low enough level access to potentially mess with devices who weren’t made to be resilient to malicious input, and didn’t like that the proposed method of allowing web Bluetooth is based on a default allow policy with a blocklist, which means as new Bluetooth device vulnerabilities are discovered, this blocklist has to be maintained.

[1]: https://mozilla.github.io/standards-positions/#web-bluetooth

That seems like a good litmus test question since it has a single correct answer, but a lot of potentially incorrect ones which sound like they might be right (North America has a lot of Hamiltons after all).

They just mean service managers like SystemD and OpenRC prefer to handle daemonizing themselves, and thus would prefer that your program stay in the foreground and let them put it in the background.

From OpenRC’s docs[0]:

  Daemons must not fork. Any daemon that you would like to have monitored by supervise-daemon must not fork. Instead, it must stay in the foreground. If the daemon forks, the supervisor will be unable to monitor it.

  If the daemon can be configured to not fork, this should be done in the daemon's configuration file, or by adding a command line option that instructs it not to fork to the command_args_foreground variable shown below.

The “undesired” or “controversial” part is whether programs should do it themselves or not.

[0]: https://github.com/OpenRC/openrc/blob/master/supervise-daemo...

My local university used to teach MIPS, and as of some years ago they’ve switched to RISC-V.

The final assignment at the time I took it was to write a program which compiles a subset of ARM machine code into RISC-V machine code, which was a challenging but so rewarding thing for a younger me to cut my teeth on.

It was a surprisingly modern class too. The in-class material was learning about pipelining, instruction/memory latency, and general CPU concepts, while the assignment and lab material was focused on writing RISC-V assembly and implementing more and more complex programs.

Most likely this. I vividly remember reading this the first time I had heard about STUXNET.

https://www.quora.com/What-is-the-most-sophisticated-piece-o...

edit: someone beat me to it, I just didn't notice since it wasn't a direct link: https://news.ycombinator.com/item?id=38518286

Nothing is unrepresentable, if I’m not mistaken.

https://en.m.wikipedia.org/wiki/Structured_program_theorem

Rather, I think the trade off was more in the realm of “aggressively optimize for what the web does well”.

With that being said, I do wish it was better suited for general purpose computation.

Supposedly, usr was supposed to be “user”[0] but was switched after the Unix guys needed more disk space and split the file system into the / and /usr mount points.

Then /home was made because /usr was filled up with other things.

[0]: Rob Landley of busybox fame recalled on the busybox mailing lists some ten years ago http://lists.busybox.net/pipermail/busybox/2010-December/074...

I agree with the sentiment, but does Swift actually see any usage outside of Apple’s own hardware? I think Swift’s reliance on such an optimization is justified since the hardware this optimization is applied to is the main target.

While Swift’s approach may be slower in theory, is it actually slower in practice? Just a thought.