Hacker News Reader

Comment by ufmace | Hacker News Reader

I suggest giving Ruby a try too. I find it great for both web dev and local automation scripts. You can do pretty much anything you can do in bash but with clearer and shorter code. I've been writing all my non-trivial automation code in Ruby for years.

Rails is just a popular web framework for Ruby, there's a lot more the language can do.

View on HN

It's annoying to have to install the ruby interpreter onto everything. Go feels a lot like a scripting language, but produces binaries.

Agreed. I recently transitioned from Rails development to devops, and there's no Ruby on any system by default. My Bash got better fast!

Fortunately Elixir/Erlang releases include all the executables you'll need. They aren't quite as slick as Go binaries, which all live in one file, but it's still pretty cool.

This is a hurdle, but IMO it's not too annoying if you already have rights to install packages. Just automate interpreter installation in bash if it's not already there. Way too much time and money is invested in fighting the esoteric crannies of Bourne shell when the logic would be much clearer in Ruby or Python.

Ansible's moment in the sun is fading now that Docker came onto the scene, but that was a glorious moment. It's still very useful for anyone with long-running, non-removable machines. Ansible requires Python and allows a great deal of behavior to be defined in simple YAML instructions.

You might have the right to install packages, but that may not solve your problem, that the application may require different version than available in the repo.

The classical case is Ruby + Rails + Passenger + CentOS. While there is SCL with any Ruby and Rails version you might want, that does not mean, that the Passenger package will work with it :(.

Yeah, if you can install packages, then you can run the RVM installation script and install the right version of Ruby. In fact, you don't even need admin privileges if you use RVM.

That will get you off package system for the entire stack and now the maintenance of the whole circus is up to you. Which is exactly what I'm trying to get away from.

I do dislike individual language package managers and ecosystems for this reason, but I think it's gotta be accepted at this point. Practically every language has their own package repo and versioning apparatus now. Ruby has RVM, Node.js has NVM, Python has PyPi/venv, etc. Most projects expect their users to deploy with these and include things like Gemfiles to define dependencies. That usually means if you insist on using the upstream packages provided by the distribution, you're going to have to install them manually and have a bunch of extra headaches to worry about anyway (to be honest, most custom applications are really difficult to get running using only distro-packaged Ruby or Python libs).

The individual language package managers are very nice for development, as you may have any package version you want, and also for non-linux users, where there may be no native package management at all. For operations, however, they suck mightly (that's terminus technicus).

I quite like the SCL [1]. It solves the problem, that you might need different version of node/python/ruby/rails/php/whatever, than is packaged with the OS release of your choice. It has the software nicely packaged and maintained. Now getting third party packages to work with that, that's the problem. Passenger rpm [2] requires system-provided ruby, not just any ruby... I will survive that that App X wants Gem Y installed by rubygem. I won't like it, but it is workable and makes maintenance/updates slightly more difficutlt. But I will not put unpackaged module into Apache config.

[1] https://www.softwarecollections.org/

[2] https://www.phusionpassenger.com/library/install/apache/inst...

Then Python is a good alternative, it's basically already installed everywhere.

'Everywhere' being most Linux distributions, an outdated version (2.7) on OS X, no version at all on Windows.

Go and Python are not even close to being in the same league for performance in a majority of cases.

1: https://www.techempower.com/benchmarks/#section=data-r12&hw=...

2: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

Maybe try Crystal (https://crystal-lang.org/) then. It has many of the benefits of Go and a Ruby-like syntax. It feels even more like a scripting language than Go because of awesome type inference, uses a similar model as Go for concurrency, and even has proper generics ;-)

> I suggest giving Ruby a try too.

If you like Go, I don't see much reason to try Ruby except intellectual curiosity. Ruby is clearly a language on its way out and it is not just a lot slower than Go, it's also dynamically typed.

Why is it 'clearly' on its way out? IMO Rails is still the best web framework around, and the last release has really put it ahead of its closest competition.

Not really,

https://www.techempower.com/benchmarks/

I wasn't making a statement about performance. That has very little to do with most web development.

On my little part of the world, performance always plays a role in web development.

It is even described in many of the project contracts.

Until you have users. :-P

For one example, check this comparison: https://dockyard.com/blog/2016/08/09/phoenix-channels-vs-rai...

Ruby is too forgiving, has multiple syntaxes for the same thing, and lets people do really obscure shit in a large codebase (monkey patching, hidden imports, etc). In short: it enables developer laziness.

I've found Ruby code the hardest to debug over the years. Also, I think the web development community is waking up to the value of type safety.

I will use Ruby for the occasional script because I like its backtick syntax for invoking other commands, but that's it.

I can't speak to this. I'm a Go and Python programmer. I learned Go in about ~8 hours and have been very productive with it over the past 2 years.

I've been struggling at work to learn and use Rails for the better part of a year. I constantly have to grab someone and have them help me. Either I'm an idiot, or Rails has a bigger learning curve than people make it out to have because I've never experienced this in all my 10 years of programming professionally.

I'd second this. Rails is still probably the fastest way to get an MVP off the ground, and most of the time it's more than fast enough. You can get UX on par with a well done SPA almost entirely using server code with Turbolinks 5 + Action Cable, too.

The fastest way to get an MVP off the ground is to use the tools you know best. It doesn't have to be Rails :)

Yes, this is also usually true. But if you don't know tools that are particularly well suited for the job, or you just don't like them and are looking for something else to try, I would put Rails at the top of the list for productivity. (For most use cases)

The only problem is that you need to maintain and enhance that MVP for the next several years -- unless it's just a hackathon.

I've spent way too much of my life trying to optimize Ruby performance and memory usage, switching from one web server to the next, then fixing threading issues in dependencies, and so on. It's not fun. All that upfront productivity is lost in the end.

Quite happy to spend more time upfront investing in a reliable end-product.

Agreed on popularity but Kickstarter is slow and memory is still expensive. Shorter code isn't always a good idea when most Rail and Ruby developers can't tell between APIs.

Swift is by far being the best all-rounder language and between the fastest and slowest.

Reply on news.ycombinator.com