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)
|