Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Compile Ruby to C

github.com

Post reply on HN
Print view View original

31–40 of 110 posts

Re: Show HN: Compile Ruby to C

#31

Post by calineczka »

survili wrote: post #26
samtheprogram wrote: post #25

Earlier quoted context omitted.

I can echo this sentiment. I want to love Ruby, but when I work in project in it, I eventually get to point where I have trouble finding where something is defined, which wastes my time — and in general, to your point, it’s harder to find where anything that’s getting pulled into a file is defined. Unfortunately, this dynamism is a concept in Ruby that is part of the reason why it’s so great. However, recently I star…

Come on, use Rubymine or any other smart editor to find definitions..

Rubymine is fantastic most of the time. But when projects use too much DSLs and 'magic', nothing helps.

Re: Show HN: Compile Ruby to C

#33

Post by pjmlp »

m12k wrote: post #30
pjmlp wrote: post #27

Nice effort, but I think contributing to Crystal would be better spent.

I maintain a 4 year old rails code base. I'm not going to be porting it to Crystal - but if I had an easy way to get ~5x speedup of the most performance critical parts of my code, I would jump at the opportunity. I'm glad someone is working on this

In that case, why not JRuby or TruffleRuby?

4 year old Rails is probably fully supported on them.

Re: Show HN: Compile Ruby to C

#34

Post by pjmlp »

altdatathrow wrote: post #23
bfieidhbrjr wrote: post #9

I'm sad Ruby has been, or is, left behind by python. There are lots of little reasons but no real big one. I just love ruby. I love little things like 'unless'. I know it's still with us, but still feels a little sad.

Thorsten Ball's writeup [1] on the architecture behind Unicorn is one of the single most informative pieces I've ever read about fork-based multiprocessing, signals, and pipe-based ipc. The information there can be applied to any platform and, imo, is a must-read for anyone operating in a *nix environment. [1] https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-...

How is it any different from when Apache 2.0 got introduced?

Re: Show HN: Compile Ruby to C

#35

Post by 02020202 »

bfieidhbrjr wrote: post #9

I'm sad Ruby has been, or is, left behind by python. There are lots of little reasons but no real big one. I just love ruby. I love little things like 'unless'. I know it's still with us, but still feels a little sad.

im not fan of ruby but python was on its death bed and it came back to life only because of "data science" and "machine learning" since it was wasier to write it in python than in some compiled language and so it exploded since every big tech jumped on it right away and here we are. never say miracles don't happen :D

ruby has nothing to offer so it was left behind. maybe possibility to take your old code and ccompile it into C and gain massive performance will put ruby back on map, but i would not count on it. ruby was just a sillicon valley favourite pet that's no longer the case so i would not keep my hopes up for a big return.

Re: Show HN: Compile Ruby to C

#36

Post by bauerd »

pjmlp wrote: post #33
m12k wrote: post #30

Earlier quoted context omitted.

I maintain a 4 year old rails code base. I'm not going to be porting it to Crystal - but if I had an easy way to get ~5x speedup of the most performance critical parts of my code, I would jump at the opportunity. I'm glad someone is working on this

In that case, why not JRuby or TruffleRuby? 4 year old Rails is probably fully supported on them.

TruffleRuby cannot run real-world Rails yet. JRuby does not always yield the perf improvements one would expect

Re: Show HN: Compile Ruby to C

#37

Post by ClikeX »

d3nj4l wrote: post #4

Looks great - but since you mention you're inspired by Sorbet, why not use their type annotations instead of rolling your own with Rubyspeed::T? (I don't know too much about C, so this might be obvious to some) Otherwise, I'm excited to try this out. I don't really have any performance-sensitive ruby personal projects, but with time and improvements pushing this to a production-ready state this could be a lifesaver i…

Or the .rbs files that are supposed to come at Christmas.

Re: Show HN: Compile Ruby to C

#38

Post by Lio »

samtheprogram wrote: post #25
hetman wrote: post #22

Earlier quoted context omitted.

I still think Ruby is the more interesting and expressive language. However, for me there's a single pain point that means Python wins in any larger project. That is the behaviour of Python's "import" vs. Ruby's "require". So it's not surprising that this distinction between these languages pops up all over the place. Python tries to be as explicit as possible. While "from import *" is possible it is heavily frowned…

I can echo this sentiment. I want to love Ruby, but when I work in project in it, I eventually get to point where I have trouble finding where something is defined, which wastes my time — and in general, to your point, it’s harder to find where anything that’s getting pulled into a file is defined. Unfortunately, this dynamism is a concept in Ruby that is part of the reason why it’s so great. However, recently I star…

This doesn’t answer all of your points but in terms of finding out where something is defined you can turn a method into a Proc and then ask it. Eg

  some_instance.method(:foo).source_location
There’s a similar method for source definition. Both are useful dealing with over use of meta-programming.

Re: Show HN: Compile Ruby to C

#40

Post by vidarh »

pjmlp wrote: post #27

Nice effort, but I think contributing to Crystal would be better spent.

Crystal is not a Ruby. They're doing things that are intentionally different, and it's totally put me off considering it.

In practice 99% of the time plain old MRI is fast enough for the things I do. The rest of the time, resorting to RubyInline or a C-module has usually been more than enough.

E.g. the bulk of my code for my masters that involved heavy use of k-nearest neighbour implementations etc. for pre-processing image files for OCR was written in Ruby, with only ~2-3% then replaced with RubyInline C-code to get the speed needed.

I'd take that over Crystal any day, as I don't like the places where Crystal diverges.

Post reply on HN