cyco130

I've heard of it, of course! And of course they're years ahead of my little hobby project.

But there's an important difference: They run on the browser via WebAssembly, the project is in Rust. Sfotty Pie is pure TypeScript, so, hopefully, easier to hack for a greater number of people. Also harder to make performant but why do we have all this CPU power if not to emulate 1.79 MHz machines using high-level languages :)

I can see where the arguments for React's alternatives like Preact, Vue, Svelte, Solid, etc. come from. All of them are better than React at least in one aspect and React's dominance is mostly due to inertia: Developers (and now LLMs) know it better and the ecosystem is richer.

But having built websites and apps since before jQuery times, I strongly disagree with manual DOM manipulation as an alternative. Declarative, component-based approach won for a reason. These frameworks allow you to tell how the UI should look based on the state and manages the transition (either via virtual DOM diffing or fine-grained reactivity) for you. DOM manipulation requires you to write some code for every single state transition (instead of every _state_). And, in practice, it becomes unmanageable very fast, and you give up, and start writing code like `element.innerHTML = ...`, causing problems with focus and event management. It's fine for small widgets, even enjoyable, but only until you need to manage a complex UI. Then, you end up with a mess of code that is hard to maintain and debug.

I know some still feel web is not the right platform for building complex UIs but that battle was lost more than two decades ago. Web is good. It comes with accessibility features (like zooming) and works everywhere. As someone with age-related farsightedness, I hate native apps that don't allow me to zoom in with a passion (which is, almost all of them). Of course I hate websites that don't allow me to zoom even more because they had to go out of their way to disable a basic browser feature. But getting decent accessibility is harder with native apps. You basically have to build everything yourself. Web gets you 90% there for free.

React might not be the best out there and might be, one day, replaced by one of the competitors or something new. But declarative, component-based UI development is not going anywhere.

And this is Railway, a big enough name to top the HN main page and presumably find someone from Google to intervene at some point. I would have zero recourse if it was some little product that I built.

tanh is a very pleasant sounding overdrive function for audio, for example.

One neat trick for TypeScript branded types is to use { "~brand": "SOME BRAND" } instead of { __brand: "SOME BRAND" }. __brand shows up at the top of the autocomplete keys where "~brand" shows at the bottom.

Axios has maxContentLength and maxBodyLength options. I would probably go with undici nowadays though (it also has maxResponseSize).

I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.

Thanks for the articles, great sources.

> Current literature does not distinguish between head voice and falsetto.

Hmm, are you sure about this? I thought chest voice and head voice were understood to be a single register called the modal register. And falsetto was fundamentally different.

Anecdotal evidence from my own singing at 20 compared to 40 seems to point to the opposite.

It is indeed part of the standard. It says "Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared"[1] which doesn't allow implementations to reorder fields, at least according to my understanding.

[1] https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf section 6.7.3.2, paragraph 17.

If history is any indication, it would only mean more passengers in the plane.

Natural languages are much more complex.

Complex for humans: I can learn a new programming language in an afternoon and be reasonably productive in it within a week or two. I wish I could say the same for natural languages.

Complex for computers: We’ve had good compilers since the 50s. Satisfactory language models are less than five years old.

My very first open source project[1] aimed to solve the same problem. Nice to see it still has quite a few weekly downloads.

[1] https://sourceforge.net/projects/bin2c/

Not the gp but I can't live without co/ci/br now.

I celebrated my 25th year on stage almost three years ago. Mostly playing covers in bars.

There was a time when we were hoping to “make it” and we did release an album but it wasn’t very successful, of course. That band broke up a few years later but I kept going with different bands.

I can’t do it every week anymore, let alone every night. It’s very physically demanding, so once a month is plenty in my age.

But it’s still fun. A lot of fun. I can’t imagine ever stopping it until I can’t physically do it. It’s part of who I am. Long live rock’n roll \m/

I've watched the SSA-related parts of these lectures and, despite the low video quality, I've found the quality of the content to be very high. Lecture notes can be found here: https://nptel.ac.in/courses/106108052

These instructions were not intentionally designed and put in there in secret. They're simply an unintended consequence of the "don't care" states of the instruction decoding logic.

The decoder is the part of the CPU that maps instruction opcodes to a set of control signals. For example "LDA absolute" (opcode 0xA5) would activate the "put the result in A" signal on its last cycle while "LDX absolute" (opcode 0xA6) would activate the "put the result in X" signal. The undocumented "LAX absolute" (opcode 0xA7) simply activates both because of the decoder logic's internal wiring, causing the result to be put in both registers. For other undocumented opcodes, the "do both of these things" logic is less recognizable but it's always there. Specifically disallowing these illegal states (to make them NOPs or raise an exception, for instance) would require more die space and push the price up.

See here[1] for example to get a sense of how opcode bits form certain patterns when arranged in a specific way.

  [1] https://www.nesdev.org/wiki/CPU_unofficial_opcodes

That’s where link-time optimization enters the picture. It’s expensive but tolerable for production builds of small projects and feasible for mid-sized ones.

It would but it's harder to trigger. Here, it's not safe because they're public functions and the standard would require `add_v1 != add_v2` (I think).

If you declare them as static, it eliminates the functions and the calls completely: https://aoco.compiler-explorer.com/z/soPqe7eYx

I'm sure it could also perform definition merging like you suggest but I can't think of a way of triggering it at the moment without also triggering their complete elision.

First time I see it being a net positive that someone didn't know about Vite: Bun wouldn't exist otherwise.

What a respectfully and humbly written comparison page. Ditto for their Supabase comparison. I can't rate the objectivity since I know very little about TrailBase but they got my attention now. It brings me such joy to see such a writeup in a world where humility is perceived as weakness. Kudos.

As a person who knows next to nothing about how the brain or the genes that configure it work, I tend to think of this in terms of 80s video games like River Raid. The level data for these games, if stored naively, would fill the computer's available memory many times over. So they just store a pseudorandom number generator seed along with a few other parameters. Coupled with a few rules to make the level playable, it can generate a seemingly impossible number of levels with very little stored data.

Maybe the genes just encode a few crucial rules and the rest just emerge from that.

Oh, and I know even less about how the universe works. But I tend to think of it in the same terms: Emergent phenomena stemming from simple rules à la Game of Life.

I love how they didn't come up with a joke and just run with it lazily. They added lots of additional details to make it funnier and more realistic.

No mention of INTERCAL!

It's all about context, isn't it? "Humans vs. animals" is an important distinction to make in some contexts and useless in others. Insisting on the fact that humans are also animals if we're talking about, say, "language in humans vs. animals" is unproductive. It just makes discussions harder by forcing everyone to add "_non-human_ animals" to every mention. But if we're talking about, say, cellular biology, it's unproductive to force everyone to write "human and animal cells" instead of just "animal cells".

Similarly, distinguishing between transpilers and compilers might be important in some contexts and useless in others. Transpilers are source-to-source compilers, a subset of compilers. Whether it matters depends on the context.

LLMs are not people. We can’t blame them.

Internationalization and localization are extremely hard problems. I know because I worked as technical translator for sone years.

But, in C++ land, I had very good success with Qt and its translation system in one of my open source projects.

That was 2010’ish, there are probably better ways now bit I don’t know.

In fewer words: It was already a fairly flexible and customizable tool. But then came a time when a client requested faster horses we could show them our car instead and they recognized the value. (And occasionally, when _they_ requested a car instead of our faster horses, _we_ recognized the value and implemented it).

Absolutely. When we started growing (I was employee #3, we were about 20 people when I left), we didn't use our own product for our own needs. It wasn't designed for a tiny startup, it would be like building a sand castle with a bulldozer.

But we started as a "boutique" company that implemented everything requested by our then small number of clients (mainly out of desperation, we were self-funded and we didn't have much leeway, we needed those clients). It was as flexible as it gets before the LLM times.

But after a while, you start noticing patterns, an understanding of what works and what doesn't in a given context. Our later customers rarely requested a feature that we didn't already have or we didn't have a better alternative of. It's not like we had a one-size-fits-all solution that we forced on everyone. We offered a few alternative ways of working that fit different contexts (hiring an airline pilot is a very different context than hiring a flight attendant). And in time, this know-how started to become our most important value proposition.

At some point we even started joking about leaving the software business and offering recruitment consulting services instead.