st0012

I’ve been building cctop for over 4 months and never stopped improving it as I migrated between harnesses. It now supports Codex desktop/cli, Claude desktop/cli, opencode, and pi. It’s the only app that allows users to monitor these harnesses sessions at the same time without putting them into the same session manager app.

Can you elaborate what sustainability and openness do you mean to here? Do you mean disclosing usage of AI tools in the project’s maintenance and development?

These are the Ruby libraries that already adopted Prism: https://rubygems.org/gems/prism/reverse_dependencies

syntax_tree was actually created before Prism. Ruby LSP also adopted syntax_tree first, and then switched to Prism (then called YARP) when it was mature enough.

But indeed, the type completor would've been much harder to build and maintain if without Prism.

In 2017, I wrote a toy language called Goby[1] to learn how Ruby works. A few folks contributed quite a bit to it and one of them later referred me to my previous job (as a backend developer).

Fast-forward to 2021, I got interested in debugging tools so I started contributing to the then newly created Ruby debugger[2]. In less than a year I opened more than a hundred PRs and became the 2nd biggest contributor of it. And that eventually landed me a job to work on Ruby's development tools, like LSP servers, REPLs, and of course, the debugger :-)

[1] https://github.com/goby-lang/goby

[2] https://github.com/ruby/debug

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

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

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.

Thanks!

I think Go does good work at concurrency support, so using it can save me a lot time dealing with concurrency.

And in my opinion Go is simple to learn, which can make others contributing it more easily. For example, this is only my second Go project, and most of Goby contributors haven't written any Go code before (of course I spent some time guiding them).

The last reason is that I think Go has a relatively big community and ecosystem. It'll be more easy for me to finding resources.

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

Goby does reverse, using Go package as plugin. See: https://goby-lang.gitbooks.io/goby/content/plugin-system.htm...

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/

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

Hello, I'm Stan, the project's creator. A few months ago Goby(Rooby) was posted on Hacker News. I got many feedbacks and said that this language is aim at help developing microservices. To achieve the goal I also said that it'll have built in multi-threaded server and better thread system.

Now me and my team did all these features, and released version 0.1.0. We built a sample website in 100% Goby and it works. Currently Goby's new goal is to let developers access Go object and packages without writing any Go code.

BTW here's the monkey source code I wrote when I practiced with the book https://github.com/st0012/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.

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.

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

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