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!)
Goby: A new Ruby-inspired language written in Go
21–30 of 45 posts
Re: Goby: A new Ruby-inspired language written in Go
#22sorry but the ruby community now has something called Elixir.
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.
Re: Goby: A new Ruby-inspired language written in Go
#23Are threads both concurrent and parallel (like goroutines)? In other words can they be used to parallelize CPU-heavy computation?
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 slow…
> 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 didn't downvote you, so i'm not sure, but maybe it was because of the condescending tone (assuming what they care about from a simple question and telling them what they should care for instead), aaand not answering their question about parallelism in the first place.
Re: Goby: A new Ruby-inspired language written in Go
#24Earlier 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. (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 slow…
> 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 didn't downvote you, so i'm not sure, but maybe it was because of the condescending tone (assuming what they care about from a simple question and telling them what they should care for instead), aaand not…
I didn't assume, the question contained "CPU-heavy", and the answer is relevant because it's a common misconception that you can make up for a slow language with parallelization, but you can't. If you've got a CPU-heavy task, you will find in practice that even using a lot of threads you'll be lucky to get even a 3x speedup on clock time, unless your problem is 100% strictly embarrassingly parallel. (I've tried a few times, which is where the 3x comes from. It's all I was able to get and my tasks were very close to embarassingly parallel, but the cruel nature of Amdahl's law is that it takes only very slight non-parallel components to wreck your speed.) It's not a viable solution in practice.
Re: Goby: A new Ruby-inspired language written in Go
#25Are threads both concurrent and parallel (like goroutines)? In other words can they be used to parallelize CPU-heavy computation?
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 slow…
Didn't downvote, but perhaps a request for clarification; perhaps you could cite some benchmarks for these numbers? Esp. The 100-500x speed loss for interpreted languages.
Re: Goby: A new Ruby-inspired language written in Go
#26Are threads both concurrent and parallel (like goroutines)? In other words can they be used to parallelize CPU-heavy computation?
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 slow…
But, you may have chosen to use an interpreted language for other reasons. GPs question still makes sense, relative to the other options s/he may consider (like go itself, or ruby)
Re: Goby: A new Ruby-inspired language written in Go
#27Can this be used in a Go app as a plugin/scripting lang?
Goby does reverse, using Go package as plugin.
See: https://goby-lang.gitbooks.io/goby/content/plugin-system.htm...
Re: Goby: A new Ruby-inspired language written in Go
#28sorry but the ruby community now has something called Elixir.
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.
I agree with you. Elixir can help in the web side of things but tasks/non-web in Elixir don't help. I really like Go's offering, but it gives me 4x the pain in developing a solution that ruby does (eg: parsing anything, etc). I would love to simply use a compiled, optimized ruby (like Crystal)
Re: Goby: A new Ruby-inspired language written in Go
#29Are threads both concurrent and parallel (like goroutines)? In other words can they be used to parallelize CPU-heavy computation?
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 slow…
> "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).
Re: Goby: A new Ruby-inspired language written in Go
#30Hi, 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...
Congrats on the release!
I have one question: why Go? I would have expected Rust I guess, or OCaml or something.