Then, a user (like me) tries writing something like

  package main
  
  func main() {
    register := 42
    println(register)
  }

  /tmp/solod_build3904763637/main.c: In function 'main':
  /tmp/solod_build3904763637/main.c:6:21: error: expected identifier or '(' before '=' token
      6 |     so_int register = 42;
        |                     ^
  /tmp/solod_build3904763637/main.c:7:29: error: expected expression before 'register'
      7 |     so_println("%" PRIdINT, register);
        |                             ^~~~~~~~ (exit status 1)

The next bad thing is when you step on your own toes and see that the new names you invented, like `so_int` or `so_println`, will inevitably pollute the global namespace. We'll either cross our fingers and hope that no one will create a variable named `so_int`, or we'll need to add all our new kind-of-reserved words to our already big list of exceptions.

I'm sure there are multiple levels of complexity beyond this.

Not trying to say that seeing a bunch of new translators from language A to language B is bad: not at all! It really seems that this is one of the popular usages of the agents, and a rewarding one. But doing it without hidden bugs is kinda hard.

Which while some of the design decisions might be debatable, they actually knew what C is all about, informed by their own experience with what worked in C, Alef and Limbo, across UNIX, Plan 9 and Inferno.

I was a little worried at the start because nobody would normally consider Go for games, but I did a bunch of tests and found it's just no big deal.

(I'm focused on game play and not interested in pushing hardware to its limits.)

That hadn't really occurred to me before.

Wut?

Also, how do you preserve garbage collector semantics without garbage collector?

a) none

b) http 1.1

c) ... forget about more

Maybe you need rar support ... O well, ... And then you always enter the world where you need to start linking external libs, and then your mixing not just the base language and the transcompile but also whatever interface for calling those external libs.

Ironically, with LLMs being around, your often better to just have it write whatever is missing. Until you find out then, that the language misses some feature.

O great, you needed crypto support. Ok let the LLM write it for you, its only 100x slower then whatever was written years ago and had tons of enhancements and edge cases fixed.

At that point, you can just tell a LLM to write in C from the start, and be done with it. lol.

Transcompile languages have always had tons of issues, and there is a reason why non became popular. Haxe comes to mind. How many years this exist and barely anybody knows it. Because your often just better writing in the original language and fixing the issues, or picking a better fitting language for your project.

Wish something like this existed instead i am stuck with flutter and react native on Mobile.

When will a time come when i can use some functional languages like Haskell or a plain boring language like Go for making apps with OTA ability for mobiles.

As vibe coding takes over, app store approval will become slowerer and OTA is really great when you need to make quick changes!

You can OTA each day and do base app release to store once each week.

i think this maybe the space where very little work is being done.

eventually, they fell back to rust.

there's a lesson here: subset languages are fine for experiments and small projects, but they're rarely the right choice for production software.

...and C still can't be replaced. it's still the language of choice for mission-critical systems and low-level problem solving.

I don't get it at all. Green threads are cool, but again, it's easy to write unsafe concurrent code in Go, so why would I choose it over e.g. Rust (where its hard to write unsafe concurrent code) or C++ (which gives me more control)?