Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Compile Ruby to C (github.com/agrafix)
153 points by agrafix on Sept 21, 2020 | hide | past | favorite | 109 comments

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.

> The obvious performance and bloat overhead with RoR aside.

Does the bloat matter in the end tho?

You can build a million dollar business on a single $20 / month DigitalOcean server to run everything with tens of thousands of users. That's what Chris did from https://gorails.com. We talked about his Rails driven tech stack on the Running in Production podcast[0].

Recently he tweeted out he generated a million dollars from his business[1].

If you can get 100ms or less p95 response times without a complicated infrastructure then the only thing that matters is the ecosystem, community and how much you enjoy using that technology. If performance is a web framework's biggest feature then I think they're fighting an uphill battle. Performance isn't that important for most applications as long as you can produce a nice feeling application that responds quickly. All modern frameworks have a means to do that. Now it comes down to how fast can you build it and how nice is it to maintain.

[0]: https://runninginproduction.com/podcast/12-learn-ruby-on-rai...

[1]: https://twitter.com/excid3/status/1295730795148193792

I guess it depends on what you build. At the scale of GitHub and Twitter or Shopify there are probably significant challenges caused by said bloat.

But once you reach that level of scale you have (or should have!) the resources to redevelop services that are holding you back. Not choosing Rails because you intend some day to get to Twitter scale smells of premature optimisation. (Twitter themselves used Ruby!)

Yep, which is generally why I can't see a good argument for not using it. I was hoping to see some here but it seems to be a consensus view.

I would argue that there isn’t a framework in existence that is actually built to cleanly scale to the size of any of those companies. If there is one that claims to, it is probably lying.

I have had to help scale a large scale Rails app and break it apart about 5 years ago. 500k requests per minute. That was tough. A lot of the features that Shopify and Github have upstreamed since then would have helped a lot and to be honest it is a lot easier to scale now with Rails because of those upstreamed features. Like multiple databases, viewcomponents, etc.

The weird thing is we have to keep semi-apologising for choosing Rails. Why is that? For each his own. I love Rails, sue me.

I am all for your love of Rails, but tools should not be picked based on how much you love them. Choose the correct tool for the job, if it is rails, good for you.

For me its Rails, also because I love it. None of us is 100% objective or rational about this. I'm very much aware most companies can be built with any of the common stacks, the tech barely matters for 90% of these companies. Why does it mater if advertisement algo company X or insurance tech company Y choose java/.net/ruby/php ? All these stacks are good enough and have been used countless times in varying scales.

For example if you are building something around nlp, probably pick python.

Also, since you are all into ruby, maybe take a look around as to why other languages exist.

There's a solid question as to why the tool you'd pick for CRUD databasey stuff should be coupled to what you'd pick for NLP heavy lifting by the interpreter. Different jobs, different tools.

That's quite a specific use case and as a mainly backend web developer I don't hit many nlp problems. That's usually a whole specialisation of it's own.

> maybe take a look around as to why other languages exist.

I've been around. Still like Rails, works well for me. Thanks for the advice :)

Depends why you love Ruby. If you love it because you adore programming languages with red logos then yes, bad choice. But if you love it because it lets you work quickly and performs well then that is a reason to pick it.

Not to mention, if you’re a solo developer or a small team, picking a language everyone knows and likes absolutely is a good reason. It’ll save you a lot of time.

I can list some good qualities I love about Ruby, but I don't know if that's gonna be a great answer. It just clicked with me and analysing it too much is futile. Kinda like analysing why you love your friends is futile: sure, you can list some good qualities. But you could also list good qualities of people who aren't your best friends. It just so happens sometimes a person or a tool clicks with you, it's being in the right place at the right time with this tool. I can see why C# or Python make sense for people. But they haven't clicked with me so they're not my friends. We have no history together.

Now I'm not saying you can't ever grow out of your friends (or languages), I just haven't outgrew Ruby.

I'm sure if joel loves rails, it must be working for him.

If it didn't, surely he'd hate it, no?

No. You can continue to build everything with the language you love. But there are cases where a certain thing is just easier to get done in a particular language. And there is nothing about hating any language.

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

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

I can't speak to Phoenix, but I've looked into Rocket and don't understand how it can really be compared to Rails. There's so much you need to implement yourself that you'll end up spending a big chunk of time on implementing things that Rails (or high quality / well used gems in the Rails ecosystem) can provide for free. And don't get me wrong, I'd love to sit down and do that work, but my job is to make stuff work and make it work quickly, and my employer doesn't hire enough people that we can afford to dedicate that kind of time when it's already "solved" by a framework.

I tend to work on projects where the requirements change constantly, and they're never really "done." Saying rails is good for "prototyping" is not wrong, but in a world where software is always evolving, the features and capabilities that make Rails great for prototyping are also great for just day-to-day existence.

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

As a person maintaining multiple Rails codebases approaching a decade in age: RoR just bitrots incredibly fast and its really difficult to catch or update.

With each new version of RoR gems just stop being compatible without replacement, and its a fairly significant effort to migrate everything to the new shiny being introduced. In fairly stable projects where there isn't much feature churn/replacement, you pretty much have entire sections of the codebase that never move past the version they were originally written in. You're constantly maintaining controllers/models written in RoR 3.2/4/4.2/5/5.1 styles since its incredibly difficult finding which features were used, but they still kinda sorta mostly work, until they silently don't.

The difference compared to other frameworks/languages is that Rails is very heavily powered by "magic". Every other tech explicitly configures and calls features being used, but Rails is mostly held together by "convention", but convention evolves. How do you search for things like "the filename of this must match the class name of this" or "the method name must match this database feature". Nevermind the metaprogrammed methods that aren't documented anywhere. The convention evolving as developer preferences changes is generally a good thing and keeps RoR from becoming too dated but it is an expensive maintenance burden.

I quite like Rails and it's still my first choice for personal projects/prototypes. But I'm definitely souring to it for long running professional work.

It's mostly the "magical" parts like before/after hooks. When you are tracing a bug and are trying to do step-by-step debugging, it has been hell. Quickly jumping to definitions? Even RubyMine can't do it.

Furthermore, as the project grows, you need to introduce something more/bigger than MVC and people put these files everywhere. Sure it's a management problem but it doesn't help that people don't do the right thing by default.

In general, there's a breaking poing that you will very soon hit when you try to just pile things on top.

    It's mostly the "magical" parts like before/after hooks. 
I dislike a lot of the "magic" in Rails, but don't find before/after hooks very "magical" at all.

I guess when you get into inheritance perhaps. When you have an inheritance chain, which hooks are firing and in which order? That gets confusing fast. But, that also doesn't feel Rails-specific at all to me.

Rails gives you some ways to shoot yourself in the foot, but what language/framework doesn't?

    When you are tracing a bug and are trying to do step-by
    -step debugging, it has been hell.
I don't find this too much of an issue. It may be primitive but I just rely on debug output statements.

I have an expansion set up in my text editor that spits out `Rails.logger.debug("[jbootz] ")` and then I just do `tail -f log/development.log | grep jbootz`. I also have iTerm set up to highlight any lines containing "jbootz", so it stands out when it's mingled in with other output. (I just picked "jbootz" as it's a unique string)

In general that's the strategy for Rails debugging or really any dynamic language where the editor/IDE can't reason about the code like it can with a static language.... lots of debug output and then get a little creative with how you filter it in your terminal.

Helps to use an terminal app like iTerm that lets you use split panes so you can look at multiple filtered views of your log output at once if you like.

    Quickly jumping to definitions? Even RubyMine can't do it.
Yeah. I used to work in C# + Visual Studio + Resharper and oohhhhh boy, I often miss being able to lean heavily on the IDE/compiler.

Still, as far as definitions go? I don't know. I just grep for "def foo" (if I don't know what file it's in) or use my editor to jump right to the file where it exists (if I know where it is, which is usually the case)

Not as slick as the editor/IDE actually being smart, but I don't really find it to be a friction point.

> I have an expansion set up in my text editor that spits out `Rails.logger.debug("[jbootz] ")` and then I just do `tail -f log/development.log | grep jbootz`. I also have iTerm set up to highlight any lines containing "jbootz", so it stands out when it's mingled in with other output. (I just picked "jbootz" as it's a unique string)

... that seems unnecessarily complicated compared to using byebug, or hell, the RubyMine debugger.

I should have been clearer.

I use pry/byebug extensively as well.

There are times when I prefer debugging via debug output statements and times when I prefer interactive debugging.

I agree Rails only does a great job on structuring when project is started

But any large enough project needs rules for placing files/classes

I don't see how Rails failed in that way

I do agree there are some "magical" stuff like hooks that can be easily abused and introduce bad coding habits/patterns

Wish I can turn them off per class (not for the whole app since they are still sometimes useful)

Yeah. MVC is not always the right tool for the job, but it's generally fine and IMO rarely a terrible fit.

I don't see how that's a Rails-specific problem.

Before Rails, working in the wild and wooly world of Microsoft web dev (with occasional PHP thrown in) I saw some real horrorshow web apps. People hacking together their own confusing and misthought architectures. And those horrorshows were rule and not the exception.

The standardized structure of Rails apps is such a breath of fresh air. It's so nice to step into a Rails codebase and basically know where most things are most of the time.

Admittedly it's also nice to step away from Rails for smaller, simpler apps.

What do u use outside Rails and how was your experience? It's a bit embarrassing I only did Rails with Ruby.

Before Rails I did a lot of work where there was no framework comparable to Rails, in ASP "Classic" and then ASP.NET.

Generally each web app had its own organizational structure. Everything was still "page-based" so your site's file structure would mirror the actual URLs: the code for your product page would be "/product.asp" and your shopping cart page would be "/cart.asp" or whatever. Those files had intermingled markup and code extremely similar to ERB files in Rails.

Conscientious developers of that era would of course extract as much functionality as possible into shared include files. Even in those savage days we tried to separate logic and presentation whenever possible. Early PHP dev worked much the same way.

Needless to say this generally lead to spaghetti code. You certainly could make very maintainable ASP/PHP sites, with a lot of effort -- just like you can find some very maintainable and well-structured shell scripts. But, even so, each "well-structured" ASP/PHP site would have its own structure and it was quite a learning curve jumping into a new one, if you ever had to look at somebody else's code.

Early ASP.NET apps used an even more bizarre set of Microsoft constructs. Code-behind files, etc. Yuck.

Later came ASP.NET MVC which was quite good IMO. It borrowed liberally from Rails which was a good thing.

In Ruby land I developed with both Sinatra and Rails. Sinatra is great and a lot of fun, but you are totally on your own w.r.t. structuring your app. Once your Sinatra app grows past a certain complexity, you will generally just find yourself reimplementing large parts of Rails and encountering the same problems w.r.t. structuring your app.

Rails and MVC are not perfect -- many say other variations like MVVM/MVP/etc are better. Perhaps so. I've certainly had pain points with Rails (too much "magic", high RAM usage) but as far as structuring my applications.... no.

I think there are probably a large number of people who "learn Rails" without really learning the deeper/unique concepts of vanilla Ruby. For me at least it was like a decade in between first writing some Ruby and really feeling like I've started to understand the full scope of the language and syntax that's available to me, such that I'm only now able to start thinking about what cool actual-things I can build with these concepts.

In your experience, is there good resource for discovering the "de-facto" hex packages for a particular requirement - I end up Googling things like "Phoenix paperclip equivalent" and then evaluating all the various ones.

Alternatively are there some good "kitchen sink" open source projects that implement many of the typical web application features like auth, uploads, etc. ?

Companies like thoughtbot have been a gold mine of information and battle-tested practices - is there anyone similar in the Phoenix space that's worth following?

Sadly there aren't many better ways. For the moment the best course of action is to search on ElixirForum. Even if I love the language and still look for ways to work with it (in my new job where it isn't used) I recognize that the ecosystem is not that big.

For auth, the core Elixir team has made one prototype but I am not sure if they'll pursue it further. Outside of that, use Pow. For file attachments: Waffle. Authorization: CanCan, although the area has several very solid options, I heard.

Discoverability can indeed be a problem. Covid-19 hit everything pretty heavily and Elixir's community is no exception. Just a month ago people started finally hiring for it again (on the forum).

Time for a respin of https://www.ruby-toolbox.com/ ?

edited to delete as i was discourteous.

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

This answers your question indirectly. I’ve included a link below to Amber Web Framework, built on Crystal. Crystal is a statically typed language with the speed of C and the exact same syntax as Ruby.

Check out the video a couple screens below, and you’ll see a demo of how quickly an Amber Blog App is generated. You’ll notice their is almost no difference between Rails syntax and Amber syntax.


> the exact same syntax as Ruby

I would be very careful with that statement, because it's simply not true (example: no type-related syntax in Ruby).

Is there anyone notable using it in production?

Digital Ocean is a sponsor according to the website, so maybe that counts.

Spring Boot Kotlin is worth giving a go. It has rapid prototyping abilities, but underlying Java promise of easy refactoring, great tooling. I recently refactored entire frontend and parts of backend code without ever having to restart server.

While I wouldn't exactly put it in the Rails category, I love Spring Boot far more. I love Micronaut even MORE than Spring Boot... but that's another story.

Spring Boot doesn't tick ALL the Rails boxes (Scaffolding a backend CRUD admin interface, all of the complex templating stuff - although Thymeleaf is pretty darn good) I'd put my money on it being more maintainable a year later. Spring as an ecosystem is huge, so there's always a strong possibility someone else has already solved the problem you're trying to solve. The tooling is pretty fantastic as well. Kotlin as a language is just fantastic.

How is the ecosystem? For example - if I want to add auth, social login, profile picture and admin dashboard CRUD, are there mature packages that can be leveraged for these features?

It has decent support. It is based on sprint which has had social auth for many years now. Plus good third party support like okta.

Note to self - dont post about Java on HN, people downvote even non hateful comments!

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 in production for computationally heavy parts of a rails codebase.

I think it's possible, mostly didn't go down that route to keep things as simple as possible at first.

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

The amount of new languages and "the absolute best framework" makes me think that big enterprises should never leave Java. Fancy project written on a newest tech is legacy before it is published. Scary from the business point of view. Disclaimer: I love Ruby.

Or use JRuby. :)

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.

> Keep Ruby as it is - slow and expressive.

Why not try to make Ruby faster without changing how expressive it is? I don't think this project does that by the way - it breaks Ruby semantics - but let's aspire to make Ruby faster.

> If you need to speed up, get faster hardware.

If your code is still too slow for your required per-request latency on a top-of-the-range Xeon and your individual requests have no useful parallelism and are not memory or IO bound... where do you go from there? Where are you getting faster hardware from?

Sometimes there is no faster hardware.

Ruby is getting a JIT in 3. So it's happening. I'm always supportive of small projects and this is no exception. Still, it is going to get crowded out by the generalized offerings of Ruby 3.

There may be some benefit to ultra specialized for this project to live in still but the audience is going to be quite niche.

> ...If you need to speed up, get faster hardware.

So if I need to speed up my Rails application on a AWS, GCP or Azure instance, you're telling me in order to increase performance, I need to upgrade to hardware that is able to take at least 4 to 6+ GB of RAM, to modern hardware on each of the servers I have to make it go faster?

Not only that it will still be slow, very expensive and an unnecessary waste of money (Given the absolutely huge cloud costs), it shows that it doesn't scale efficiently to save on costs at all. Oh dear.

This is like saying, "Can you please get a new laptop with 16GB RAM to let my hungry electron apps eat the RAM it wants?, 4GB RAM is not enough and literally causes starvation."

EDIT: To downvoters: Oh so the high overhead and heavy resources of a Rails app and upgrading your instances to new hardware and more RAM requirements is justified with the extremely high cloud infrastructure costs then? Explain your reasons if this is the case.

By the way, I don't want to see your gigantic operating costs if you're running Docker & Kubernetes on a multi-instance Rails stack.

You could use a few DigitalOcean VPS for your rails app server and pay a lot less than the on-demand pricing that the GCP/AWS/Azure folks will charge.

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

You should really read that article. Just below the fold:

> Everything is fast for small n. When n gets large, that's when things start to go sideways. The above graph of an ancient Trash-80 clobbering a semi-modern DEC Alpha is a sobering reminder that the fastest hardware in the world can't save you from bad code.

> Imagine going all in

> "a basic proof of concept"

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 don’t really think it’s so much that Ruby has declined in popularity (although Rails has), but that Python has exploded as it moved from Academia into data science and ML which are really big right now.

Ruby only ever has one big ecosystem (web development), whereas Python has expanded into several.

But Ruby isn’t going anywhere, so no need to be sad. It’s still a joyful scripting language, and its community is alive and well :)

I used to watch rubygems.org rss to keep myself in the loop. Nowadays it is a deserted wasteland. Many previously popular gems never updated and thus do not work on newer versions of ruby.

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 upon. The Ruby culture doesn't seem to have such qualms; things are often much more hidden and magical. It can make navigating larger projects... even your own... difficult and inefficient.

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 started a project with Ruby, thanks to language servers. I’m hoping this solves that issue, but it’s too soon to say.

There’s still other issues with the require mechanism, and Ruby in general, and other languages to try, e.g. Elixir and Crystal. I haven’t been sold yet in terms of what Ruby excels at, and those languages are each different in their own right.

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

There’s a similar method for source definition. Both are useful dealing with over use of meta-programming.

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

> However, recently I started a project with Ruby, thanks to language servers

What do u mean exactly?

Language servers provide generic autocomplete and other language-specific functionality (e.g. rename a method, find all references to a symbol within your project, find where a symbol is defined, etc) to any editor that supports them. The reference implementation is VSCode, so if you use VSCode you can definitely use language servers, but now that’s it’s picking up steam, support is getting added to other editors, e.g. see vim-coc.

The Ruby language server in question: https://solargraph.org/

Interesting. Do u know what Rubymine is using ? it's own in-house solution?

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

I've been using Ruby in IntelliJ for nearly a year now at my new job. Up until literally the very most recent version of it, this has definitely not been enough to be able find some methods.

Like, ... 'move' or 'read', or some other horribly overloaded function that is the one that I need to go and find the specific implementation of because it's busted.

You need more than just Rubymine in many cases.

And no, sometimes it's quite difficult to get the exact configuration required to get that code path to figure out what's wrong.

I was fairly unhappy with RubyMine 4-5 years ago, when I last worked in Ruby long-term. Glad to hear it’s gotten better. I’ll have to revisit it, especially if there’s a CE for RubyMine.

To GP: there weren’t at the time any other options for a Ruby “smart-editor” AFAIK. However, like I mentioned in my comment, I’m giving Solargraph [1], a Ruby language server, a try, which is equivalent.

1: https://solargraph.org/

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

Maybe this experiment of mine is the kind of thing you’d be looking for


While I feel sad too, I think the primary reason why it imploded under its own weight was the "magic". I still love Ruby, for all its developer friendliness and the consistency of its idioms. But too much of that sugar leads to bloat, that requires a bunch of hair-pulling for newbies to grok.

Now of course, there exist other simpler frameworks (a la sinatra), but when your posterchild is a thing like Rails, you can't expect people to not be burnt in the long term and still come back.

I recently started using Sinatra for side projects and it’s an absolute pleasure. It’s simple and reliable. I think it should get a lot more recognition.

Ruby is a good little language, I used it quite a bit for time. Rails is a horror that I've run from whenever possible.

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?

What? My comment was praising the blogpost.

Ruby is changing. I doubt it will ever be as big as the Python world, but I can see it coming back into fashion. I’ve been paying attention to the community and it’s still very active.

I think there's a lot of burnout in the JS ecosystem, and many are looking for the efficiency of Rails. However, I'm not certain if Ruby on its own is gaining more of a foothold. For a few years it looked like you'd seen more Ruby generalists with tools like Chef and Puppet, but I think Docker has taken a lot of wind out of those sails.

And then Rails 6 came along and brought NodeJS by way of Yarn and WebPacks. I'm still pretty light on deep Rails knowledge (currently doing my first non-toy project with it), but I was not pleased to see that this pile of bloat now appears to be a requirement.

It's the default and you can opt-out.

If you're interested in front-end performance, having a webpack build pipeline for your frontend assets is quite useful, especially if you want to leverage libraries like react or vue and build interactive reusable components, or leverage existing ones.

Tree shaking, minification, chunking, splitting, etc. will help you deliver a faster initial page load, which is a better overall experience and is also factor in search ranking for your public pages.

Front-end engineering has changed because users expect interactive experiences. Rails has an opinionated way to solve this differently using turbolinks and Rails UJS. A very significant proportion of folks don't want to go that route, enough for it to become the default.

>Chef and Puppet

And Vagrant.

Rails jobs are still plentiful. I don't see what's gonna wipe them all out in the coming 10-20 years. Especially if you live in North America, Rails is still super popular. But yes outside Rails there's mostly devops for Rubyists.

Have you looked at Crystal?


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.

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.

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?!?!"

Yeah, this. With Python -and I love Python, don't get me wrong, it got me a job- I find myself doing more tasks that feel boilerplate-y and bureaucratic. Ruby is a language that I'd call "delightful", in that a lot of annoying things are easy and intuitive.

This feeling is one of the only things I've found to help keep hobby programming fun while also working full-time as a programmer. I am happy to let everyone at $work favor us writing Python for this reason :)

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.

For practical use, how does this compare to crystal?

Those are probably not for the same use case. Crystal is a whole another language, and you'd have to migrate your whole codebase there. This (in my understanding) is more for compiling certain heavily used functions in your otherwise Ruby codebase to get a quick performance boost.

Doesn't the new ruby JIT already do the same thing?

It's certainly related -- not sure what kinds if specialisation the new ruby JIT does.

I haven't looked into the new ruby JIT too deeply, but as far as I remember it had several limitations that made it slow Rails apps down instead. This would make it easier to select and optimise for specific methods instead.

Current Ruby JIT doesn't take any type hint.

Yeah, this is pretty much how the JIT works.

Reading this thread makes me feel like i have been transferred back to 2009-2010.

Am enjoying the nostalgia quite a bit :)

I wish there would C to GO compiler, that would make my day.

c to go transpiler exists https://github.com/elliotchance/c2go

i have discovered it just today, lol. but it kind of works and mostly not, unfortunately. it would be AWESOME if Go core team would implement something like this into Go itself, since Go is just better C anyway, with GC. that would revolutionize the programming world, i think. i still dont understand why we dont have transpilation between the major languages being something one does not even have to think about, it just IS and WORKS.

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.

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

Fair enough.

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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact