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

Ruby on Rails Audit Complete

ostif.org

Post reply on HN
Print view View original

141–150 of 171 posts

Re: Ruby on Rails Audit Complete

#141

Post by notjoemama »

throwawaymaths wrote: post #53
demosthanos wrote: post #41

Earlier quoted context omitted.

In the grand scheme of things, if we're considering everything from web to bridge building, yeah, the distinction is small. But within the world of software engineering specifically it's not all that small and it's worth being precise when we're talking about it. Whatsapp and telecoms have a lot in common, so no one questions that they benefited a ton from the BEAM. Airbnb, though? The main similarity is that they bo…

no. in the modern web world you often have persistent client server connections, which make it a distributed system out the gate. the most inefficient way to deal with this is to go stateless, and without smart architecture to deal with unreliable connection, it's really your best choice (and, it's fine). since BEAM gives you smart disconnection handling, web stuff built in elixir gives you the ability to build on cl…

> in the modern web world you often have persistent client server connections

Is this actually true though? I’d be interested if you know any data backing that perspective. I only know what I’ve worked on and my anecdotal experience doesn’t match with this statement. But I know my sphere doesn’t represent the whole. In terms of state, by now there are many ways of dealing with persistence and reconnection. Not only are most of those problems solved with existing technologies and protocols but they’re everywhere in web dev. Maybe we’re talking past each other? Did I misunderstand your point?

Re: Ruby on Rails Audit Complete

#143

Post by inopinatus »

Some good recommendations. Feedback on this one:

> "X41 recommends to disallow the creation of un-escaped SqlLiteral objects with user input in favor of a complete model of SQL"

Rails already has a sufficient model of SQL in its Arel layer. Complete? Not exactly, because SQL is never implemented by the standard, but certainly sufficient, and very composable and extensible. Sadly the core team killed off the public documentation of Arel a few majors ago. Nevertheless I still use Arel whenever Active Record doesn't expose enough of the model, such as expressing left-open intervals as inequalities¹. Sometimes incorrectly called a "private API", but it's not anyone's private possession, Arel is just undocumented in recent releases.

The recommendation's language is also just a touch naive, because it's nigh-impossible to outright disallow developers doing practically whatever they want to in Ruby, there's no isolated sandbox. The question is what incentives are in place to stop them wanting to.

Active Record already has excellent support for bound values via the predicate builder, and it's only egregiously bad code that concatenates raw user-supplied values directly into query strings. Nevertheless for those few remaining places in the API where this could happen inadvertently such as #calculate, a variant recommendation - similar in spirit, but not identical - might be that where it doesn't already, Active Record treats raw strings supplied as requiring escape unless explictly wrapped with Arel.sql(), or just accept an Arel node/AST (many already do on the QT). That is, force the developer to confess their sin in writing, or do it relationally.

But IMO the wizards shouldn't keep Arel locked up in the tower, either.

[1] https://gist.github.com/inopinatus/c84c78483b30fb2d5588db9be...

Re: Ruby on Rails Audit Complete

#144

Post by josephg »

inopinatus wrote: post #143

Some good recommendations. Feedback on this one: > "X41 recommends to disallow the creation of un-escaped SqlLiteral objects with user input in favor of a complete model of SQL" Rails already has a sufficient model of SQL in its Arel layer. Complete? Not exactly, because SQL is never implemented by the standard, but certainly sufficient, and very composable and extensible. Sadly the core team killed off the public do…

> The recommendation is also a touch naive as framed, because it's nigh-impossible to outright disallow developers doing practically whatever they want to in Ruby

Sure but defaults matter.

Nothing is truly private in most languages. In C/C++, you can poke raw memory. In rust you can transmute. In Java you can override the classloader and edit classes before they’re passed to the JVM and so on. But most environments have a golden path for getting things done which most developers will walk. This is exactly what removing documentation does - it signals to developers that some API isn’t part of the expected golden path.

Every sql library needs ways to pass raw sql strings to the database. (Just as every browser framework needs a way to embed raw html strings). But it should require you to explicitly acknowledge you’re doing something unsafe. Rust’s unsafe keyword. React’s unsafelySetInnerHTML, and so on. It’s not about denying it. It’s about making the obvious thing safe and the unsafe thing not obvious.

Re: Ruby on Rails Audit Complete

#145

Post by poisonta »

poisonta wrote: post #81
kybishop wrote: post #18

Earlier quoted context omitted.

After programming with elixir and phoenix for a few years (with many prior years of rails experience) I have a hard time seeing why one would choose rails. Elixir is more performant, has compiler safety guarantees that are only getting better as types are introduced, is actually designed from the ground up for web dev (being based on the Erlang VM), and... it's just way more fun (subjective I know). Elixir is what I…

Elixir is a great language, but it lacks a framework as polished and full-featured as Rails. Phoenix could have been far more popular if it had something like Active Record.

Many Rails developers try Phoenix at some point because they may need better performance. They’re so accustomed to the Rails structure that they assume Rails has done everything right. However, Ecto and ActiveRecord are two very different beasts. When Rails developers try out Ecto, they often feel there’s too much boilerplate and believe the Rails design is much more intuitive. This, I think, is one reason Phoenix struggles to attract Rails developers. If it can’t please Rails users, it will rarely appeal to others.

Re: Ruby on Rails Audit Complete

#146

Post by pmontra »

kybishop wrote: post #122
pmontra wrote: post #99

Earlier quoted context omitted.

Ecto was literally the component I liked less in all the Phoenix stack when I worked with it after a dozen of years of Rails. I did maybe 5 years of Phoenix for a customer of mine and went back to Rails for another customer. It's good enough and overall Rails is easier to deploy IMHO. Capistrano vs I don't remember what.

Oh man, this must just be subjective because I find Ecto to be beautiful compared to the absolute trainwreck of Activerecord. Having compile time guarantees through Ecto is wonderful.

Yes, that must be the case because if my customers and I would care about compile time guarantees we would not be working with Ruby.

In that years long Phoenix project one of the developers on the team added dialyzer type annotations to the functions in the files he worked on. Everybody else did not bother. The project ended up with no type checking. The service run and the company did well.

Overall using Phoenix was a good experience. I never used Elixir in any other project and never for my own programs. I use several other languages for my own little scripts, mainly bash, Ruby, Python and Lua. I think that I really like dynamic typing.

Re: Ruby on Rails Audit Complete

#147

Post by vidarh »

IshKebab wrote: post #117
vidarh wrote: post #113

Earlier quoted context omitted.

Learn to use a remote debugger, and how to show the method source location. This may sound snarky, but it's a good faith suggestion. Ruby has all of the tools to make debugging easy, but they're different than what you will expect if you come expecting things to work like in the static typing world. But as much as I love Ruby, I do agree that Rails has too much unnecessary "magic". Much of which more modern Ruby is a…

I mean... that sounds like a pretty horrible dev experience. Every time I want to understand a piece of code I have to actually run it? Insane. For example I'm trying to understand Gitlab's merge train behaviour. Do I have to set up an entire Gitlab instance from source, then create a project, set up CI, run a merge train, all while running Gitlab in a debugger and then set a breakpoint and then finally I can see whe…

In practice it is not. And no, you don't have to run it, but it makes things a lot easier to do so.

And no, you don't need to do what you suggest, you just need to load all the code into a running Ruby REPL.

It is one consequence of Ruby being as dynamic as it is, but another is that the codebases tends to be far smaller. Anywhere from half to 1/10th of the size of codebases in statically typed languages is my experience, including with direct translations.

Re: Ruby on Rails Audit Complete

#148

Post by IshKebab »

vidarh wrote: post #147
IshKebab wrote: post #117

Earlier quoted context omitted.

I mean... that sounds like a pretty horrible dev experience. Every time I want to understand a piece of code I have to actually run it? Insane. For example I'm trying to understand Gitlab's merge train behaviour. Do I have to set up an entire Gitlab instance from source, then create a project, set up CI, run a merge train, all while running Gitlab in a debugger and then set a breakpoint and then finally I can see whe…

In practice it is not. And no, you don't have to run it, but it makes things a lot easier to do so. And no, you don't need to do what you suggest, you just need to load all the code into a running Ruby REPL. It is one consequence of Ruby being as dynamic as it is, but another is that the codebases tends to be far smaller. Anywhere from half to 1/10th of the size of codebases in statically typed languages is my experi…

> load all the code into a running Ruby REPL

That counts as running it if you ask me. And I don't see how just loading the code would help you find the callers of a function?

> Anywhere from half to 1/10th of the size of codebases in statically typed languages is my experience, including with direct translations.

That sounds highly implausible.

Re: Ruby on Rails Audit Complete

#149

Post by jupp0r »

camcil wrote: post #32
ukprogrammer wrote: post #12

The productivity of Rails for B2B 'CRUD' software is unmatched. Surprised to not see more newer startups make use of it!

What caused the drop in popularity in RoR? It seemed like ~10-12 years ago RoR was the de-facto startup standard. On any given day there were multiple items on the HN front page having something to do with RoR.

> What caused the drop in popularity in RoR?

Async/await. JavaScript and all other modern languages and frameworks have a great concurrency story. Rails still hasn't (but it's coming next year, it's been coming next year for a decade).

Re: Ruby on Rails Audit Complete

#150

Post by jupp0r »

mrinterweb wrote: post #91
camcil wrote: post #32

Earlier quoted context omitted.

What caused the drop in popularity in RoR? It seemed like ~10-12 years ago RoR was the de-facto startup standard. On any given day there were multiple items on the HN front page having something to do with RoR.

Around that same time, microservice architecture was the new hot. Rails apps tend to be monolithic. Now that many people have realized that microservice architecture is often not worth the complexity costs, monolithic apps are back in fashion, and people are rediscovering how great rails is.

Rails is in steady decline [1].

[1] https://trends.google.com/trends/explore?date=all&geo=US&q=%...

Post reply on HN