100 lines
5.8 KiB
Plaintext
100 lines
5.8 KiB
Plaintext
%p Since i currently have no time to do actual work, i’ve been doing some research.
|
||
%p
|
||
Reading about other implementations, especially transpiling ones. Opal, ruby to
|
||
javascript, and jruby, ruby to java, or jvm instructions.
|
||
%h2#reconsidering-the-madness Reconsidering the madness
|
||
%p
|
||
One needs to keep an open mind off course. “Reinventing” the wheel is not good, they
|
||
say. Off course we don’t invent any wheels in IT, we just like the way that sounds,
|
||
but even building a wheel, when you can buy one, is bad enough.
|
||
And off course i have looked at using other peoples code from the beginning.
|
||
%p
|
||
A special eye went towards the go language this time. Go has a built in assembler, i
|
||
didn’t know that. Sure compilers use assembler stages, but the thing about go’s
|
||
spin on it is that it is quite close to what i call the risc layer. Ie it is machine
|
||
independent and abstracts many of
|
||
%em real
|
||
assemblers quirks away. And also go does
|
||
not expose the full assembler spectrum , so there are ways to write assembler within
|
||
go. All very promising.
|
||
%p
|
||
Go has closures, also very nice, and what they call escape analysis. Meaning that while
|
||
normally go will use the stack for locals, it has checks for closures and moves
|
||
variables to the heap if need be.
|
||
%p
|
||
So many goodies. And then there is the runtime and all that code that exists already,
|
||
so the std lib would be a straight pass through, much like mri. On top one of the best
|
||
gc’s i’ve heard about, tooling, lot’s of code, interoperability and a community.
|
||
%p
|
||
The price is off course that one (me) would have to become an expert in go. Not too
|
||
bad, but still. As a preference i naturally tend to ruby, but maybe one can devise
|
||
a way to automate the bridge somewhat. Already found a gem to make extensions in go.
|
||
%p
|
||
And, while looking, there seems to be one or two ruby in go projects already out there.
|
||
Unfortunately interpreters :-(
|
||
%h2#sort-of-dealbreaker Sort of dealbreaker
|
||
%p
|
||
Looking deeper into transpiling and using the go runtime i read about the type system.
|
||
It’s a good type system i think, and go even provides reflection. So it would be
|
||
nice to use it. This would provide good interoperability with go and use the existing
|
||
facilities.
|
||
%p
|
||
Just to scrape the alternative: One could use arrays as the basic structure to build
|
||
objects. Much in the same way MRI does. This would mean
|
||
%em not
|
||
using the type system,
|
||
but instead building one. Thinking of the wheels … no, no go.
|
||
%p
|
||
So a go type for each of what we currently have as Type. Since the current system
|
||
is built around immutable types, this seems a good match. The only glitch is that,
|
||
eg when adding an instance or method to an existing object, the type of that object
|
||
would have to change. A glitch, nothing more, just breaking the one constant static
|
||
languages are built on. But digging deep into the go code, i am relatively
|
||
certain one could deal with that.
|
||
%p
|
||
Digging deeper i read more about the go interfaces. I really can’t see a way to have
|
||
%em only
|
||
specific (typed) methods or instances. I mean the current type model is about
|
||
types names and the number of slots, not typing every slot, as go. Or for methods,
|
||
the idea is to have a name and a certain amount of arguments, and specific implementations for each type of self. Not a separate implementation for each possible combination of types. This means using go’s interfaces for variables and methods.
|
||
%p
|
||
And here it comes: When using the reflect package to ensure the type safety at runtime,
|
||
go is really slow.
|
||
10+
|
||
%a{:href => "http://blog.burntsushi.net/type-parametric-functions-golang/"} times slower
|
||
maybe. I’m guessing it is not really their priority.
|
||
%p
|
||
Also, from an architecture kind of viewpoint, having all those interfaces doesn’t seem
|
||
good. Many small objects, basically one interface object for every object
|
||
in the system, just adds lots of load. Unnecessary, ugly.
|
||
%h2#the-conclusion The conclusion
|
||
%p I just read about a go proposal to have int overflow panic. Too good.
|
||
%p
|
||
But in the end, i’ve decided to let go go. In some ways it would seem transpiling
|
||
to C would be much easier. Use the array, bake our types, bend those pointers.
|
||
While go is definitely the much better language for working in, for transpiling into
|
||
it seems to put up more hurdles than provide help.
|
||
%p
|
||
Having considered this, i can understand rubinius’s choice of c++ much better.
|
||
The object model fits well. Given just a single slot for dynamic expansion one
|
||
could make that work. One would just have to use the c++ classes as types, not as ruby
|
||
classes. Classes are not types, not when you can modify them!
|
||
%p But at the end it is not even about which code you’re writing, how good the fit.
|
||
%p
|
||
It is about design, about change. To make this work (this meaning compiling a dynamic language to binary), flexibility is the key. It’s not done, much is unclear, and one
|
||
must be able to change and change quickly.
|
||
%p
|
||
Self change, just like in life, is the only real form of control. To maximise that
|
||
i didn’t use metasm or llvm, and it is also the reason go will not feature in this
|
||
project. At the risk of never actually getting there, or having no users. Something
|
||
Sinatra sang comes to mind, about doing it a specific way :-)
|
||
%p
|
||
There is still a lot to be learnt from go though, as much from the language as the
|
||
project. I find it inspiring that they moved from a c to a go compiler in a minor
|
||
version. And that what must be a major language in google has less commits than
|
||
rails. It does give hope.
|
||
%p
|
||
PPS: Also revisited llvm (too complicated) and crystal (too complicated, bad fit in
|
||
type system) after this. Could still do rust off course, but the more i write, the
|
||
more i hear the call of simplicity (something that a normal person can still understand)
|