Hacker News new | ask | show | jobs
by meesterdude 3434 days ago
This reinforces what I see a lot too - people creating yet another XYZ, but rarely I see someone go and create an integrated solution to streamline development processes or make things easier or clearer.

There are a lot of vocal people who make it seem like you should be doing everything in Go or Angular or what have you, but I want nothing to do with either, and do not have problems that those are meant to solve. I love ruby, and I love rails.

DHH regularly sounds the drum of rationality - in a community at large of idealists and extremists. He is the reason I got into programming, and constantly serves to remind me that what I'm doing is, in fact, perfectly fine; and that everyone else puts up with a lot of nonsense for no great reason.

There are other frameworks out there, but you'd be hard pressed to find one with a leader that has such a sense of direction and reason for why the framework does what it does, and does not.

4 comments

I am a rails dev. I inherited a legacy application. The biggest problem with Ruby/Rails is that anything Ruby will allow, someone will do. Ruby is the language I learned data structures and algorithms in, built my first significant projects in. It has a generous wealth of helpful builtins. But it makes me long for strictness, static typing, a language where not just anything can completely modify any other.
This. Often, you can't find where this variable or function comes from. You read the sources only to discover that there is no trace of this variable and it is probably defined dynamically in some callback. You can only find this kind of stuff with the help of debugger. The dynamism, which allows one to create beautiful interfaces, and is often advertised as a programmer's friend, is actually the enemy of the programmer who is going to read the code afterwards.
I've actually run into methods defined from names concatenated from multiple strings, i.e. methods you can't even use grep over the whole codebase to find. This has left me with a lingering vague fear ever since.
I've seen worse.

A system that would load chunks of code out of MySQL and eval them in place.

Magic variables with magic meanings... shudder

Sounds like the coder was might have been imitating the idea of SQL stored procedures.
Actually he was imitating Lotus Notes...
that sounds like shitty code - i wouldn't blame ruby or rails for that.

Lots of things are possible - but not everything is a good idea - or is, but could be done in a clearer way.

This.

I used to work at places where we cared deeply about our code. You should see some of the code reviews from one of the places, sometimes they got kinda ridiculous and people got into arguments about coding style and the discussion never ended... But the code was great. I kept it for some time after leaving the job and I looked at it to see how good a Rails project can be. Ah, we had over 90% code coverage from the beginning too.

Without Rails, I don't think that codebase would have been as maintainable as it was.

Then at my next job after that, I was hired as a Rails developer. Rails was a dependency and they used controllers and views and wrote the most insane code I have ever seen. Not that many tests, and the tests we had required a significant amount of setup and no one really knew how to run them (and make them pass).

I'm used to Rails being nice and friendly to work with, so joining a project where they fucked up everything really sucked, because I know what it's like to work in a good rails app.

I feel that ways as well... and I'm loving F# for being easy to write and read and yet giving me algebraic data types which allow me to better to model the domain I'm working in and for forcing me to explicitly demarcate what's mutable and what's not.

You should check out Scott Wlaschin's talk, Domain Modeling with F# if you get the chance. https://vimeo.com/97507575

> There are a lot of vocal people who make it seem like you should be doing everything in Go or Angular or what have you

It might be hard to believe now, but Rails also went through this stage of vocal supporters advocating for it over alternatives. If you go back and watch the introduction video [1], you have DHH creating a blog in 15 minutes using RoR. I remember being impressed by it and vocally pushing for it where I worked then. :)

[1]: https://www.youtube.com/watch?v=Gzj723LkRJY

Crikey that takes me back. Almost 12 years ago! I was 23 then and big-time into .NET but caught wind of this and watched it (hooray for student housing with decent net speeds -- sometimes, off-peak!) with an amused smirk as so much other tech stuff that comes and goes. Funny, this kind of stuff wouldn't raise an eyebrow today, other than "15 minutes to create a blog" in a fresh framework install being perceived as suspiciously cumbersome at best! ;) do realize that it was a much needed breath of fresh air back in the day for what was the widespread "LAMP stack" (linux/apache/mysql/php for ye young'uns) ..
> There are a lot of vocal people who make it seem like you should be doing everything in Go or Angular or what have you

Can you give examples of the 'lot of vocal people' saying 'you should be doing everything in Go or Angular'? I don't see this. I only hear this kind of black/white sentiment when filtered via junior devs.

Experienced devs I know get there are trade-offs. And I don't see anyone on the React/Angular/Vue teams saying that server-sidey Django/Rails/etc. apps are 'wrong'.

At least once a week I read comments or a submission about how X should be written in Rust. That's a pretty common occurrence here; if you stay long enough it'll be another language.
Before Rust it was Haskell, before Haskell it was Erlang, and before Erlang it was Lisp.
I've seen a lot of Rust posts on HN lately, but none saying you must ditch mature frameworks like Rails for Rust equivalents (there aren't any yet, and they know that, for one).

Where's the evidence for this claim DHH/Rails is the only rational force in a sea of extremists?

(Of course the dull reality with real apps is "it's complicated" and most devs are busy grappling with that).

> Rails for Rust equivalents (there aren't any yet, and they know that, for one)

... Can we please call it Rusty Rails?

Do you have any examples?
I mean it sounds rational until you realize that modern rails apps are a perfect example of the complexity you want to avoid.
> modern rails apps are a perfect example of the complexity you want to avoid

Nope. This is a misnomer that get's passed around a lot, and it's not based on anything factual. It's also dangerous, because people will read that and think "oh, i guess rails is bad". but it's not.

When you leverage the framework and best practices, it's great. There are different styles that can make things more complex, sure - but that's by no means the fault of rails.

People can go overboard at any level of the stack - rails won't stop you from this. Things can get sloppy and not perform efficiently - or become convoluted. again - not the fault of rails.

Sometimes, you need a little magic. Ruby (and rails) makes this possible. But if you rely heavily on magic, it'll bite you in the end.

This. Legacy codebases convinced me that good languages / frameworks are the ones you can do many things in.

But the great ones restrict how you can do those things down to a few patterns (in a way that doesn't actually seem like a restriction).