67 comments

[ 2.7 ms ] story [ 145 ms ] thread
It would be interesting if it would include native Go features such goroutines and channels
Nice... reminds me of Mirah (formerly known as Duby). It's basically a compiled Ruby, but abandoned since some time. 5 years ago it used to be the fast alternative to JRuby on Google's App Engine. Together with the web framework Dubious :D
So basically another elixir? I'm curious why Ruby? and why with Go?
Right there on the page:

"Goal

I want to build a language that focuses on developing microservices. Which should be performant and easy to write. This is why Rooby has Ruby's user friendly syntax and is written in Go."

I don't think it's really elixir so much as it's another Crystal (https://crystal-lang.org)
At least Crystal brings new features like static typing, light threads, and compilation. From the README I don’t see what Rooby is bringing to the table.
Maybe not being static typed is what could make it appealing to Ruby developers. For example I don't like to have to declare types or generics. Type inference is ok.

There is a wide range of languages to pick the one that better suits our style from. That's great and I like that people keeps trying.

Static typing doesn’t mean you have to declare types. Type inference means you can write code just like a non-typed language but you get the safety + it executes faster. IMHO, except for toy languages, not having (strict) typing in 2017 is a language design flaw.
It's a tradeoff between safety and convenience. It's swinging toward safety now and it will swing back towards convenience again. At best we're living in a damped harmonic oscillator. Maybe type inference is the equilibrium point.
I'm baffled as to why people keep insisting Elixir is "Ruby-like".

Is it just because they both have "def" and "puts"? Cause that's just about where the similarities end :-)

Agree. The language is different. The standard library is different. The runtime is different. The last two quite substantially at that. JavaScript is more like Ruby than Elixir is. I'm tempted to say Go and Jave are more Ruby than Elixir is.

FWIW, I've been using elixir for about a year now, and I think it's fantastic. I still use node & ruby for scripts (which can get complicated, but almost always for one-offs and asynchronous processing), Go for anything I actively want to share memory (though, started using Crystal, can't wait for threads), and OpenResty for any web proxy/middleware stuff. But Elixir is now the lions share for me and I find it fun and productive.

Maybe they mean in terms of there being a Rails-style (mindset might be a better way to put it) framework available to get up and going quickly.
This would be huge if it passed at least some portion of the RubySpec
I like the name and I hope the obligatory web framework will be called "Rales".
Name is terrible, you can't tell your friend "I've started using Rooby", response would be "good for you".

I suggest renaming before too late.

Crystal is years ahead and way better with an active community. What purpose does Rooby serve?
> What purpose does Rooby serve?

I don't know. I do know that many of these language projects are people's hobby projects. They like to pick a language they either know'n'love or want to get more proficient in.

> Rooby is a Ruby-like object oriented language written in Go. You can think it as a simplified, compilable Ruby for now.

I have to ask, if your goal is "compilable Ruby", then...why not Crystal? (https://crystal-lang.org/ ) Seems like it accomplishes your goals, already exists, and is (as far as I know) stable and well regarded.

Nothing wrong with reinventing the wheel, and you may have very compelling reasons to write your own project. But it looks weird when there's already a well-known project in this space and you don't compare yourself to it. How are you better?

Not written in Go maybe? Many of these language projects are people's hobby projects. They like to pick a language they either know'n'love or want to get more proficient in. (edit: nothing wrong with that!)
Quite right. And there's nothing wrong with that!

But it's good to know if the author's main issue with Crystal is that it <lacks important feature X> or if it's that it's not written in Go, which is a barrier for him to contribute. Both are very valid reasons to start a new project, but it's good info to have. :)

> And there's nothing wrong with that!

I was not implying a problem with that. I'll try to make that more clear by an edit.

Crystal is written in crystal so everyone has an equal barrier to entry
In terms of Crystal vs Go, I've heard that Crystal is slightly faster but that Go is more portable and has much better concurrency? Is that not accurate?
Currently that's true, but we aim to have better concurrency than go at the point of 1.0. Crystal can probably also gain more architectures faster due to llvm. It's only about a week's worth of work (at most) to port Crystal to a posix target that has LLVM support.
I just wish pet hobby language projects stopped making it to the top of HN. That's where asking why is it better is important.
I found the author posted this on Changelog:

Hi, Rooby is a new object oriented language I created recently (written in Go). It looks just like Ruby for now because it's mainly inspired by it. But I want it to be a new language and start developing its own feature when it gets more mature. So I'm looking for developers who also interested in this project, any help or idea will help me a lot.

https://github.com/thechangelog/ping/issues/698

Crystal actually has quite a few features unique to Crystal too! I'd love to hear the author's ideas of how he wants to improve Ruby, maybe some of those ideas are still applicable to Crystal.
I'd argue there's a lot wrong with reinventing the wheel. People don't seem to care about the inevitable waste of programmer time and effort that comes with introducing a new programming language or library, assuming it gains any traction.
> assuming it gains any traction.

There's little risk of that I think; even very strong and innovative languages struggle to gain traction. It doesn't tend to happen by accident.

And let's not forget that writing your own ORM, compiler, programming language, hardware driver, etc., (even blog engine!) is an amazing way to learn. But it is good to know whether a project is a hobby project to help learn, or a serious project aimed at getting traction, or what.

>> But it is good to know whether a project is a hobby project to help learn, or a serious project aimed at getting traction, or what.

Most programming projects start with the intention of the latter but usually end up becoming the former.

I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu)

Linus Torvalds 1991

Minecraft is another good example.
I think it's the other way around.

Most projects start out as a hobby / experiment and a tiny fraction of those become popular.

> It doesn't tend to happen by accident.

I don't know, C++ is pretty popular. ;)

I (and everyone else) am allowed to waste precisely as much time as I feel like both as a creator and user of things.
By reinventing the wheel we've gotten much better wheels.
There's a difference between improving something and reinventing it.
Use of time for things that the programmer values, even if you don't, is not a waste.
> How are you better?

It's a valid question to ask but I don't think anyone has to think that through and really have a good answer before creating!

It might not matter much to the Ruby folks if it remains a hobby project, but this probably violates the "Ruby" trademark.
I went to https://www.ruby-lang.org/en/about/ and I didn't find any references to trademarks. There is a JRuby, an IronRuby, why not a Rooby?
IronRuby and JRuby are both implementations of Ruby; aside from any trademark issues that maybexist (I kind of doubt there are any) the usse of Ruby in the name is communicative of accurate information. Using something that's natural pronunciation is as a homophobe of Ruby for something that is not a Ruby implementation is probably misleading and and undesirable for it's effect on being able to clearly talk about the project.
I believe the two could be sufficiently differentiated in execution to satisfy the USTPO. It's a rather subjective system.
I see a lot of references to Crystal here and I would agree it is more mature but has different goals to be sure. If you want a rubyish DSL for microservices which can expose golang features and libraries then Crystal isn't a suitable match. We have to assume the later is important.

It's like saying JRuby is a suitable replacement because it's fast and has microservice libraries - it's not exactly what you want.

If the author is not planning to support rubyspec, monkey patching, runtime magic, etc. then it looks like they are closer to delivering on their objective.

Hello, I am the author of this project and I think you said what I think. I won't support most of ruby's meta-programming magic for keeping rooby as simple and performant as possible. Thanks for your explanation
Awesome, it looks really interesting.
CV Kits Supplies is Engaged In The General Services Contractors Providing Services Among Other Services Office Cleaning Service Building, Portable Toilet Rental, Property, Headquartered Di Jalan Raya Natar Lampung Indonesia. Vision & Mission CV. Kits Supplies Customer Satisfaction is our challenge detail us : http://kitssupplies.com 081368381598 ( +62) INA
Why not Guby or Gooby?
Hello, I'm the author of this project. Let me explain a few things:

1. The goal of this project is to let people "Use Ruby-like syntax build Go-like performant api servers".

2. The "Ruby-like" means Ruby-like syntax because I am a Rubyist and I think using Ruby to develop project is fast.

3. Using golang is because I want to build a http server library upon go's http package, which I think is a very good choice for writing api servers. And of course I might use goroutine directly in the future.

4. Making rooby compilable is just a feature I personally like.

5. You can see this project as a experimental language for a relatively small goal (see the first point above) + I like writing Go, then you won't be so surprise why I created it and not using crystal instead.

6. I really didn't expect rooby would gain so many traction, thanks for all your opinions :)

Seems like interop with Go could be its selling point. I wouldn't call it gruby though, since it isn't Ruby-on-Go.
For all the people asking "Why not Crystal?". It seems to me like the creator obtained a copy of the Go Interpreter book(https://interpreterbook.com/). Seems like a fair bit of the code is reused here. Nothing wrong with that at all (if true). After all its all under MIT License. Seems like a pet project more than something the author expected to gain any attention (kind of like Linux started out). Seems to me more like a ruby-like-coffeescript equivalent for Go.
Haha, I did read that book before start this project, it's a very useful material. But for now the project are far more complicated than the sample project in that book, only lexer and parser remain similar.

BTW I also took "nand2tetris II" on coursera and read "Ruby under a microscope" for this project.

I think that you should be a bit more transparent about how much of Thorston's ideas and code you are using in this project. You should probably give him some attribution.

I also read that book, and have a toy language I've been building, basically extending his ideas. I've looked through your code and much of is it nearly verbatim from the book (including code in your 'vm', or the monkey 'eval' package - it's not just the lexer/parser), though you (as I have), chose different names, or organized things differently, and added new features.

Yes, you've extended his ideas much farther, but the core of 'rooby' is pretty much the same as Thorston's language, 'monkey'.

Monkey is available with the MIT license, so it's fine what you've done. But, having been through the book and pretty familiar with the Monkey code (available for download here: https://interpreterbook.com/waiig_code_1.3.zip), I think it's disingenuous to say 'I read that book before this project..', which seems to imply that it was inspiration, rather than original source material.

On a positive note, it's a pretty cool version of Monkey.

The 'code' you read is similar, but the way they work are totally different.

Monkey is fundamentally a functional language, but rooby is totally an object oriented language. And the compiler, vm's internal implementation and bytecode spec, which are the 'core' of rooby, is not like monkey at all.

I would say I extended monkey's lexer and parser as rooby's. I feel sorry if I didn't give enough credit to Thorston, I would add reference to his book in readme. But the core is more a Ruby than monkey, so I don't think it's just an "extension" of monkey.

Please read the commits and you'll know how much work I did to make rooby, it's far more complicated than just "extend" monkey.