Rooby: a Ruby-like object oriented language written in Go(github.com)
github.com
Rooby: a Ruby-like object oriented language written in Go
https://github.com/rooby-lang/rooby
67 comments
I think you shoulda named it "Goby" -- which is a real word for a cute l'il fish.
https://en.wikipedia.org/wiki/Goby
https://en.wikipedia.org/wiki/Goby
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.
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.
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.
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.
BTW here's the monkey source code I wrote when I practiced with the book https://github.com/st0012/monkey
Why not Guby or Gooby?
Seems like interop with Go could be its selling point. I wouldn't call it gruby though, since it isn't Ruby-on-Go.
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?
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 :-)
Is it just because they both have "def" and "puts"? Cause that's just about where the similarities end :-)
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.
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.
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.
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.
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.
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.
I suggest renaming before too late.
Should rename to Rubby.
When I get bored I'll give into recruiter spam sometimes and take them up on a phone call. I'd purposely pronounce Ruby as Rubby, and similar words. My favorite was Mysqueel.
Sounds like you may enjoy My Rails Blob: http://railsblob.blogspot.ca/2006/08/my-new-blob.html
Implies talking about this IRL
Crystal is years ahead and way better with an active community. What purpose does Rooby serve?
> 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?
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. :)
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. :)
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.
> 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.
I was not implying a problem with that. I'll try to make that more clear by an edit.
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.
> 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'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!
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
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.
I (and everyone else) am allowed to waste precisely as much time as I feel like both as a creator and user of things.
> 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.
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.
> It doesn't tend to happen by accident.
I don't know, C++ is pretty popular. ;)
I don't know, C++ is pretty popular. ;)
>> 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.
Most programming projects start with the intention of the latter but usually end up becoming the former.
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.
It might not matter much to the Ruby folks if it remains a hobby project, but this probably violates the "Ruby" trademark.
How about changing the name to Gooby?
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.
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.
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 :)