Live data from Hacker News

Goby: A new Ruby-inspired language written in Go

github.com

41–45 of 45 posts

Re: Goby: A new Ruby-inspired language written in Go

#41
post #33
post #29

Earlier quoted context omitted.

> "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…

"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 t…

Goby doesn't have JIT. It just created 6 months ago so we have many things prior to performance improvements. And I'm not a programming language expert so it's too hard for me introducing JIT in my first language.

Re: Goby: A new Ruby-inspired language written in Go

#42
post #10

Earlier quoted context omitted.

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…

>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 i…

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

Re: Goby: A new Ruby-inspired language written in Go

#44

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 PS: Notably, websocket support is still lacking in Goby.

at first glance it appears that goby runs on windows, which is pretty handy.

Re: Goby: A new Ruby-inspired language written in Go

#45
post #33
post #29

Earlier quoted context omitted.

> "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…

"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 t…

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

Post reply on HN