Goth - Inferno in Go
Jason Catena
Go doesn't seem to have an operating system project to prove out its worthiness as a systems language. At the same time, I would rather write Go than Limbo. And since I use Inferno everyday I would like it to be more lively. But I can't write an operating system alone. So I wondered whether there was community interest in rewriting Inferno in Go, to create a virtualized cross-platform OS layer in Go, and with an extension language also in Go. I was thinking of calling it Goth (Go to Hell), to honor both Go and Inferno. (Seriously, not a joke like gofy). I would think the first thing to write would be a Go version of emu, but someone might have a better idea.
Nick Owens
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
https://code.google.com/p/gofy/
it is now unmaintained because of the effort required to track the
changes in go.
Nick
jason....@gmail.com
mortdeus
A core component of chaos is the goblin project that I currently maintain. Goblin is the plan9 coreutils rewritten in Go in a cross platform way. The general idea is that the goblin tools may be used as a drop in replacement for the coreutils when using the plan9 kernel, or on other operating systems it would function kinda like plan9port does.
Any commits to goblin are highly welcome if you want to contribute to this cause.
mortdeus
Its an interesting idea in theory, but in reality not really worth the resource investment when we already have the plan9 kernel. IMHO, our resources should really be focused toward developing a userland that can compete with other operating systems.
Jason Catena
> can you guys assemble a pro/contra list about go vs limbo?
For me it mostly comes down to Go being a more modern descendent of Limbo, which refines its ideas, and under active development.
Jason Catena
> not really worth the resource investment when we already have the plan9 kernel
I see emu as having broader applicability than the Plan 9 kernel, since you have to choose between using the Plan 9 kernel and using $dayjobos, or put Plan 9 in a VM. I think the hosted mode of Inferno is closer to integration, since you run both at once. You can construct pipelines which not only use both userlands and host applications, but also take advantage of the Inferno view (e.g. namespaces, at least in the Inferno-userland commands).
Jason Catena
> Goblin is the plan9 coreutils rewritten in Go in a cross platform way.
I forsee something very close to Goblin being part of Goth. I don't see much point in a competing rewrite in Go of the Plan 9/Inferno userland, so long as it keeps to the minimal-options ideal.
I like sh, so I'd like it to also be part of Goth. I'm writing a build tool which uses Inferno/Plan 9 features (filesystem layout, /env, bind, sh language and <{}), so selfishly--and to help advance the state of the build art--I'd include that beside mk.
The go userland requires that we compile go to dis, as mentioned, so we'd develop the userland concurrently with godis (go to dis compiler) and goemu (emu in go).
I don't think it's necessary to reskin Inferno completely with some kind of punk/goth flavor (don't need a tool called docmartin or lippierce). I'm happy using go* names to make it clear it's a gooey Inferno.
Jason Catena
> I was thinking of calling it Goth (Go to Hell), to honor both Go and Inferno.
Goose might also be a good name, for Go operating system emulator.
Tamas Herman
> one cent - I'm not sure I like the idea of re-writing Inferno in Go, as it
> means only computers with Go compilers can run Inferno. At present, Inferno
> is written in C, and pretty much everything has a C compiler.
well, obviously the go rewrite of inferno could run go too
eventually... or, wait a sec it is written in C too. so what exactly
is the problem?
im my opinion is a but unfortunate that everything is written in C,
because it's not the cleanest language syntax wise. also the \0
terminated strings promoted by C caused this problem of buffer
overflows allowing arbitrary code execution, etc, which are still
plague-ing the programming world.
party because of this, the Rebol community set out on a journey to
change this and started developing the Red + Red/System language pair.
have a look at the project here: http://www.red-lang.org/
Red/System is the new C, but with a very clean, natural syntax and it
is gonna be implemented in itself (currently it's still written in
Rebol) hence it would be self-hosting on any platform.
we gonna have a developer conference 2 weeks from now in montreal:
http://recode.revault.org
both the author of Rebol and Red will be there.
it will be great to have some Go people present too.
i think we can learn from each other.
> two cents - Using Go within Inferno sounds great however. I can't say I like
> Limbo that much, and Go which compiled to dis would be be really interesting
> to me.
can you guys assemble a pro/contra list about go vs limbo? im just curious.
--
tom
Garry Taylor
mortdeus
> not really worth the resource investment when we already have the plan9 kernel
I see emu as having broader applicability than the Plan 9 kernel, since you have to choose between using the Plan 9 kernel and using $dayjobos, or put Plan 9 in a VM. I think the hosted mode of Inferno is closer to integration, since you run both at once. You can construct pipelines which not only use both userlands and host applications, but also take advantage of the Inferno view (e.g. namespaces, at least in the Inferno-userland commands).
mortdeus
On Thursday, June 27, 2013 8:10:56 AM UTC-5, Jason Catena wrote:
> Goblin is the plan9 coreutils rewritten in Go in a cross platform way.
I forsee something very close to Goblin being part of Goth. I don't see much point in a competing rewrite in Go of the Plan 9/Inferno userland, so long as it keeps to the minimal-options ideal.
4. There are new tools worth adding to the current plan9 coreutils, for example mosh. (http://mosh.mit.edu/)
The go userland requires that we compile go to dis, as mentioned, so we'd develop the userland concurrently with godis (go to dis compiler) and goemu (emu in go).
1. The dis VM isnt being worked on nearly as much as the go compiler and standard library (if at all).
2. I dont believe go's interfaces will work with dis bytecode.
3. Running Go in a VM feels sacrilegious.
Jason Catena
> I can think of alot of reasons to argue the validity of goblin.
To be clear, I support Goblin and think it would be good to reuse. I was trying to say that since Goblin exists, it would be better to use Goblin itself than to create another, separate port of those utilities, also written in Go.
Jason Catena
> 1. The dis VM isnt being worked on nearly as much as the go compiler and standard library (if at all).
If we did this, it would be an opportunity to revisit the dis VM, to make it work well with Go, and other small (in project scope) changes to make it more modern (eg, 64-bit).
> 2. I dont believe go's interfaces will work with dis bytecode.
Why? I don't know enough about it to see an incompatibility.
> 3. Running Go in a VM feels sacrilegious.
The VM is for nifty Inferno OS features not present in the host, not really just to run Go. Whether Go in a VM is distasteful depends on what you want: if you want to distribute binaries to any platform, I would think it's a win over asking people to recompile. There's also the option to pass through executables that are native to the host platform, at the loss of easy portability. I'd let users decide when to use native or dis executables.
> 4. As I mentioned earlier, 9vx is a much better idea imho.
I have not yet used 9vx. From what I read, emu seems to have better availability and stability across Windows/Macosx/Linux/etc, and possibly be more self-contained (vx32 would also need ported or replaced?).
Jason Catena
> Using Go within Inferno sounds great however. I can't say I like Limbo that much, and Go which compiled to dis would be be really interesting to me.
This is what first inspired the idea, and seems a minimal standalone project, that fits well with everything currently in place. Are other people also interested enough in godis to also work on it, or at least use it if it were written?
Sebastien Binet
-s
