Live data from Hacker News

Show HN: Compile Ruby to C

github.com

41–50 of 110 posts

Re: Show HN: Compile Ruby to C

#41

Earlier quoted context omitted.

I was intrigued by it for a while. I can remember the jokes from years ago that it should be renamed the Rails programming language. I find it a shame when an otherwise interesting language gets pigeonholed into single framework.

For sure. Ruby is great for things other than rails, like automation, writing server scripts, and of course small api servers/web sites using sinatra. I use it all the time and still haven't actually done anything with Rails. The last thing I wrote in Ruby was a script to help manage my email inbox using imap.

I've worked with Ruby for ~15 years now, and I've used Rails maybe 2 of those and it was the worst experience.

I think Rails really was a very mixed blessing for Ruby - on one hand it brought a lot of people. On the other hand it associated the language with a whole lot of practices that has done long term damage.

Re: Show HN: Compile Ruby to C

#42

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.

I also love Ruby, it's all the little things. It helps me along and makes me happy every time I manage find a solution to a problem. "Woah! Can I really do it just like this?!?!"

Re: Show HN: Compile Ruby to C

#43
Imagine going all in on a Ruby project with this specialized library that literally changes the way you write Ruby and still thinking that's a good idea.

Keep Ruby as it is - slow and expressive. If you need to speed up, get faster hardware.

Re: Show HN: Compile Ruby to C

#44
The obvious performance and bloat overhead with RoR aside, I have yet to see a framework and ecosystem that lets you have a programmable web application up and running with typical features in comparable time.

For shipping new products or testing out ideas, I have not come across a more optimal framework in terms of going from idea to market.

Most often I've tried Phoenix, Django and Laravel as alternatives, but all of them seem to fall short. I gave .NET MVC a shot too back in its early days, it was not pleasant.

I run a dev shop and it seems to fit really well with our business model.

Re: Show HN: Compile Ruby to C

#45

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.

I have exact the same thing with Coffeescript. First left behind because apparently most Javascript dev's think ESx is now better than Coffee. And after that they joined the strict typing frenzy.. I hope the next front-end/node language will be a little more joyful.

Re: Show HN: Compile Ruby to C

#46
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…

Elixir is much more explicit compared to Ruby in terms of "where is X?" and its compiler apparatus (and user-available hooks and tooling) is getting expanded in 1.11 which is landing soon -- but to be 100% objective, some libraries utilize macros where alias/import/require might be used, which obscures things sometimes.

The tooling still catches all dependencies and their sources though (via `mix xref ...`)

Re: Show HN: Compile Ruby to C

#47
post #44

The obvious performance and bloat overhead with RoR aside, I have yet to see a framework and ecosystem that lets you have a programmable web application up and running with typical features in comparable time. For shipping new products or testing out ideas, I have not come across a more optimal framework in terms of going from idea to market. Most often I've tried Phoenix, Django and Laravel as alternatives, but all…

This is what brought me to RoR land... and this is what made me leave.

I agree rapid prototyping is an excellent point for RoR but when you need to actually evolve the project for years, it gets really tedious and hard.

So for a dev shop RoR is quite fine -- you make the project, do very little iteration on it, and ship. That works well and I've experienced it.

For longer-lived projects however, Phoenix is miles ahead. Even Rust's Rocket, but only if you are willing to invent a lot of stuff yourself (auth for example).

Re: Show HN: Compile Ruby to C

#48

Imagine going all in on a Ruby project with this specialized library that literally changes the way you write Ruby and still thinking that's a good idea. Keep Ruby as it is - slow and expressive. If you need to speed up, get faster hardware.

Faster hardware costs money. If this works well, and it stops being a PoC, why pay extra when you can simply add an annotation to a method, and your speed gain is free?

Re: Show HN: Compile Ruby to C

#49
post #44

The obvious performance and bloat overhead with RoR aside, I have yet to see a framework and ecosystem that lets you have a programmable web application up and running with typical features in comparable time. For shipping new products or testing out ideas, I have not come across a more optimal framework in terms of going from idea to market. Most often I've tried Phoenix, Django and Laravel as alternatives, but all…

This is what brought me to RoR land... and this is what made me leave. I agree rapid prototyping is an excellent point for RoR but when you need to actually evolve the project for years, it gets really tedious and hard. So for a dev shop RoR is quite fine -- you make the project, do very little iteration on it, and ship. That works well and I've experienced it. For longer-lived projects however, Phoenix is miles ahea…

What makes you say it is hard to maintain longer lived projects? (I used to be a RoR developer for a few years, so I'm curious about other people's experiences.)

Re: Show HN: Compile Ruby to C

#50
post #48

Imagine going all in on a Ruby project with this specialized library that literally changes the way you write Ruby and still thinking that's a good idea. Keep Ruby as it is - slow and expressive. If you need to speed up, get faster hardware.

Faster hardware costs money. If this works well, and it stops being a PoC, why pay extra when you can simply add an annotation to a method, and your speed gain is free?

The thinking is that faster hardware is cheaper than developer time. E.g.: https://blog.codinghorror.com/hardware-is-cheap-programmers-...
Post reply on HN