V: Proposal: transpile Go standard library to V

[elimisteve]

V is even more similar to Go than to C. And since @medvednikov has apparently written code that translates from C to V already, I would think that translating from _Go_ to C would be easier than what has already been done.

If feasible, I propose writing go2v, a Go-to-V compiler/transpiler/translator, so that Go's standard library can become V's standard library, thereby making V mind-blowingly practical for truly serious real-world use immediately thereafter.

[medvednikov]

Yes, I considered this. This would be great.

The main challenge is imitating the Go runtime.

[elimisteve]

Last I checked, Go 1.5+ is written in Go 1.4. So if we could translate arbitrary Go code to V code, we could translate the Go runtime to V as well, and have it become the V runtime, yes?

[MostHated]

While I am all for having the actual functionality of the Go StdLib, I would imagine it is not that easy. I am no expert, but if you simply bring over everything from Go, I am pretty sure you are going to end up just having a second copy of Go.

If it can be done while maintaining the speed of V, then that is great, but if mimicking the Go runtime just ends up making V become Go, that kind of defeats the purpose and you may as well just use Go in the first place?

[elimisteve]

@MostHated I think @medvednikov has utterly nailed the syntax, semantics, and fundamental advantages of V. If the hard-to-imitate parts of the Go runtime are auto-translated to V (after doing significant work to turn arbitrary Go code into V code), then they don't need to be imitated at all -- they can simply be used.

[MostHated]

I hear ya, I was just going by his reply mentioning having to imitate it. Don't get me wrong, I am 1000% for it. Fingers crossed. : D

[elimisteve]

:smiley: V's syntax and semantics + Auto-generated implementation details (e.g., goroutines and memory management) => :tada:

[medvednikov]

I think Go runtime uses Go assembly, not sure.

[medvednikov]

Yes 44k lines of Go assembly in runtime/

[medvednikov]

But there's probably a way to translate that Go assembly to native assembly.

[elimisteve]

I'm looking in https://golang.org/src/runtime/ and I'm not sure what you mean by "Go assembly" :-). Aren't the .s files normal, native assembly code?

[rohanthewiz]

Go has it's own flavor of ASM. https://golang.org/doc/asm.

The most important thing to know about Go's assembler is that it is not a direct representation of the underlying machine

[Chiiruno]

Can we even imitate the Go GC without having a GC ourselves?
AFAIK, Go doesn't have manual memory management, although I'm not sure for the standard library.

[Immortalin]

Can we pull in the Rust libraries too? The memory model is similar. For Go, we can implement ARC for the libraries. Not perfect and would cause issues with circular data structures but for 80% of cases would work.

[lammel]

Shouldn't V bring it's own standard library. Probably not everything in Golang fits the simplicity that V aims for.

The go stdlib would be a very good starting point of course. Maybe it makes sense to transpile and use a separate namespace for it (like compat/go/strings), to allow V to evolve it's own stdlib.

Or was the plan to use the Golang stdlib as a starting point anyway to evolve V from there (could be tricky, because there would always be breaking changes for existing code then)

[MostHated]

It sounds like everyone is just really excited at the possibilities and is wanting X, Y, and Z, but then someone else also wants N, F, R, etc, etc. Next thing we know it is just going to be another C++. Might be best to first simply make sure everything is working properly, such as actual machine code generation, etc? It is probably going to take a bit of time and planning in order to make proper decisions on what is actually best for the language.

[elimisteve]

Probably not everything in Golang fits the simplicity that V aims for.

It is probably going to take a bit of time and planning in order to make proper decisions on what is actually best for the language.

V is extremely similar to Go -- more similar than V is to any other language -- and if @medvednikov thought that there was something in the Go stdlib that doesn't belong in V, fine, leave it out! But it would be wise to translate from some other language rather than building everything from scratch.

I am also excited that @medvednikov understands the value of translating between languages. And since he does, I think that translating from Go to V rather than building almost-identical stuff in almost-identical syntax is important.

Translating Go's runtime to V and using most of _that_ (for the reasons I mentioned above) could also be a gigantic win!

[joe-conigliaro]

A large percentage of Go's std lib uses very little to no functions from the runtime module, so a lot of these modules can easily be translated without it. I would guesstimate that over 95% of the code in the std lib modules is not calling any functions from the runtime module.

I personally would steer clear of translating the whole runtime module directly, like I was saying there is a large portion of the std lib which needs little to none of it. I would take a look at the parts that are needed and see if direct translation makes sense, or if those functions should be implemented in a way optimized for v. Once these parts are in place any std module could be translated without needing the entire runtime module, I feel that this would keep things simpler/leaner, and would be better for performance.

I think the parts of the runtime module which are used the most in the std lib are the reflect & atomic/race stuff. Ideally I think these should be implemented in a way specific to v's design, of course we could base it of go's code, but again I feel like this will need manual intervention. We already need these things implemented in v (irrespective of translating go). I feel like we should concentrate to implement these (can be based of go but optimized for v) once we have the implementation there go std lib modules can be translated.

I feel like the type of functions in the runtime module need consideration to be built in a way optimized for v's design. Just my thoughts.

[M4SSD35TRUCT10N]

No Go please. V is so fast and has no need for GC. That's why I'm so interested in it. Do vlib in the v way.