Question regarding the direction

[neiltalap]

Hi, I am Neil.

Have you considered creating a subset of golang that actually compiles into llvm IR? Or is that not really realistic, was just curious.

[nalgeon]

Hey Neil! The thing is, I like C as an intermediate representation. So I don't have any plans to switch to LLVM or QBE at the moment. That could change in the future, but for now, it's not on the roadmap.

[ohir]

compiles into llvm IR?

What would be the purpose of having "a subset" and the IR output?

@nalgeon
Big thank you for the transpiler :)

[neiltalap]

compiles into llvm IR?

What would be the purpose of having "a subset" and the IR output?

@nalgeon Big thank you for the transpiler :)

No need for quotes, I will define a subset for you, which I mean.

It might be crazy, but what if we largely keep conformance to Golang and, in a sense, inherit all of its ecosystem, but at the same time we compile our own LLVM IR, and then use clang to create the executables.

Because you see, the problem is that if we don't inherit most of the Golang ecosystem, this is a perilous effort.

BUT

If we do, we get as fast as we can be + we get to keep the ecosystem + we don't have to write a compiler, we will simply use a highly optimized, and I say preferable compiler, clang.

The whole problem then boils down to two problems: how do we create the best IR we can possibly create from the Golang syntax, and how do we make sure all of the code from the Golang ecosystem can compile too?

If we keep the primitives and the contracts that Golang has via its syntax, but rip out and replace things lower down. I believe there is a chance for massive improvements. With tradeoffs, of course.

But that might open a door for Golang to be compiled and used in space applications or high-performance systems.

Go lang tries and succeeds at being the best server language. What if we take its ecosystem and say, we want more performance now.

I must say that I am somewhat biased because I want to be able to formally verify golang code.

As a result, there will be no intermediate step of C.

[neiltalap]

If we do go down that path, you will have my support and contributions. Well... without overreaching, of course. In just but mild terms.

[nalgeon]

There are two separate things I want to comment on:

we get to keep the ecosystem + we don't have to write a compiler, we will simply use a highly optimized, and I say preferable compiler, clang.

Solod already does this — without generating LLVM's IR. Solod's transpiler outputs regular C code, which you can then compile using any highly optimized C compiler like gcc or clang.

how do we make sure all of the code from the Golang ecosystem can compile too

This is not a goal for Solod. Solod isn't meant to be a Go compiler — it's a different language with its own design choices. If you're looking for a Go-to-IR compiler, check out tinygo.

[ohir]

As a result, there will be no intermediate step of C.

But C generation is exactly is the power of Solod transpiler. You write C in Go syntax then you have C source you can just plug in your existing C codebase.

if we largely keep conformance to Golang and, in a sense, inherit all of its ecosystem, but at the same time we compile our own LLVM IR, and then use clang to create the executables [...]
we will simply use a highly optimized, and I say preferable compiler, clang

This was tried and retried and in one case (tinygo) aleready works:

• https://tinygo.org/docs/concepts/faq/what-is-tinygo/
• https://go.googlesource.com/gollvm/
• https://github.com/llir/llvm
• https://tinygo.org/docs/concepts/faq/what-is-tinygo/
• ByteDance has TangoLllvm (afaik closed source now)

[nalgeon]

Now you have two answers that are basically the same. Just pick the one you like best :)

[neiltalap]

Yes, thank you. Apparently Google tried this in the past. They abandoned it though. At the state in which the project is, it is not faster than standard golang. It depends a lot on the quality of IR, and I don't particularly respect Google or its engineers for rigour or knowledge. Still...

I wanted it to be formally verifiable with rocq. But I think that would be too much effort.

I can use OCaml for important parts instead, and use golang for plumbing. For my projects that is.