Translating a language into a different language is a popular thing to do these days, but still not a very easy one. I feel it's like peeling an infinite onion of misery. First, you write a parser of your source language, figure out the translation of the instructions, and emit the code in the target language, and you're very happy when your translated Hello world compiles.
Then, a user (like me) tries writing something like
package main
func main() {
register := 42
println(register)
}
well, oops.
/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)
OK, now you grab the list of reserved words of the target language, which is not always an easy thing to do, and rename type names and variables as needed.
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.
> 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.
To be fair, it's not like it's a completely foreign concept; consider C's categories of reserved identifiers (e.g., no double underscores or underscore followed by a capital letter) as well as the identifier ugilification that needs to be done in the C/C++ stdlibs to avoid collisions with user code.
In that vein, the transpiler could pick some prefix which users are highly unlikely to use and document that said prefix is off limits (e.g., "You can't use identifiers starting with `_solod_id_`") or maybe it could use C's reserved IDs (idk if such a transpiler would count as an "implementation" as far as the C standard is concerned).
That seems like a brittle approach to transpilation. A transpiler should translate all of the language's semantics, including resolving identifiers as symbols, and then choose legal names for them in the target language. Also, there is so much more to a language than its surface syntax.
I've never designed a transpiler (I'm not a programmer), but surely the correct approach is to transform the source code into its type-checked AST, and then translate to the target language from there?
> A transpiler should translate all of the language's semantics, including resolving identifiers as symbols, and then choose legal names for them in the target language.
Yes, it should; but it also makes things much more difficult. This specific transpiler indeed builds an AST, but does not care about identifiers, just emitting them as is [1] (I hope I found the correct place in the code).
I'm really sorry to be harsh but if you don't use programming languages and have never written a transpiler, why should anyone read your comment?
You critique the approach as brittle and yet the approach you propose doesn't solve the thorny problem gp described of a growing ball of reserved keywords.
> resolving identifiers as symbols, and then choose legal names for them in the target language
The responsibility for avoiding collision with the target language is in the transpiler; it should mangle identifiers appropriately to ensure you can't accidentally hit a keyword in the target language.
A good test is to try to port significant from c++ to plain and simple C using "AI". Maybe it can retain some of the semantics for the original code.
There is a more brutal option: AI could help write a c++ to plain and simple C transpiler... then we would lose the semantics of the original program, but free ourself from the very few toxic and real-life c++ compilers out there.
Oof that's not a good look. You can trivially avoid this by just prefixing all variable names with a salt. By the way this (or a variant thereof) is called "avoiding unwanted name capture" if you want to sound all sophisticated :)
Go is a better C already, designed by C authors themselves, with other UNIX key figures.
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.
It’s not. Garbage collection made sure of it. I believe everyone agrees that a "better C" has to have manual memory management. Most even rule out Go as a systems language because of GC.
Of course, I’m pretty sure Go is much better than C at some problems. But there’s no way in hell it supersedes it.
The fact that people care a lot about Unix clones is significant, though. nine_k could have been more effective in arguing the point, but it seems like a strong point to argue. Do you think you Go is flexible enough to write a Unix clone with performance equivalent to a C-unix? If so, why has it not been done?
Besides the sibling Biscuit, maybe because no one bothered to do it?
As simple as that, not everyone of us is a Linus.
I should also point out that if you are using a Mac, changes are its iBoot Safe C might already been replaced by Embedded Swift, a GC enabled systems language.
Chapter 5 of The Garbage Collection Handbook, or A Unified Theory of Garbage Collection paper for the incoming replies related to RC.
People care about UNIX clones because they are lazy, UNIX has the source code available, and an existing ecosystem that they don't want to replicate, so it always ends up being yet another clone, thus throwing away all the possible innovations.
We see this happening even with Haiku, Genode, Redox OS, or Windows now shipping alongside Linux on top of Hyper-V.
Unless one is an Apple or Google, with the money and will power to push something out the door, using Objective-C, Swift, Java, Kotlin, with plain C and C++ standard libraries, and even then people will bend backwards to put UNIX into those systems, even when the platform owners went to great effort to hide it under the official userspace APIs.
> As simple as that, not everyone of us is a Linus.
I’m pretty sure Linus could not have written Linux today. Too much hardware to support, too many drivers to write, before it’s remotely useful. Well, except perhaps on some specialised servers.
Yes, not everyone is Linus. Otherwise we’d be using GNU Hurd. But he also came at the right time.
> People care about UNIX clones because they are lazy, UNIX has the source code available, and an existing ecosystem that they don't want to replicate, so it always ends up being yet another clone, thus throwing away all the possible innovations.
Which is a real shame, because people thinking outside the UNIX clone box have come up with some incredibly innovative operating systems like Plan 9 and OS/400.
Because of the 30 million lines problem. Writing a serious OS kernel nowadays is flat out impossible: the hardware is just too diverse, it requires too many drivers. The best we can do right now is just add to an existing kernel. Kind of a vicious cycle: the more drivers we accrete to any given OS, the more impossible it is to get feature parity from the ground up.
The only solution to that is for hardware vendor to standardise their interfaces (at the hardware level), and actually give us the fucking manual. And I mean the real manual, the one that tells us voltages and pins and baud rates and the actual wire formats required to talk to it. A proprietary Windows driver is not a manual, even if it comes with an SDK. Heck I’m not even sure the source code of a Linux driver would count.
But they won’t do it. They just won’t. So unless we do something drastic like forbidding hardware vendor to ever ship software (to force them to standardise and document their actual interfaces), writing another OS that can actually compete with the existing ones will remain flat out impossible.
> Go's runtime is written in Go. The whole compiler toolchain, GC, compiler, linker, Assembler, is written in Go.
There's some nuance to this. The runtime code uses specific compiler support and restrictions that are not ordinary Go - possible (or even done, like this case) ≠ ergonomic. No doubt of course that for the Go project, this is still a win.
I love how language extensions, and subsets are always valid for C and C++, but used as an attack against other languages, as if to prove they are not good enough for a specific use case.
Well, neither are C and C++, as they either have to rely on hand written Assembly code, language extensions, or be gutted down into subsets outside the official language standard.
> Go is not a better C, in the sense that you cannot write an OS with it
Can you even write an OS in pure ISO standard C? I know atomic (https://en.cppreference.com/c/language/atomic) was added in C11, but is that sufficient to write an OS? How do you write a kernel-user space transition in standard C, for example?
The larger runtime makes bootstrapping go for unsupported architectures more laborious than C, but it's not a hard blocker. The function call overhead for inline assembly feels like more of an issue doing close to hw programming. It can be avoided for the runtime, but user go code can't escape it afaik.
Yeah but they were intentionally trying to build a better C++/Java, not a better C. It wasn't even aimed at things that C is good at. It was mostly aimed at writing high performance servers that have to scale really big not only in terms of performance but software complexity, size and contributions. So Go is a better C++ or Java for writing servers according to its creators.
A better C++ is by definition a better C, no one should be using C in 21st century beyond UNIX clones, and embedded devs that are religiously against C++, even all modern C compilers are written in C++ nowadays.
Anything you can think C is better, it isn't ISO C, rather non standard C compiler specific extensions, which can language can also be.
Just do like in K&R C days, use Assembly for what language isn't directly capable of, and it is right there as part of a regular Go toolchain installation.
I wrote C++ for most of my career. And as of late, I found myself avoiding more and more features from it. The STL is mostly trash, not worth the increase in compilation times. Templates are good for containers, but that’s about it. Inheritance and polymorphism are circumstantial enough that I’m not sure they’re worth adding to the language: in the rare cases I do need them, I can always write my v-table by hand.
The more I write C++, the more I find C is not that far from that "much smaller and cleaner language struggling to get out". And I say that fully aware of the many egregious faults still present in C.
There are two features from C++ I would really miss in a big C project: generics (templates), and destructors. But then we can always write a lightweight pre-processor to add those generics and a `defer` statement. Even if it requires a full parser, C parsers are pretty easy to write.
The idea of using a subset of an existing popular language is very wise IMHO. We can (and apparently are) debating the merits of the language runtime, but what a subset gives you is immediate access to a large pile of existing tooling that you'd have to write yourself, eg linters, formatters, lsps, etc. Stuff that is purely source-oriented.
> So is for Go developers who want systems-level control without learning a new language. And for C programmers who like Go's safety, structure, and tooling.
Wut?
Also, how do you preserve garbage collector semantics without garbage collector?
- Everything in the language is statically allocated or stack-allocated. You have to call a malloc / free function to get heap allocated things
- The language is not memory safe (you can't return slices, pointers, or interface types from a function if the thing was created inside the function, unless you used heap allocation)
- Interfaces (the only variable size struct Go has) are implemented by creating a struct of function pointers. Arrays and maps (the non-struct variable size types) are implemented as stack-only and maps are limited to 1024 keys. You can opt into heap-based arrays / maps in the standard library to bypass this.
Been a while since I used go but I remember it being kind of uniquely hard to tell? Like a struct is on the stack, but a *struct is maybe on the heap, depending on escape analysis?
In go you don’t need to care, the GC will take care of allocations on the heap and the runtime will choose when something should go on the stack. That’s the problem: in this other language it’s suicidal to program as if it was the same as Go as you will just make huge mistakes like returning a pointer to a local variable.
In C you explicitly malloc things onto the heap. In go, taking the address of something maybe allocates on the heap, or maybe not if escape analysis can keep it on the stack.
As far as I understand co-routines help don't really help with memory shared across go-routines. They only help in the fact you need to manage spawning and joining threads, making it easier to do stuff in parallel. But they don't provide thread-safety.
edit: I suppose you don't get segfaults or buffer overflows and the sort in go for accessing memory in a parallel context, you get recoverable panics. But that is still not really thread safety in my opinion, it is memory safety.
The "a better C" meme needs to die. It's ill defined. Everyone wants something different. For me, GC disqualifies any language as a better C. Bjarne Stroustrup promoted C++ as a better C. But C++ killed off some of C's killer low-level features like type-punning via unions. Indeed it's only in recent years that low-level memory manipulation, such as std::start_lifetime_as and the implicit lifetime rules were standardised. The whole strict aliasing fiasco made C and C++ permenantly worse. Some people say Zig is a better C, but it is certainly not a minimal language, if that's how you define better. For me a better C would have an abstract model that matched machine-level memory access (i.e. no type-based alias analysis) would be as minimal as C in terms of feature set, would clean up C warts like operator precedence, and would be as deterministic as possible (e.g. deterministic memory layout, including bit fields, would be possible without hacks)...
Everyone agrees C has problems, but there’s no consensus on what those problems are. People build ‘better Cs’ to solve the problems they see in the language, and offer them to the community for the benefit of those who share their tastes.
It’s perfectly fine for you to disagree with them, but it’s also perfectly fine for them to publish their solutions to their problems.
‘A better C’ is a good description for these projects. ‘The better C’ would not be.
John Regehr tried to start an initiative to make what he called Friendly C, removing some of the most blatant C footguns, and even that turned out to be extremely hard to get consensus on: https://blog.regehr.org/archives/1287
It also varies heavily on the kind of static analysis tools you are using in conjunction with your compiler. Some "bad" things about the language are just fine if they can be caught by the static analysis you are using.
It is a major problem with most really old languages, JS is notoriously prone to this kind of "remove the bad bits" thinking when in actuality most of those complaints are non-issues if you run a linter.
What do you think of Ada's representation clauses and Zig's packed structs? Do they give you the syntax and semantics for arrangement (ordering, padding, widths), endianness, and control of bit order that you want?
Also, thank you for an educational comment.
Edit: I forgot to ask about your thoughts on Ada's and Zig's type punning.
How does it deal with pointers if everything is stack based? You can't really return a pointer to something on the stack because it could get overwritten between when you return it and when you access it.
Quoting the FAQ: "So itself has few safeguards other than the default Go type checking. It will panic on out-of-bounds array access, but it won't stop you from returning a dangling pointer or forgetting to free allocated memory. Most memory-related problems can be caught with AddressSanitizer in modern compilers, so I recommend enabling it during development by adding -fsanitize=address to your CFLAGS."
So saying you get the "safety of Go" is a bit of a stretch.
Yeah that's not great. It's easy to be faster than go if you haven't thought about memory management yet. I bet go with GOGC=off is faster than plain go too.
That's undefined behavior in C I thought? You're addressing the memory of a stack frame that already collapsed when it returned. I think it's ok for compilers to either segfault or work like you'd think they would for that example in C.
You can pass pointers to earlier frames in the stack, they're still active, but you can't return a pointer to an expired stack frame.
I think you're basically agreeing with the person you're replying to; they're pointing out that Solod doesn't really provide the "safety of Go" since the translation trivially exposes the user to UB that would not be present in Go.
I doubt that it can. so in addition to C's quirks (which I know about), I have to care about go's quirks and solod's quirks as well? and for what? there's no solod-to-regular-go interop aiui, so just some tooling and the standard library?
I really like this idea. I was reading a post earlier about how Go generics are implemented, and how they're sort of leveraging root GC-types in the "runtime" to avoid the same bloat as monomorphization causes in, say, C++. I wonder how Solod will do that? I guess plain monomorphization? I guess that's fine since C compilers are so speedy.
At first glance looks like stipped C++ with minor differences. For example go have row polimorphism compared to OOP in C++. What else is there that C++ does not have?
This looks silly. It's about a Go subset with no GC and various other restrictions that make it map onto C. But then you have most of the problems of C. It's unclear what the advantages are supposed to be. Rust or Ada seem way preferable, depending on the application area.
I've been using Go and Raylib to make a game lately and I really don't have a problem with garbage collection. It's so fast that it's not having an impact on my frame rate.
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.)
I’ve been considering using Odin and Raylib for this because of its similarities to Go, but using Go itself is appealing. Do you have any good resources for what you’ve learned, or is it an unexplored frontier?
I don't know If I can be very helpful, I'm using gen2brain's binding [1].
I started about a year ago asking the AI very beginner questions about Go and 3d math. I think it did steer me down some wrong path sometimes and of course I did some dumb things myself too. I'm not using Agents, just asking questions about features, then writing the code myself by hand.
I really like the power of the tools and the constraints of the language in Go. It's been fun so far.
It's interesting you would mention Odin because I spend a fair amount of time playing with it as well. It was easy to get started and fun. Fast, easy to iterate. The reason I moved away was not the language itself, but I felt it was too much Ginger Bills baby. Oh, and managing memory is no fun. I want to make game play, not think about allocations :)
It cannot be a better C. You cannot implement exceptions in it using set jump for example, but the biggest problem is memory management. You can't implement your own arena allocator in golang.
I've drastically sped up commercial shipping C code by implementing arena allocators and Go is my daily driver and it's not clear to me why you're making this claim.
Not the OP but I guess what they are saying is that since this language is a subset of go and if you use it as such then an arena allocator cannot be used in the transliterated code.
Maybe it's possible to force the transliteration to use a different allocator and then you could use the one you wrote in C?
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.
Good point! Regarding C being the language of choice for mission-critical systems, probably you want to avoid memory bugs that might result ruining the mission. I understand many projects have large C codebases or interact with other projects in C, but migrating to Rust when possible (like replacing lead pipes as you find them for plastic pipes) sounds like a smart choice to build mission-critical low level systems.
NO
Developers who use a particular language reshape their mental model to fit that language. Go is centered around its runtime. If you switch to C11, do you really need to be thinking about a goroutine scheduler, never mind garbage collection? Even just looking at example code, would a Go developer ever think defer pool.free is necessary? The mental model is completely different.
C++ is like PHP: it used to be a terrible language, and you can still reach for everything terrible if you wish. But during last maybe 10 years, C++ made a lot of effort to become a language with fewer footguns and more safe, high-level tools.
Still I won't start a new project in C++. If I wanted high-level features and zero-cost abstractions, I'd take Rust. If I wanted working really close to hardware, do bit-twiddling and knowing where every byte is allocated, I'd take Zig. If I wanted to write a small piece of code intended to run absolutely everywhere, including old and esoteric architectures, I would still have to go with C (plain, old).
> Yet another attempt to reinvent a better C. Curious, but unpractical. If one need a better C, C++ should be used instead.
Those two languages are on the opposite ends of any complexity scale. Someone looking for a better C has a ton of options before getting to "lets use C++ and ask our devs to practice discipline".
It cannot. C is a wonderful language that makes me smile every time I pick it up. A truly universal tool that lets you go wherever your heart desires. Go is a prison designed to enforce a bleak uniformity on all of it's users. For only by painting everything a uniform gray can we ensure we are all equal.
Go is not like C in any way. It doesn't feel like C, it feels like C# with mediocre syntax changes and extremely explicit error handling -- like someone took the bad parts of C and added them to a high level language.
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)?
Then, a user (like me) tries writing something like
well, oops. OK, now you grab the list of reserved words of the target language, which is not always an easy thing to do, and rename type names and variables as needed.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.
reply