
Goby: A new Ruby-inspired language written in Go - mcone
https://github.com/goby-lang/goby
======
anilgulecha
Crystal-lang has also been around with similar ruby syntax and features like
green threads, and a larger standard library. Performance is at par with
golang.

[http://crystal-lang.org](http://crystal-lang.org)

PS: Notably, websocket support is still lacking in Goby.

~~~
honewatson
Crystal is closer to C performance wise. The compiler is much slower than Go
due to the aggresive type inference.

~~~
theodorton
I believe this is partially due to the lack of incremental compilation, which
is on the roadmap [0] for 1.0. The compiler itself builds in ~10 seconds. [1]

[0]: [https://github.com/crystal-
lang/crystal/wiki/Roadmap](https://github.com/crystal-
lang/crystal/wiki/Roadmap)

[1]: [https://crystal-lang.org/2015/12/24/the-future-of-
crystal.ht...](https://crystal-lang.org/2015/12/24/the-future-of-crystal.html)

------
jwilliams
Interesting. The goal is "small and handy environment that mainly focusing on
creating API servers or microservices". Having moved from Ruby to Go in the
last year or two I'd be really interested in what language features they're
pushing with that goal. I really enjoyed my work with Ruby, but I have found
Golang pretty quick at these "backend" type work.

On the back of this, I dug around a bit around for other transpilers to/from
Golang. So far:

\- [http://havelang.org/](http://havelang.org/)

\- [https://github.com/jcla1/gisp](https://github.com/jcla1/gisp)

\- [https://github.com/google/grumpy](https://github.com/google/grumpy)
(Python to Go)

\- [https://tardisgo.github.io/](https://tardisgo.github.io/) (Go to Hexe)

\-
[https://github.com/gopherjs/gopherjs](https://github.com/gopherjs/gopherjs)
(Go to JavaScript)

If there are any others, be keen to find out.

~~~
singularity2001
EDIT: my bad, I saw 'bytecode' and wrongfully assumed goby is a compiled
language

[https://github.com/goby-
lang/goby/tree/master/compiler/bytec...](https://github.com/goby-
lang/goby/tree/master/compiler/bytecode)

~~~
lloeki
> this is not a transpiler though, it as a compiler. which makes it
> attractive, especially because Crystal is so very slow

This is an interpreter, not a compiler. Crystal is a compiler and what makes
it "slow" to compile is type inference but then it runs at native speed.

------
st0012
Hi, I'm Stan, this project's creator. I will explain your questions later. But
before that please check out our sample site (written in Goby):
[http://sample.goby-lang.org/](http://sample.goby-lang.org/)

And our plugin system, which is Goby's coolest feature: [https://goby-
lang.gitbooks.io/goby/content/plugin-system.htm...](https://goby-
lang.gitbooks.io/goby/content/plugin-system.html)

~~~
oelmekki
Congratulation, and best wishes :)

When things settle down, I would love to read an article from you about what
it's like to launch a new programming language by the end of the 2010s.

I'm under the impression that adoption is going way faster than in previous
decade, when php, java and C/C++ were kings hard to revoke. But there's still
a gap of few years between initial announcement of a language and it being
used in the wild - which is quite understandable, because people want to be
sure the language will stick around before writing production code with it.

I would love to know what you do during those years, how you grow your
language, how you simply manage to use it at work, or for your own projects.
If you could write such article, that would be awesome :)

~~~
st0012
Thanks! I'll try to share my experience to others by writing posts or giving a
talk on conf. But actually Goby is just 6 months old, so you might need a
while :)

------
kingwill101
Would be interesting if we could use it as a library from go

~~~
st0012
Sadly we can't. But you can use go library in Goby

------
varunramesh
Are threads both concurrent and parallel (like goroutines)? In other words can
they be used to parallelize CPU-heavy computation?

~~~
jerf
If you care about CPU-heavy computation, you care about not using an
interpreted language to do it, because if you pay a 10x performance penalty,
that turns your 16-core machine back into an effective 1-core machine.
(Apparent number mismatch to account for slowdowns and general amdahl's law.)
And, with no offense intended to Goby, a brand new scripting language built on
top of a language like Go (already ~2x-3x slower than C in general) could
easily see performance penalties of 100x or 500x vs C. (Think logarithmic
here.)

Even Go, at 2x-3x slower than C, is already not a terribly great choice for
true CPU-intensive loads. It's fast enough it can fit in some scenarios, but
if you really start to ramp up you're going to want to switch to something
else.

Edit: Would someone like to explain what is wrong with the idea that people
who care about CPU-heavy computation also need to care about the performance
of the language they are using rather than just downmodding it? I find the
idea that in one second, someone cares deeply enough about CPU performance to
call their load "CPU-heavy" and want to learn how to use many cores to process
it, but in the next second is oblivious to the issues of using languages that
are very slow on the CPU to do the work, to be a very bizarre shape of
concerns about performance. It's like someone asking how they can move ten
tons of something from New York to LA as quickly as possible, but insisting
that they will only use bicycles to do it. The fact that you may be able to
work out a way to do it with only bicycles, even perhaps surprisingly quickly
compared to what one's initial reaction may have been, isn't going to change
the fact that it sure is weird how one moment you're concerned about doing it
as quickly as possible and in the next moment completely oblivious to the
performance consequences of the chosen tools.

~~~
jhgb
> "If you care about CPU-heavy computation, you care about not using an
> interpreted language to do it, because if you pay a 10x performance penalty,
> that turns your 16-core machine back into an effective 1-core machine. "

> "Edit: Would someone like to explain what is wrong with the idea that people
> who care about CPU-heavy computation also need to care about the performance
> of the language they are using rather than just downmodding it?"

You first talk about interpreters and then you talk about performance. They're
not _perfectly_ correlated. Given how modern implementations of languages are
not _either_ simple token processing state machines of the 1980s _or_ simple
compilers of the same period, this equivocation of yours seems out of place in
the 2010s. A _proper_ interpreter like LuaJIT can not only reach very decent
performance on computationally expensive stuff (1x-2x of C run time in Scimark
2, depending on the particular test, for example) but also allow for delaying
computation to as late a time as possible and then generating specialized code
based on the increased amount of information available. That can be done not
only even across modules (which static compilers still struggle with without
some kind of link-time optimizations) but also depending on actual data at run
time (which static compilers are completely incapable of, unless they're
somehow embedded into the final application - an option that, e.g., Lisp
programs can use if they choose so).

~~~
jerf
"A _proper_ interpreter like LuaJIT"

Is a JIT, not an interpreter. JITs are fundamentally different. I seriously
doubt Goby is a JIT yet, to the point I'm not even going to check the source.

LuaJIT is also an outlier. I consider it a solid point in favor of the
argument that if you build a language for speed from day 1, you can do pretty
well and still build in a lot of nice features. Even so, I understand LuaJIT
had to drop some Lua features to get there. However, if you first design your
language's features with a lot of focus on convenience, and then try to make
them fast without compromise, you end up in the
PHP/Python/Perl/Ruby/Javascript space, where no matter how much work you put
into it you hit fundamental walls. (Yes, even JS with all modern JIT'ing is
not really _that_ fast of a language.) The counterargument to your point is
that LuaJIT is pretty much all alone in its position on the performance,
despite the fact that other seemingly-similar languages have had orders of
magnitude more work poured into their JITs.

I think there's a lot of up-and-coming languages that have learned a lot about
designing for performance and while, alas, LuaJIT's future seems dim, I
believe a lot of languages like Nim and Crystal and even to some extent Go
have learned about how to be nicer languages than C or C++ while _not_ giving
up tons of performance. LuaJIT, in my opinion, still has a place of honor in
the history of programming languages, far outsized from its actual use.

(Rustaceans may be assured I have not forgotten them, I just think Rust is
coming at this from a significantly different angle.)

~~~
etiene
> Even so, I understand LuaJIT had to drop some Lua features to get there.

Not true. LuaJIT is complete Lua. The difference, besides being jitted are:
having parts written in assembly, super optimisations and things like FFI
which cannot be written in C89. Main Lua uses nothing but C89 which makes it
run on almost anything so this is not the case for LuaJIT. Also vanilla Lua is
way smaller and the source code is cleaner simpler. Divergence in the language
is not because LuaJIT dropped some features but because it was created while
Lua was on version 5.1. Now Lua is on 5.3 and LuaJIT didn't catch up on
everything yet, it is basically 5.1 compatible with some sprinkles of 5.2.

------
smegel
> Tough thread

What the heck's that??

~~~
bshimmin
I think the word "tough" is an adjective here, modifying "thread/channel
mechanism" \- meaning something like "resilient" or "robust".

------
knodi
Can this be used in a Go app as a plugin/scripting lang?

~~~
st0012
Goby does reverse, using Go package as plugin. See: [https://goby-
lang.gitbooks.io/goby/content/plugin-system.htm...](https://goby-
lang.gitbooks.io/goby/content/plugin-system.html)

------
timercl
sorry but the ruby community now has something called Elixir.

~~~
devmunchies
Erlang is not made for anything that is cpu intensive. It doesn't solve every
problem. Thats the void I think Crystal is going to fill for Rubyists.

~~~
oelmekki
That's one of the reasons I migrated to Go instead of Elixir (plus, I love the
idea of suddenly having system programming within reach). But doing so, I
haven't explored deeply enough Elixir and Crystal. Would you say they each
provide something, not related to taste, that Go doesn't have (or that Go is
doing worse)?

~~~
devmunchies
I'd compare Go to Crystal. Go is more mature and stable but crystal a little
faster thanks to LLVM. Plus I like Crystal's syntax better. I've been
contributing to the crystal ecosystem with some libs and use it for personal
stuff but I use Go at work. Once Crystal hits 1.0 and has good parallelism
then I think it could be used as a drop-in replacement for Go for most use
cases.

~~~
oelmekki
I see. Thanks for your insight!

------
kazinator
Just call it "Gouldby". That's an English surname, and can be short or "Go
would be Ruby". (Which doesn't entirely make sense, but names don't entirely
have to!)

------
nawfalhasan
Unless you explain the motivation behind yet another language, it's hard for
people like me to like a new thing. How is it different from Ruby? Just
concurrency support? How is it different from Go? Just ruby syntax? Is the
language statically typed or dynamically?

Additionally I would like to see some syntax examples at the start as well.

~~~
lloeki
What? This is literally the first paragraph of README.md:

    
    
        Goby is an object-oriented interpreter language deeply inspired by Ruby as well as its
        core implementation by 100% pure Go. Moreover, it has standard libraries to several
        features such as the Plugin system. Note that we do not intend to reproduce whole of
        the honorable works of Ruby syntax/implementation/libraries.
    
        One of our goal is to provide web developers a sort of small and handy environment that
        mainly focusing on creating API servers or microservices. For this, Goby includes the
        following native features:
    
        - Tough thread/channel mechanism powered by Go's goroutine
        - Builtin high-performance HTTP server
        - Builtin database library (currently only support PostgreSQL adapter)
        - JSON support
        - Plugin system that can load existing Go packages dynamically (Only for Linux by now)
        - Accessing Go objects from Goby directly
    

This makes it quite a match to do containerized things as a single binary ||
self-deploying Go apps[0]

[0]: [https://www.dotconferences.com/2016/10/kelsey-hightower-
self...](https://www.dotconferences.com/2016/10/kelsey-hightower-self-
deploying-go-applications)

~~~
nawfalhasan
>One of our goal is to provide web developers a sort of small and handy
environment that mainly focusing on creating API servers or microservices

How does it explain the motivation behind creating another language? What were
the reasons the developer/team behind goby thought existing languages/tools
didnt help? My questions are also about how different goby vs ruby is, or goby
vs go. I also question if the language is dynamically or statically typed, etc
which are bare minimum I expect in introduction.

~~~
st0012
If you ask me why I started this project at first place, I'd say it's just for
fun and practicing.

And we know that Goby is not special enough by giving green thread or channel.
So currently our main goal is to let users use Go's packages and manipulate Go
objects directly in Goby.

And we already made some progress, please check out this: [https://goby-
lang.gitbooks.io/goby/content/plugin-system.htm...](https://goby-
lang.gitbooks.io/goby/content/plugin-system.html)

