ncruces

The most non boring thing you can say about it is that it's terrible for ignoring most of what we've learned in the past couple decades of programming language design.

That generates plenty of excitement.

I suspect bagpipes may be the worst wind instrument to learn in this regard, at least if the goal is to train circular breathing?

Right. I am doing a standard library replacement, and forgot I needed to compile freestanding. Oops. My bad.

So `str` and `mem` are reserved. But then so are `to` and `is` (by <ctype.h>). Just forget about having a function named `is_valid_user`.

And so are `mtx_`, `cnd_`, `thrd_`, `atomic_`, `memory_`...

Which is why... everything in C is UB.

Actions, as I get use them for free really seem irreplaceable.

See, I only have one project where this actually matters (and help maintain another), but: I get to test on mac and Windows, both ARM and x64, for free.

Then, with a one line import, I can use Linux+QEMU to test a bunch of other architectures.

Adding a couple other deps, I can have VMs to test: FreeBSD, OpenBSD, NetBSD, illumos, Solaris… the list goes on.

And thanks to other providers I now also get RISC-V, IBM Z and Power runners for free.

So, yeah, for the other projects, I could have CI on a self-hosted Forgejo instance. I could also run tests on my dev machine before commiting and get 95% or the same benefit.

The value in CI is that it can run tests that are inconvenient to run locally.

From the point of view of "small open source project" I honestly have no idea what I would move to.

I happen to make, I think, $5/month in donations (thank you). According to GitHub's numbers, they offer me about $25/month in the product everyone likes to hate: Actions.

I could certainly cut costs if I had to (half the cost, certainly not half the value, is mac runners), but my projects are definitely in a better shape for having this.

So: where do I get a better deal?

I actually encountered it a couple weeks ago.

Can you spot the infinite loop in this function?

  char* strcpy(char* restrict d, const char* restrict s) {
    stpcpy(d, s);
    return d;
  }

I'll help. A call to `stpcpy` that ignores the return value can be swapped with a call to the (more likely to be optimized) `strcpy`. Since that's infinite recursion, and there is no forward progress, it's undefined behavior and anything goes.

This isn't just theory, it actually broke things in practice for me.

This.

The APK number looks impressive if you don't know some files are uncompressed on purpose: https://developer.android.com/tools/zipalign

There's also no mention that this likely breaks signatures? https://developer.android.com/tools/apksigner

The weird thing is that they say they worked on Signal ... so, what's going on?

I don't know that there was an inflection point. I know that, over the past year, they definitely became useful to me as more than auto complete.

My most recent pet project is a transpiler from Wasm to Go, and I find it incredibly impressive that recent models (I've used Sonnet, Opus and Gemini, far more successfully than GPT), they're able to just pick up the project and work at all these levels:

- Go code that implements the transpiler (parsing Wasm, building an AST)

- Go code that gets generated by serializing the AST to a .go file

- Go code that manipulates the AST (to optimize it), and its effect on the generated code

- Go code that's grafted to the generated code (to implement more advanced opcodes) and how to interact with it from the AST

- C code that gets compiled to Wasm, then translated to Go, then called by Go

- Go code that gets called by this C code to implement a C stdlib

- WAT and WAST files that are used to implement the Wasm spec tests

I find this impressive because I have to think hard about all these levels, and I feel many programmers would have a problem with this.

And it's very often way easier for me to just write: "I want to generate this code, build me the AST that does it", than go "count parenthesis" in the Go code (I do have some LISP experience; it's still easier).

Feel free to scrutinize/criticize the code. Not vibe coded, but plenty of GenAI help.

https://github.com/ncruces/wasm2go

Because that's 364 days.

You think they'll ~all merrily move to the new version?

Haven't tried. But there are "IDEs" (Unity) that are really hostile to the idea that your project directory is not a fast local disk that they can both fill with garbage and use fsnotify on everything.

Do you mean local checkouts? There's a similar workflow with at least mercurial? Dunno about jujutsu.

There are mercurial and jujutsu frontends now.

The mono repo that holds most source code (pronounced google-tree?) It's referenced in the OP.

That's good to know, thanks!

It makes this quite realistic, which might mean a good/great OPFS VFS (like Roy's) actually starts to make sense.

https://github.com/rhashimoto/wa-sqlite/discussions

Unfortunately I'm not knowledgeable enough on the browser side of things to advance something like that, and have quite a bit on my plate already. But if there's interest I can help demystify the SQLite/VFS side of things. Feel free to (e.g.) open a GitHub discussion on my repo to track this.

The thing I most love about Cider-V is that moving between it and (often remote) VSCode when working outside google3 becomes mostly painless.

Thanks! Yeah, I guess on the web it would always manifest as load time.

But order of magnitude, with everything cached, on a decent laptop/desktop, is it a few seconds, or a minute?

Because what I get from testing in CI is every test takes a minute.

How's the performance? My Wasm-under-Wasm tests became slow since I transitioned to the wasm2go transpiler, but I wonder if that's an artifact of repeated slow compilation (rather than execution) of tests.

That name change…

They created other kinds of despair.

A year ago I would've told my boss “can't be done” about my work today. I'd tell him to get me the right person to talk to (our partner, not an alien) who could give me some insight into what the hell I'm supposed to be doing to consume their API. Or to at least explain why it is that this can't be done.

Nowadays, I spent a couple of weeks reverse engineering their terrible ideas. Yeah, it worked. But it's a complete waste of my time, and tokens, energy, chips and RAM. And worst of all, it will lead to a terrible design.

That will work, but will eventually colapse under its own weight, as we use our increased power to increase our sloppiness and take it a little further. Because we can manage it. For now.

I don't disagree, but whoever never put math they don't fully understand in their code gets to throw the first stone.

I've reached solutions by trial and error too, and tried to rationalize them later, quite a few times. And it's easier to rationalize a working solution, however adversarial you claim to be in your rationalization.

I don't see using gen AI for the (not so) “brute force” exploration of the solution space as that different from trial and error and post fact rationalization.

Adding support for the threads/atomics proposal to my Wasm to Go transpiler: https://github.com/ncruces/wasm2go

Since I started it a couple of months ago, it's been used by me to transpile SQLite to Go, and by some other folks to transpile other C, C++, Zig and even Perl libraries to Go.

Also, one thing the numbers they published show is that the bits that are growing 10x YoY (and which they expect to get “worse”) are all the things that you get “unlimited” mileage off (even if you're a paying customer): repos, commits, PRs.

Things that have “usage based billing” (like action monites) grow closer to 2x YoY.

When there's a dollar amount attached, people don't 10x, because it's not worth it. They splurge when it's cheap, and unlimited.

Or things didn't change much at all except Microsoft forced them to be more honest in their reporting.

See, I can just as easily make up a story that explains the chart.

Sure.

Since they're a for profit entity, they'll do whatever they think offers the best cost/benefit.

That's fair, but forking the FOSS version is also an adequate response.

Before, meetings (aka. coordination) bottlenecked the coding.

Even if coding was solved, meetings could still be the bottleneck.

You think spending more time on meetings is going to solve anything?

Do you always run with those sanitizers in place?

Just this week I've had a C compilers silently delete me an entire function call because of UB (infinite loop without side effects). Took me a day to figure out. So that's a problem for me.

I don't think I've ever had an hard to debug issue in Go because of signed/unsigned wrap around. Particularly a memory issue.

If anything, and there I guess I agree with the article, I wish Go had implicit conversions to wider types: to make the problematic ones stand out.

I guess the reason it doesn't is that they're different named types, which would be a problem when you create a named type for the purpose of forcing explicit type conversions. But maybe the default ones could implicitly implement a numeric tower, where exact conversions can be implicit.

It's not really signed vs unsigned that's the issue, IMO. It's (mostly, in C) undefined behavior and implicit conversions?

I'm not sure Go is saner just because len is an int. Well, maybe, depending on how you look at it. Defining len to be signed int, means the largest valid len is half your address space, which also means half of all possible indexes are always invalid; which makes some things easier.

But it's really that integer arithmetic is not undefined behavior regardless of signedness, that bounds are checked, and that even indexing your slice with an int64 on a 32-bit CPU does the full correct bounds check. In fact, you can use any integer type as an index.

Given all of the above, indexing with a uint or an int is actually indiferent. In that case, the bound check is a single unsigned <len compare (despite the fact that len is signed).

What's really painful, is trying to handle a full 32-bit address space with 32-bit addresses and sizes, like in Wasm; you need 33-bit math. So in a sense, limiting sizes to 31-bit (signed) does help. But at the language level, IMO, the rest matters more.

I think you can just pretend to be a PWA, no need for code changes.

You may need an unused service worker, or not, I don't remember.

This just means your site looks like an Android app (but still needs net, etc).