23 ms·

Rails is not written in Ruby

222 points by tanyar 5y ago

anandvc 5y ago
ActiveSupport is a core part of Rails though.
- steve_adams_86 5y ago
  I think this is the author's take on that: https://solnic.codes/2022/02/02/rails-is-not-written-in-ruby/#but-many-methods-from-activesupport-are-now-in-ruby https://solnic.codes/2022/02/02/rails-is-not-written-in-ruby... Not sure this is what you're getting at. I agree with the author though, this aspect of Rails bothered me quite a bit. Knowing that working on a Rails project meant I could magically generate ranges from dates because of ActiveSupport was unsettling - it made me wonder what else was non-native behaviour and waiting to trip me.
  - jon-wood 5y ago
    I just can’t bring myself to get worked up about it - I’ve done a lot of Rails, and I’ve done a lot of pure Ruby. You quite quickly learn which bits come from ActiveSupport when you step outside Rails because… it doesn’t work. It’s not going to trip you up in 8 month’s time after shipping your code, you’re just going to get an exception when you first try to run it, and then either implement it the pure way or add a dependency on ActiveSupport.
    - steve_adams_86 5y ago
      Those are good points. I should say it's not really ActiveSupport that concerned me the most so much as the possibility of other people on my team monkey patching stuff in a similar way, but with much lower quality code. It's almost like all the common dangers of bad programming exist, plus a bunch more at a lower level. I totally recognize that it's also a strength of ruby. I really enjoyed working with it. It's super expressive and clear to read. ActiveSupport is all really well documented and designed too, and I'm not trying to criticize it. After re-reading my comment I'm noticing I was specifically targeting Rails as well. I think if anything Rails does a great job and shows why this is a cool thing about ruby. I think what I should have said is that this aspect of ruby is what I found off-putting and specifically in a context where I'm relying on a vast number of dependencies, coworkers of various skill levels, and shipping code to customers. Does that make more sense? I didn't express what I was thinking very well before.
  - jacobsenscott 5y ago
    There's nothing magic about it. It is just ruby. And no need to wonder what else is there. It is all documented. All the methods are well named. It is hard to see how they could trip you up. I've been programming for a long time now. I remember when people would read the documentation for the libraries and frameworks they were using. Seems to have fallen out of fashion.
    - steve_adams_86 5y ago
      I read the docs, and I thought it was all well designed too – the issue I took with it is that Ruby is so incredibly dynamic that it looked like a giant foot gun to me. Well, potentially at least. I know it's powerful in the right hands. I'm a lot happier with something like Rust, and it arguably comes down to personal preference. Ruby is awesome and fun to write. I'm not a good enough programmer to make it as productive as others in the long term though, especially when working on a large team.
manquer 5y ago
Prototype modification of global objects in JS provides similar monkey patching capability. Interestingly evolution is very different though The instances of abuse are generally less in mainstream JS libraries, and in many of them such features are usually opt-in or at-least it is possible to still use the lib even when opting out , there is also no major dialect that has privileged rights so to speak.
- choward 5y ago
  The Prototype js library was pretty huge back in the day when monkey patching was all the rage.
  - erichocean 5y ago
    IIRC it was created by former Ruby/Rails developers.
hihihihi1234 5y ago
As a former Rails dev, I've always enjoyed Piotr Solnica's writing. He does a great job of explaining what's wrong with the framework, in particular the flaws that aren't immediately obvious when you're starting out. But these days the main thing I think of when I hear his name is that his blog used to be on a different domain, and he apparently let the old registration expire because someone else has bought it and now it points to a porn site. And tragically, there are still many other sites online which still link to Solnica's outdated, now-pornographic URLs. And that's how I ended up accidentally sharing a porn link in a professional setting.
- widdershins 5y ago
  Somehow this story seems to relate to the author's musings on conflicting monkey-patched libraries. It's all rather beautifully messy.
- solnic 5y ago
  welp :( I'm very sorry about this. I didn't manage to pay for my old domain because I was recovering after an accident (true story, not making any silly excuses). I was aware that it's about to expire but wasn't in a good physical and mental shape and I just forgot to do it. People keep reporting it to me and we're updating URLs every time somebody finds an old link somewhere. I should probably just search through GitHub and send some PRs...
  - hihihihi1234 5y ago
    I hope you updated your resumé!
hprotagonist 5y ago
"and behind every framework, there's a langauge trying to get out, to protect semantic ideas, then syntax ones, and then support the logical ideas that we have" -- Lambda World 2019 - Language-Oriented Programming with Racket - Matthias Felleisen https://youtu.be/z8Pz4bJV3Tk?t=180 https://youtu.be/z8Pz4bJV3Tk?t=180
overgard 5y ago
So like, I guess the thing I don't understand is this: why do people think writing: some_array.has_my_thing() is better than has_my_thing(some_array). ? The former, the extension has so many issues, it messes up namespacing, it's unclear where it came from, etc. etc. The latter is just a function. It's not longer, or complex, it's just more straightforward. I really think things where you extend or override built in types is almost always just a bad idea, because the alternative is almost always just as concise and doesn't confuse everyone.
- fernandotakai 5y ago
  >some_array.has_my_thing() is better than has_my_thing(some_array). ? one of the reasons i prefer python to ruby. sorted(my_thing) will sort anything that can be sorted. no need for monkey patching -- you just call it and, if it can be sorted, it will be sorted.
  - matheusmoreira 5y ago
    In Ruby, anything that can be sorted will respond to sort. So thing.sort will also sort anything that can be sorted. Python does the exact same thing, it just hides it from you using ugly __methods__ that the language itself will call by convention. What determines sortability? "Anything that can be sorted" just means anything that implements the __lt__ method. In Ruby, this method is called <=> and the Comparable module builds upon it.
    - remram 5y ago
      Nothing like sort is hidden in class methods in Python.
      - radlad 5y ago
        That's not true - Python implements sorted by calling `__lt__` on the object: https://docs.python.org/3/library/functions.html#sorted https://docs.python.org/3/library/functions.html#sorted
sparker72678 5y ago
ActiveSupport is one of my very favorite things in the Ruby ecosystem. I can understand why it might not be to someone's taste, but I find the idioms to be generally delightful to use and, in most cases, extraordinarily convenient. But, as always in the Ruby ecosystem, if you don't like it, find the thing that brings you joy!
- x3n0ph3n3 5y ago
  I regularly add activesupport to my Ruby programs that don't use the rest of Rails at all. It's just _so_ convenient.
mmahemoff 5y ago
You can make that argument if you consider a language is more than just syntax. It's an complicated ecosystem, of tooling (compilers, runtimes, repls, IDEs, debuggers), reusable code (libraries, frameworks), conventions (coding styles, idioms, design patterns), and community. I'm not really fussed about dictionary definition debates anyway. I generally use ActiveSupport in personal Ruby projects. It just adds too much value to ignore.
TazeTSchnitzel 5y ago
Rust's traits let you add methods like this to any type without creating a risk of conflicts, because they aren't accessible within a particular file unless you import the trait. (Also I think there's some syntax for disambiguating?)
- remram 5y ago
  The syntax is function-style, e.g. `Trait::method(object)` rather than ` use Trait; object. method()` Or you can cast &object to &Trait.
spyckie2 5y ago
I think this is the beauty of Ruby. The core philosophy of Ruby is that it was designed to make "1.day.ago" possible. That's why DHH fell in love with it and used it to build Rails. You can't do that with many other languages. "1.day.ago" is not really a piece of code, it's a sensibly named shortcut to existing code that already solves easy problems. It's is not designed to be built upon; not all code has to be designed that way. For example: // How to get last day of month? // Javascript var month = 0; // January var d = new Date(2008, month + 1, 0); console.log(d.toString()); // last day in January // monkey patching in ActiveSupport Date.today.end_of_month This is the definition of a great DSL. It abstracts away easy problems so you don't have to solve them hundreds of times and allows you to focus on the more unique problems of a domain. Monkey patching is a powerful tool and just like any powerful tool it should be used carefully. Random monkey patching everywhere is bad, just like polluting the global namespace in javascript is bad. But used well and you can create extremely expressive, powerful, and concise coding experiences. Isn't that the goal of any DSL?
- matsemann 5y ago
  Think that should be possible in Kotlin as well, fwiw. Extension functions and extension properties are nice. And function with receivers make for some nice DSLs. All without monkey patching, which I consider a better way.
- lkjsaofinwdfsdf 5y ago
  This is no longer a testimony of Ruby's strength, or rather this highlights Ruby's age and stagnation. D, Go, C#, Rust, Swift, Kotlin, Scala, Haskell, and (more I'm forgetting) already have this without the hack of monkey patching. If you really find beauty in DSL's you should look into tagless final encoding in Haskell. From what I recall Ruby still doesn't have first-class ADT's. Meanwhile Java will be getting sealed classes (the OO orthogonal to ADTs) with pattern matching.
  - spyckie2 5y ago
    Not to overstate the point, but what many Rubyists want in programming is to mirror their code to a subset of English as much as possible, avoiding the more ambiguous parts of English. This is because if it makes sense in English, it is self documenting, clear, and intuitive. By DSL, I meant an abstract language on top of an existing programming language that serves a domain well and Ruby's monkey patching makes that easy to implement. Haskell's language, with it's custom non English symbols, and functional language with verb object or even operator at the end style... it's like dvorak vs qwerty. Even if it is superior, it's not the preferred one.
ativzzz 5y ago
I think the author's example of time_calc compared to ActiveSupport's 1.days.ago syntax speaks to why ActiveSupport is used so much and that sometimes it's OK to do the wrong thing to make everything else easier. The time_calc API looks just awful to use I'd rather deal with the implications of potential Ruby "magic".
RangerScience 5y ago
> RSpec is our primary example here - a limited and problematic DSL based on monkey-patching was turned into a beautiful, composable DSL which we still have in RSpec. One of my most consistent experiences with Ruby is doing something the "wrong way" - but being able to do, due the language flexibility - and then later coming back to the problem and realizing the better solution, which ends up being more satisfactory and happier in every way. Ruby lets you do whatever you want, however you want, but it makes the right way the most satisfying. Very handy for iterative development.
byroot 5y ago
I think "Jargon" would probably have been a much less controversial term than "Dialect" for expressing this idea. "Dialect" implies that it's a sub-language, but Ruby is still Ruby no matter how many methods you add or modify. Whereas a "Jargon" is a specialized vocabulary, and even sometimes some word change meaning as part of a jargon. But I suppose that when you title your post like this, controversy is actually what you are looking for.
- samatman 5y ago
  The non-composability of ActiveSupport-flavored-Ruby with other Ruby code which tries to use the same approach, is the point of the article. It's that which (the author argues) makes it a dialect, rather than a specific jargon.
  - byroot 5y ago
    Some professional Jargon are non-composable too when they use the same words for different meanings.
ecf 5y ago
Clickbait title
temac 5y ago
And programs written in Lisp are not written in Lisp?
jaredcwhite 5y ago
I understand that if you like Ruby a whole lot and like being a web developer, but you don't like Rails for whatever reasons, it can be a frustrating experience over the long haul. But as a counter-example to that, I'm constantly amazed that there are a ton of Ruby gems out there which pretty much work as advertised outside of Rails (even if Rails gets a privileged happy path during config). Not to mention you can use ecosystem stalwarts like Puma, Rack, Sidekiq, and many other subsystems outside of a Rails app entirely. Heck, you can pull just bits of Rails in if you really need them. Want Active Record for your ORM but nothing else? That's totally possible! (But of course then you get a bunch of Active Support stuff too which is what the author objects to.) Personally I love Active Support and actively (heh) bring it into my Ruby projects if it's not there already. To a certain degree, everything people say is a "bug" about Ruby's metaprogramming/monkeypatching is a feature in my book. The fact that "Ruby core" is simply a substrate upon which you can build your own flavor of a Ruby-plus language—be that "The Rails Way" or something else entirely—is amazing. In that respect, I entirely disagree that Rails is not written in Ruby. Rails shows us how you _can_ (and probably should!) use Ruby to build DSLs which suit your specific application/framework purposes very well. It's not a bug. It's a feature. And it's why most other tools which claim "Rails but for Language X" fall short…they can try to replicate features of Rails, sure—but because it's not Ruby, it misses the whole point of using Rails, which is that you get Ruby "for free" to sweeten the deal! That's the (not so) secret sauce here.
- chrisseaton 5y ago
  > I'm constantly amazed that there are a ton of Ruby gems out there which pretty much work as advertised outside of Rails I must come to Ruby from a very different angle to you - but I don't even really get what you mean. Why would the majority of gems have anything at all to do with Rails or need it to work as advertised? For example the top-ten gems have got absolutely nothing at all to do with Rails have they? https://rubygems.org/stats https://rubygems.org/stats
  - ryeguy 5y ago
    Because the ruby community generally revolves around rails. Stack overflow often has generic ruby questions where answers assume you're using rails (by referencing activesupport, for example). Just to give you an idea, on stackoverflow, there are 222k ruby questions and 330k rails questions tagged.
jacobsenscott 5y ago
Rails is a DSL for building web apps. Ruby is a great language for building DSLs. Building up a DSL to meet your domain needs is a nice way to go. I don't think this is a problem at all, and very much in the spirit of both Ruby and Lisp (from which ruby takes a lot of inspiration). I believe Ruby's open classes were also a reaction to the locked down libraries that were common to Java. They were impossible to extend and resulted in a rats nest of adapters, visitors, and every other pattern in the book. In Ruby the programmer is in charge, not the library authors. The ability to do 1.day.ago was not just cute, but revolutionary, and huge productivity boost for anyone coming from C, or Java, or C# - the predominate languages of the time.
resters 5y ago
It would be one thing if Rails was the only gem that depended on ActiveSupport. The problem is that other authors use it because they initially expect their library to be used with rails. And then, if someone chooses to use the library without rails, all of ActiveSupport must be brought in as a dependency (which is ugly). I think DHH's aesthetic intention with ActiveSupport was for it to be used by Rails, not used by a random assortment of gems throughout the Ruby ecosystem and misunderstood by a lot of people. FWIW, ActiveSupport is one of the main reasons why I stopped using Rails a while ago. The other was that version updates typically have a LOT of API changes that make staying up to date quite a drag (or source of tech debt).
jeppester 5y ago
I totally agree with this. This situation where a library has a de facto monopoly on monkey patching is just weird an unfair. It reminds me a bit of MS's good old EEE strategy. People get comfortable with ActiveSupport to a degree where they start disliking to not have it's small benefits. But the consequence of this behaviour, that most are oblivious to, is that it to a large degree puts Rails in control of the language. ActiveSupport feels like a leftover from the old days of prototype and jQuery. You search for a solution and half the answers on SO will assume that you are using it (and many of the answer authors don't even know it) I'm sure it's not going to happen, but I think Rails should stop using ActiveSupport internally. It would allow devs to decide for themselves if they want to pollute the standard library, and also open the door for competition. While the syntactic sugar of "1.day.ago" is hard to match, I don't think an alternative have to be that bad "ActiveTime.days_ago(1)"
lamontcg 5y ago
Grepping this article there isn't one word about Refinements: https://docs.ruby-lang.org/en/3.0/doc/syntax/refinements_rdoc.html https://docs.ruby-lang.org/en/3.0/doc/syntax/refinements_rdo... Those are similar to C#'s Extension methods. That way consumers of the Refinement can opt-in to the extended functionality without injecting their methods globally into the class for every bit of code running on the VM. There's a good reason that ActiveSupport as a "Monopoly on Monkeypatching" which is that nobody should be doing it any more. ActiveSupport largely gets a pass because it is pretty well defined and engineered, bits of it get pulled into core ruby, and its the 800# gorilla out there because it is rails. You shouldn't copy that pattern, and you shouldn't want to. Use refinements instead.
- inopinatus 5y ago
  I like the refinements mechanism too and it is most certainly underutilized, but the lexical scope makes it an incomplete substitute, and somewhat problematic during reflection.
  - chrisseaton 5y ago
    I'm not an expert but I believe the lexical scoping was a last-minute save by Charlie Nutter to preserve performance! Dynamic scoping of method definitions is seriously hard to optimise, and I'm not sure anyone knows how to do it. Do you really need dynamic? Why isn't lexical enough?
    - inopinatus 5y ago
      To clarify, I don't need it, and I'd agree that any library interface using monkeypatching could in principle be redesigned to use refinements. What I'm suggesting is in practice, I suspect it's doubtful anyone would undertake the exercise of reframing ActiveSupport (and thereby the entire Rails ecosystem) to use refinements instead of core extensions.
      - lamontcg 5y ago
inopinatus 5y ago
The last time I offered a Rails PR that extended core classes, it got a thumbs down review on that basis alone. Solnic's complaint is often voiced, and has merit for all the reasons given (and more besides IMO), and Rails is certainly stuck with ActiveSupport, but the core team does not seem keen on exacerbating the problem. Additions to ext modules are, consequently, rare, and in fact there's a trend going the other way, e.g. https://github.com/rails/rails/commit/33ca3923170a50da7f173165f7b8ba20fcd32803 https://github.com/rails/rails/commit/33ca3923170a50da7f1731...
simonw 5y ago
Back in the first era of the JavaScript library was this was one of the big differences between Prototype and jQuery. Prototype added a whole bunch of new methods to the built-in JavaScript objects. It also defined $ as an alias for document.getElementById. jQuery added nothing to the built-in objects, but did also use $ as an alias for the jQuery function. Something I really liked about jQuery was that it included a noConflict() function, which you could use to avoid it interfering with Prototype. Doing this: jQuery.noConflict(); Reset the $ back to whatever it was before jQuery was loaded. If you wanted to keep using $ in your jQuery code you could use this elegant idiom, which registers your code to run when the page content has loaded: jQuery(function($) { // Within this block $ is an alias of jQuery });
kirillzubovsky 5y ago
Although in principle the author is probably correct, what I don't understand is the value of his argument. Instead of saying ActiveSupport is bad, use native Ruby, why not take all of that time, energy, and more importantly understanding of the ecosystem and make AS better. When giving directions, we don't say: "please proceed forward for 17.84 ft, while reducing your speed, come to a complete stop, and then gently accelerate while turning 90 degree." We just say: "go to the corner and turn right." Certain abstractions and improvements to the way we communicate make a lot of sense. Why fight it? Sounds like the author has the perfect mix of skills to improve the core of Ruby to a point where it's useful by the rest of us who don't know and don't have the time.
- kirillzubovsky 5y ago
  p.s. Thanks to the author for pointing out how much non-core stuff there's in AS. Forced me to go read the docs, to find out how much awesome stuff I am not using, but should!
b33j0r 5y ago
Every python developer agrees with this article RE: Django. In the US, it’s like trying to talk to someone from the deep south versus Maine.
maple3142 5y ago
JavaScript supports monkey patching by modifying prototype objects too. But it is considered to be bad practice because it modify the behavior globally, and some method name conflict may cause trouble. An example is Array.prototype.contains couldn't be added because it will break another library, so it is renamed to Array.prototype.includes. (Source: https://github.com/tc39/proposal-Array.prototype.includes https://github.com/tc39/proposal-Array.prototype.includes)
e12e 5y ago
Rather than rails not being written in ruby, I would say that rails extends ruby. Rails is written in ruby, but rails isn't used by ruby - your rails (-using) project is implemented in the language of rails. And it's mostly fine, but the cavalier attitude to meta programming and lack of namespacing is a problem. And not just convenient (but ultimately insane) stuff like 1.second.ago - but also in core rails. On a current project interfacing with a legacy database, I've encountered tables with columns named "table_name" and "changes" - both of which are shadowed by ActiveRecord itself. But even with the crazy, it does make starting a project right, quite easy. Tests are set up, and with rails 7 you can finally opt out of most of the crazy js/css tooling and still have a nice front and backend stack.
montroser 5y ago
> 1.day.ago This type of shenanigans always rubbed me the wrong way. Like, are we saying that "1" has a property, "day"? Conceptually that makes no sense, right? And "day" having a property "ago" is bogus as well. So then, is it just a cute "let's make it read like a sentence" trick? One time a colleague was trying to tell me about this trick, and I opened up a ruby interpreter to see what he was talking about. I typed in "1.day.ago" and pressed enter and it gave some error message. A day later he came back and told me how he was surprised to learn that the trick only worked if you had ActiveRecord in the mix. To me, that's all downside. Sneaky and confusing that loading an ORM adds magic properties to your _numbers_. And, the properties don't even make sense. The worst part of it all is: how in God's name are you supposed to find out where these magic properties and methods sprinkled all up into everywhere -- where did they come from, so you might read their docs, or read their source? It's madness!
- Spivak 5y ago
  I think the interpretation makes a lot of sense actually. number.day -> timedelta timedelta.ago -> current time minus delta 2.months.from_now 3.months.after 2.days.ago 1.day + 2.weeks Given the choice between Time.now.advance(years: 2) and 2.years.from_now in a language that uses idioms like 1.step(to: 10) {|x| print x } I think it's totally natural.
  - montroser 5y ago
    Sure, the terseness is nice, and it is possible to learn this interface and make sense of it, but to me it still seems like abusing OOP paradigm in a way that conflicts with reality. Abstract of any programming language, the concept of "2" has the properties that it is an integer, that it is a natural number, that it follows "1", that it is prime, etc. But it doesn't have a property "years". From another perspective, back to programming, if "years" and "step" make sense as properties of "2" then does _any noun_ make sense? Is it cool for every library to monkey patch its own domain's worth of nouns to be properties of every number? 2.centimeters, 2.users, 2.widgets? I can get with natural expressions for date math, but how about something more like Time("2 years from now") Then I can read that to mean we are constructing a time, described by the parameter.
jupp0r 5y ago
Rails itself depending on ActiveSupport, that's the problem. If users were to be able to use ActiveSupport or not, depending on their preferences all would be well. Imho there isn't a good reason for Rails to depend on the monkey patched ActiveSupport parts and it could be factored out into less magicky functions inside Rails.
andreareina 5y ago
There's a third option: explicit opt-in of extensions, with better support for finding where .whatever() is defined. Gets you ergonomic helpers where they're beneficial, scoped to just the modules you pull them into. Too late for Ruby but this is how Rust traits work right?
andrewcarter 5y ago
I've felt a lot of the same frustrations on iOS projects with swift. Lots of people add tons of extensions and helpers, and folks learning on these codebases don't learn iOS, they learn the playground that the developers of the project made, it's not obvious what's built in and what's custom. The extensions are less composable, harder to navigate, and often end up really ramping up complexity when you end up with constraints and generics and protocols and all kinds of really fancy "nerd stuff" that really isn't needed in an iOS codebase. I used to have a theory that folks did this because, well, Apple has basically "solved" what make an app is. Everything you need is there, it's all pretty easy to use, it's "boring" in a good way. Maybe this is how developers scratch the itch of needing to do a lot of "real programming"? Maybe I'm just getting old!
draegtun 5y ago
> This unique feature of Ruby has been leveraged by DHH back when he created Ruby on Rails framework This isn't unique to Ruby and is possible in other languages. For eg. in Smalltalk you could create this DSL... 1 day ago.
iovrthoughtthis 5y ago
Just wanted to say that the authors libraries, especially ROM [0], are incredible and have played a huge influence on me as a developer. I learned a lot using and diving through the code. [0]: https://rom-rb.org/ https://rom-rb.org/
- solnic 5y ago
  Ah thanks man, I'm very happy to know this. ROM 6.0 is going to be a major improvement Stay tuned!
masa331 5y ago
Why there always have to be somebody telling you arbitrarily what's right or wrong even for such a harmless and creative things such are a programming languages or concepts and why i always open articles like that even that i know how bad it makes me feel. I really wish i will finally remember this next time and i will spend the time coding hapily instead, sometimes with ActiveSupport, sometimes not, maybe even with Dry-whatever, if i'm able to overcome Solnic's negative agendas.
- solnic 5y ago
  What makes you think I have negative agendas? My "agenda" is quite positive, I want a Ruby ecosystem where we play by the same rules and Rails is no longer a special snowflake. This way we can evolve faster.
  - masa331 5y ago
    Your articles are very negative. Basically everything involving Rails is bad and wrong by them. That's what i mean. I want Ruby ecosystem, where everybody is free to do their things the way they want, by the rules they want, for whatever motivations they have. I want to have my special Rails snowflake and i don't want it to ever change because it constantly enables me to build amazing things AND enjoy the process also. And i'm willing to let you have your way and i will respect it but only if you can do the same without being negative about it in every other statement. If somebody chooses to support Rails and Rails only in their library i think it's very fine and i think the same if there is a library doing the same thing for only Hanami. Or a library supporting both. Or a library not really supporting anything in a special way. I also think it's fine when there is a library which sole function is to monkey patch Object with #forty_two method. And fine it is because there are no rules from you or anybody else forcing me to actually use this thing. So, i will just not use it, right? So for me this open and free "we" is the only "we" there is and also the only one i want to evolve anyhow.
    - solnic 5y ago
      > Your articles are very negative. Basically everything involving Rails is bad and wrong by them. That's what i mean. I provide critique that some (probably many) Ruby developers don't like and disagree with but my intention isn't to bash something and make it "all bad". I don't recall saying that everything involving Rails is bad and wrong. I had conference talks sharing my appreciation for Rails and various parts of its philosophy that I agree with and try to incorporate in my own projects. There are also things I don't like that are very problematic and I share this with the community as well. > I want Ruby ecosystem, where everybody is free to do their things the way they want, by the rules they want, for whatever motivations they have. Imagine a ruby gem that becomes super popular because it provides some neat features that plenty of companies can benefit from. Then, for whatever reason, this project introduces some great performance optimizations but they are achieved through monkeypatches. Unfortunately it turns out it breaks Rails in some weird, subtle ways, that are hard to debug. Rails core teams starts getting lots of bug reports about some seemingly unrelated problems, just to realize that it's not a problem in Rails, it's a problem in another library. Does this make any sense? Nope. That's why people don't monkeypatch in their libraries. From what I gathered, there's some initiative to move Rails to use Refinements via ActiveSupport, if this happens, then the problem is solved. > And i'm willing to let you have your way and i will respect it but only if you can do the same without being negative about it in every other statement. It's interesting that you mention respect here - ActiveSupport doesn't respect the rest of the ecosystem. By simply adding new methods to Kernel, Object, NilClass, it reserves them and you really want to avoid having same methods in your library. If you want to tell me "but nothing prevents you from doing this" then you're right, except that I have to think about this because if my lib doesn't work with Rails well, I might as well not build it in the first place because adoption would be non-existant.
solnic 5y ago
FYI I changed the title to "Rails and its Ruby dialect". Thanks for all the comments. https://solnic.codes/2022/02/02/rails-and-its-ruby-dialect/ https://solnic.codes/2022/02/02/rails-and-its-ruby-dialect/
herbst 5y ago
I love Ruby and until I started to earn money with it as in a normal job I refused to touch rails. It felt wrong as someone used to pure ruby, Sinatra, and the whole syntax philosophy behind it. I had the luck to work with one of the Rails Devs in my work place and really learned to love it, the thing that makes rails great really is the structure. Taking over a 10 year old rails project written by a newbie? Well not to big of a problem. Taking over the same project by someone who knows rails is always a pleasure. Like you know exactly where a bit of code would be found, it doesn't feel like taking over legacy depts but like a fun new adventure to explore. As web dev who used to work with PHP before that was mind blowing. In the PHP world every bit of code was different enough that everything 'legacy' was something nobody wanted to work with. It's less about the dialect but the smart structure and MVC

222 points by tanyar 5y ago

anandvc 5y ago

ActiveSupport is a core part of Rails though.

steve_adams_86 5y ago
I think this is the author's take on that: https://solnic.codes/2022/02/02/rails-is-not-written-in-ruby/#but-many-methods-from-activesupport-are-now-in-ruby https://solnic.codes/2022/02/02/rails-is-not-written-in-ruby... Not sure this is what you're getting at. I agree with the author though, this aspect of Rails bothered me quite a bit. Knowing that working on a Rails project meant I could magically generate ranges from dates because of ActiveSupport was unsettling - it made me wonder what else was non-native behaviour and waiting to trip me.
- jon-wood 5y ago
  I just can’t bring myself to get worked up about it - I’ve done a lot of Rails, and I’ve done a lot of pure Ruby. You quite quickly learn which bits come from ActiveSupport when you step outside Rails because… it doesn’t work. It’s not going to trip you up in 8 month’s time after shipping your code, you’re just going to get an exception when you first try to run it, and then either implement it the pure way or add a dependency on ActiveSupport.
  - steve_adams_86 5y ago
    Those are good points. I should say it's not really ActiveSupport that concerned me the most so much as the possibility of other people on my team monkey patching stuff in a similar way, but with much lower quality code. It's almost like all the common dangers of bad programming exist, plus a bunch more at a lower level. I totally recognize that it's also a strength of ruby. I really enjoyed working with it. It's super expressive and clear to read. ActiveSupport is all really well documented and designed too, and I'm not trying to criticize it. After re-reading my comment I'm noticing I was specifically targeting Rails as well. I think if anything Rails does a great job and shows why this is a cool thing about ruby. I think what I should have said is that this aspect of ruby is what I found off-putting and specifically in a context where I'm relying on a vast number of dependencies, coworkers of various skill levels, and shipping code to customers. Does that make more sense? I didn't express what I was thinking very well before.
- jacobsenscott 5y ago
  There's nothing magic about it. It is just ruby. And no need to wonder what else is there. It is all documented. All the methods are well named. It is hard to see how they could trip you up. I've been programming for a long time now. I remember when people would read the documentation for the libraries and frameworks they were using. Seems to have fallen out of fashion.
  - steve_adams_86 5y ago
    I read the docs, and I thought it was all well designed too – the issue I took with it is that Ruby is so incredibly dynamic that it looked like a giant foot gun to me. Well, potentially at least. I know it's powerful in the right hands. I'm a lot happier with something like Rust, and it arguably comes down to personal preference. Ruby is awesome and fun to write. I'm not a good enough programmer to make it as productive as others in the long term though, especially when working on a large team.

manquer 5y ago

Prototype modification of global objects in JS provides similar monkey patching capability. Interestingly evolution is very different though The instances of abuse are generally less in mainstream JS libraries, and in many of them such features are usually opt-in or at-least it is possible to still use the lib even when opting out , there is also no major dialect that has privileged rights so to speak.

choward 5y ago
The Prototype js library was pretty huge back in the day when monkey patching was all the rage.
- erichocean 5y ago
  IIRC it was created by former Ruby/Rails developers.

hihihihi1234 5y ago

As a former Rails dev, I've always enjoyed Piotr Solnica's writing. He does a great job of explaining what's wrong with the framework, in particular the flaws that aren't immediately obvious when you're starting out. But these days the main thing I think of when I hear his name is that his blog used to be on a different domain, and he apparently let the old registration expire because someone else has bought it and now it points to a porn site. And tragically, there are still many other sites online which still link to Solnica's outdated, now-pornographic URLs. And that's how I ended up accidentally sharing a porn link in a professional setting.

widdershins 5y ago
Somehow this story seems to relate to the author's musings on conflicting monkey-patched libraries. It's all rather beautifully messy.
solnic 5y ago
welp :( I'm very sorry about this. I didn't manage to pay for my old domain because I was recovering after an accident (true story, not making any silly excuses). I was aware that it's about to expire but wasn't in a good physical and mental shape and I just forgot to do it. People keep reporting it to me and we're updating URLs every time somebody finds an old link somewhere. I should probably just search through GitHub and send some PRs...
- hihihihi1234 5y ago
  I hope you updated your resumé!

hprotagonist 5y ago

"and behind every framework, there's a langauge trying to get out, to protect semantic ideas, then syntax ones, and then support the logical ideas that we have" -- Lambda World 2019 - Language-Oriented Programming with Racket - Matthias Felleisen https://youtu.be/z8Pz4bJV3Tk?t=180 https://youtu.be/z8Pz4bJV3Tk?t=180

overgard 5y ago

So like, I guess the thing I don't understand is this: why do people think writing: some_array.has_my_thing() is better than has_my_thing(some_array). ? The former, the extension has so many issues, it messes up namespacing, it's unclear where it came from, etc. etc. The latter is just a function. It's not longer, or complex, it's just more straightforward. I really think things where you extend or override built in types is almost always just a bad idea, because the alternative is almost always just as concise and doesn't confuse everyone.

fernandotakai 5y ago
>some_array.has_my_thing() is better than has_my_thing(some_array). ? one of the reasons i prefer python to ruby. sorted(my_thing) will sort anything that can be sorted. no need for monkey patching -- you just call it and, if it can be sorted, it will be sorted.
- matheusmoreira 5y ago
  In Ruby, anything that can be sorted will respond to sort. So thing.sort will also sort anything that can be sorted. Python does the exact same thing, it just hides it from you using ugly __methods__ that the language itself will call by convention. What determines sortability? "Anything that can be sorted" just means anything that implements the __lt__ method. In Ruby, this method is called <=> and the Comparable module builds upon it.
  - remram 5y ago
    Nothing like sort is hidden in class methods in Python.
    - radlad 5y ago
      That's not true - Python implements sorted by calling `__lt__` on the object: https://docs.python.org/3/library/functions.html#sorted https://docs.python.org/3/library/functions.html#sorted

sparker72678 5y ago

ActiveSupport is one of my very favorite things in the Ruby ecosystem. I can understand why it might not be to someone's taste, but I find the idioms to be generally delightful to use and, in most cases, extraordinarily convenient. But, as always in the Ruby ecosystem, if you don't like it, find the thing that brings you joy!

x3n0ph3n3 5y ago
I regularly add activesupport to my Ruby programs that don't use the rest of Rails at all. It's just _so_ convenient.

mmahemoff 5y ago

You can make that argument if you consider a language is more than just syntax. It's an complicated ecosystem, of tooling (compilers, runtimes, repls, IDEs, debuggers), reusable code (libraries, frameworks), conventions (coding styles, idioms, design patterns), and community. I'm not really fussed about dictionary definition debates anyway. I generally use ActiveSupport in personal Ruby projects. It just adds too much value to ignore.

TazeTSchnitzel 5y ago

Rust's traits let you add methods like this to any type without creating a risk of conflicts, because they aren't accessible within a particular file unless you import the trait. (Also I think there's some syntax for disambiguating?)

remram 5y ago
The syntax is function-style, e.g. `Trait::method(object)` rather than ` use Trait; object. method()` Or you can cast &object to &Trait.

spyckie2 5y ago

I think this is the beauty of Ruby. The core philosophy of Ruby is that it was designed to make "1.day.ago" possible. That's why DHH fell in love with it and used it to build Rails. You can't do that with many other languages. "1.day.ago" is not really a piece of code, it's a sensibly named shortcut to existing code that already solves easy problems. It's is not designed to be built upon; not all code has to be designed that way. For example: // How to get last day of month? // Javascript var month = 0; // January var d = new Date(2008, month + 1, 0); console.log(d.toString()); // last day in January // monkey patching in ActiveSupport Date.today.end_of_month This is the definition of a great DSL. It abstracts away easy problems so you don't have to solve them hundreds of times and allows you to focus on the more unique problems of a domain. Monkey patching is a powerful tool and just like any powerful tool it should be used carefully. Random monkey patching everywhere is bad, just like polluting the global namespace in javascript is bad. But used well and you can create extremely expressive, powerful, and concise coding experiences. Isn't that the goal of any DSL?

matsemann 5y ago
Think that should be possible in Kotlin as well, fwiw. Extension functions and extension properties are nice. And function with receivers make for some nice DSLs. All without monkey patching, which I consider a better way.
lkjsaofinwdfsdf 5y ago
This is no longer a testimony of Ruby's strength, or rather this highlights Ruby's age and stagnation. D, Go, C#, Rust, Swift, Kotlin, Scala, Haskell, and (more I'm forgetting) already have this without the hack of monkey patching. If you really find beauty in DSL's you should look into tagless final encoding in Haskell. From what I recall Ruby still doesn't have first-class ADT's. Meanwhile Java will be getting sealed classes (the OO orthogonal to ADTs) with pattern matching.
- spyckie2 5y ago
  Not to overstate the point, but what many Rubyists want in programming is to mirror their code to a subset of English as much as possible, avoiding the more ambiguous parts of English. This is because if it makes sense in English, it is self documenting, clear, and intuitive. By DSL, I meant an abstract language on top of an existing programming language that serves a domain well and Ruby's monkey patching makes that easy to implement. Haskell's language, with it's custom non English symbols, and functional language with verb object or even operator at the end style... it's like dvorak vs qwerty. Even if it is superior, it's not the preferred one.

ativzzz 5y ago

I think the author's example of time_calc compared to ActiveSupport's 1.days.ago syntax speaks to why ActiveSupport is used so much and that sometimes it's OK to do the wrong thing to make everything else easier. The time_calc API looks just awful to use I'd rather deal with the implications of potential Ruby "magic".

RangerScience 5y ago

> RSpec is our primary example here - a limited and problematic DSL based on monkey-patching was turned into a beautiful, composable DSL which we still have in RSpec. One of my most consistent experiences with Ruby is doing something the "wrong way" - but being able to do, due the language flexibility - and then later coming back to the problem and realizing the better solution, which ends up being more satisfactory and happier in every way. Ruby lets you do whatever you want, however you want, but it makes the right way the most satisfying. Very handy for iterative development.

byroot 5y ago

I think "Jargon" would probably have been a much less controversial term than "Dialect" for expressing this idea. "Dialect" implies that it's a sub-language, but Ruby is still Ruby no matter how many methods you add or modify. Whereas a "Jargon" is a specialized vocabulary, and even sometimes some word change meaning as part of a jargon. But I suppose that when you title your post like this, controversy is actually what you are looking for.

samatman 5y ago
The non-composability of ActiveSupport-flavored-Ruby with other Ruby code which tries to use the same approach, is the point of the article. It's that which (the author argues) makes it a dialect, rather than a specific jargon.
- byroot 5y ago
  Some professional Jargon are non-composable too when they use the same words for different meanings.

ecf 5y ago

Clickbait title

temac 5y ago

And programs written in Lisp are not written in Lisp?

jaredcwhite 5y ago

I understand that if you like Ruby a whole lot and like being a web developer, but you don't like Rails for whatever reasons, it can be a frustrating experience over the long haul. But as a counter-example to that, I'm constantly amazed that there are a ton of Ruby gems out there which pretty much work as advertised outside of Rails (even if Rails gets a privileged happy path during config). Not to mention you can use ecosystem stalwarts like Puma, Rack, Sidekiq, and many other subsystems outside of a Rails app entirely. Heck, you can pull just bits of Rails in if you really need them. Want Active Record for your ORM but nothing else? That's totally possible! (But of course then you get a bunch of Active Support stuff too which is what the author objects to.) Personally I love Active Support and actively (heh) bring it into my Ruby projects if it's not there already. To a certain degree, everything people say is a "bug" about Ruby's metaprogramming/monkeypatching is a feature in my book. The fact that "Ruby core" is simply a substrate upon which you can build your own flavor of a Ruby-plus language—be that "The Rails Way" or something else entirely—is amazing. In that respect, I entirely disagree that Rails is not written in Ruby. Rails shows us how you _can_ (and probably should!) use Ruby to build DSLs which suit your specific application/framework purposes very well. It's not a bug. It's a feature. And it's why most other tools which claim "Rails but for Language X" fall short…they can try to replicate features of Rails, sure—but because it's not Ruby, it misses the whole point of using Rails, which is that you get Ruby "for free" to sweeten the deal! That's the (not so) secret sauce here.

chrisseaton 5y ago
> I'm constantly amazed that there are a ton of Ruby gems out there which pretty much work as advertised outside of Rails I must come to Ruby from a very different angle to you - but I don't even really get what you mean. Why would the majority of gems have anything at all to do with Rails or need it to work as advertised? For example the top-ten gems have got absolutely nothing at all to do with Rails have they? https://rubygems.org/stats https://rubygems.org/stats
- ryeguy 5y ago
  Because the ruby community generally revolves around rails. Stack overflow often has generic ruby questions where answers assume you're using rails (by referencing activesupport, for example). Just to give you an idea, on stackoverflow, there are 222k ruby questions and 330k rails questions tagged.

jacobsenscott 5y ago

Rails is a DSL for building web apps. Ruby is a great language for building DSLs. Building up a DSL to meet your domain needs is a nice way to go. I don't think this is a problem at all, and very much in the spirit of both Ruby and Lisp (from which ruby takes a lot of inspiration). I believe Ruby's open classes were also a reaction to the locked down libraries that were common to Java. They were impossible to extend and resulted in a rats nest of adapters, visitors, and every other pattern in the book. In Ruby the programmer is in charge, not the library authors. The ability to do 1.day.ago was not just cute, but revolutionary, and huge productivity boost for anyone coming from C, or Java, or C# - the predominate languages of the time.

resters 5y ago

It would be one thing if Rails was the only gem that depended on ActiveSupport. The problem is that other authors use it because they initially expect their library to be used with rails. And then, if someone chooses to use the library without rails, all of ActiveSupport must be brought in as a dependency (which is ugly). I think DHH's aesthetic intention with ActiveSupport was for it to be used by Rails, not used by a random assortment of gems throughout the Ruby ecosystem and misunderstood by a lot of people. FWIW, ActiveSupport is one of the main reasons why I stopped using Rails a while ago. The other was that version updates typically have a LOT of API changes that make staying up to date quite a drag (or source of tech debt).

jeppester 5y ago

I totally agree with this. This situation where a library has a de facto monopoly on monkey patching is just weird an unfair. It reminds me a bit of MS's good old EEE strategy. People get comfortable with ActiveSupport to a degree where they start disliking to not have it's small benefits. But the consequence of this behaviour, that most are oblivious to, is that it to a large degree puts Rails in control of the language. ActiveSupport feels like a leftover from the old days of prototype and jQuery. You search for a solution and half the answers on SO will assume that you are using it (and many of the answer authors don't even know it) I'm sure it's not going to happen, but I think Rails should stop using ActiveSupport internally. It would allow devs to decide for themselves if they want to pollute the standard library, and also open the door for competition. While the syntactic sugar of "1.day.ago" is hard to match, I don't think an alternative have to be that bad "ActiveTime.days_ago(1)"

lamontcg 5y ago

Grepping this article there isn't one word about Refinements: https://docs.ruby-lang.org/en/3.0/doc/syntax/refinements_rdoc.html https://docs.ruby-lang.org/en/3.0/doc/syntax/refinements_rdo... Those are similar to C#'s Extension methods. That way consumers of the Refinement can opt-in to the extended functionality without injecting their methods globally into the class for every bit of code running on the VM. There's a good reason that ActiveSupport as a "Monopoly on Monkeypatching" which is that nobody should be doing it any more. ActiveSupport largely gets a pass because it is pretty well defined and engineered, bits of it get pulled into core ruby, and its the 800# gorilla out there because it is rails. You shouldn't copy that pattern, and you shouldn't want to. Use refinements instead.

inopinatus 5y ago
I like the refinements mechanism too and it is most certainly underutilized, but the lexical scope makes it an incomplete substitute, and somewhat problematic during reflection.
- chrisseaton 5y ago
  I'm not an expert but I believe the lexical scoping was a last-minute save by Charlie Nutter to preserve performance! Dynamic scoping of method definitions is seriously hard to optimise, and I'm not sure anyone knows how to do it. Do you really need dynamic? Why isn't lexical enough?
  - inopinatus 5y ago
    To clarify, I don't need it, and I'd agree that any library interface using monkeypatching could in principle be redesigned to use refinements. What I'm suggesting is in practice, I suspect it's doubtful anyone would undertake the exercise of reframing ActiveSupport (and thereby the entire Rails ecosystem) to use refinements instead of core extensions.
    - lamontcg 5y ago

inopinatus 5y ago

The last time I offered a Rails PR that extended core classes, it got a thumbs down review on that basis alone. Solnic's complaint is often voiced, and has merit for all the reasons given (and more besides IMO), and Rails is certainly stuck with ActiveSupport, but the core team does not seem keen on exacerbating the problem. Additions to ext modules are, consequently, rare, and in fact there's a trend going the other way, e.g. https://github.com/rails/rails/commit/33ca3923170a50da7f173165f7b8ba20fcd32803 https://github.com/rails/rails/commit/33ca3923170a50da7f1731...

simonw 5y ago

Back in the first era of the JavaScript library was this was one of the big differences between Prototype and jQuery. Prototype added a whole bunch of new methods to the built-in JavaScript objects. It also defined $ as an alias for document.getElementById. jQuery added nothing to the built-in objects, but did also use $ as an alias for the jQuery function. Something I really liked about jQuery was that it included a noConflict() function, which you could use to avoid it interfering with Prototype. Doing this: jQuery.noConflict(); Reset the $ back to whatever it was before jQuery was loaded. If you wanted to keep using $ in your jQuery code you could use this elegant idiom, which registers your code to run when the page content has loaded: jQuery(function($) { // Within this block $ is an alias of jQuery });

kirillzubovsky 5y ago

Although in principle the author is probably correct, what I don't understand is the value of his argument. Instead of saying ActiveSupport is bad, use native Ruby, why not take all of that time, energy, and more importantly understanding of the ecosystem and make AS better. When giving directions, we don't say: "please proceed forward for 17.84 ft, while reducing your speed, come to a complete stop, and then gently accelerate while turning 90 degree." We just say: "go to the corner and turn right." Certain abstractions and improvements to the way we communicate make a lot of sense. Why fight it? Sounds like the author has the perfect mix of skills to improve the core of Ruby to a point where it's useful by the rest of us who don't know and don't have the time.

kirillzubovsky 5y ago
p.s. Thanks to the author for pointing out how much non-core stuff there's in AS. Forced me to go read the docs, to find out how much awesome stuff I am not using, but should!

b33j0r 5y ago

Every python developer agrees with this article RE: Django. In the US, it’s like trying to talk to someone from the deep south versus Maine.

maple3142 5y ago

JavaScript supports monkey patching by modifying prototype objects too. But it is considered to be bad practice because it modify the behavior globally, and some method name conflict may cause trouble. An example is Array.prototype.contains couldn't be added because it will break another library, so it is renamed to Array.prototype.includes. (Source: https://github.com/tc39/proposal-Array.prototype.includes https://github.com/tc39/proposal-Array.prototype.includes)

e12e 5y ago

Rather than rails not being written in ruby, I would say that rails extends ruby. Rails is written in ruby, but rails isn't used by ruby - your rails (-using) project is implemented in the language of rails. And it's mostly fine, but the cavalier attitude to meta programming and lack of namespacing is a problem. And not just convenient (but ultimately insane) stuff like 1.second.ago - but also in core rails. On a current project interfacing with a legacy database, I've encountered tables with columns named "table_name" and "changes" - both of which are shadowed by ActiveRecord itself. But even with the crazy, it does make starting a project right, quite easy. Tests are set up, and with rails 7 you can finally opt out of most of the crazy js/css tooling and still have a nice front and backend stack.

montroser 5y ago

> 1.day.ago This type of shenanigans always rubbed me the wrong way. Like, are we saying that "1" has a property, "day"? Conceptually that makes no sense, right? And "day" having a property "ago" is bogus as well. So then, is it just a cute "let's make it read like a sentence" trick? One time a colleague was trying to tell me about this trick, and I opened up a ruby interpreter to see what he was talking about. I typed in "1.day.ago" and pressed enter and it gave some error message. A day later he came back and told me how he was surprised to learn that the trick only worked if you had ActiveRecord in the mix. To me, that's all downside. Sneaky and confusing that loading an ORM adds magic properties to your _numbers_. And, the properties don't even make sense. The worst part of it all is: how in God's name are you supposed to find out where these magic properties and methods sprinkled all up into everywhere -- where did they come from, so you might read their docs, or read their source? It's madness!

Spivak 5y ago
I think the interpretation makes a lot of sense actually. number.day -> timedelta timedelta.ago -> current time minus delta 2.months.from_now 3.months.after 2.days.ago 1.day + 2.weeks Given the choice between Time.now.advance(years: 2) and 2.years.from_now in a language that uses idioms like 1.step(to: 10) {|x| print x } I think it's totally natural.
- montroser 5y ago
  Sure, the terseness is nice, and it is possible to learn this interface and make sense of it, but to me it still seems like abusing OOP paradigm in a way that conflicts with reality. Abstract of any programming language, the concept of "2" has the properties that it is an integer, that it is a natural number, that it follows "1", that it is prime, etc. But it doesn't have a property "years". From another perspective, back to programming, if "years" and "step" make sense as properties of "2" then does _any noun_ make sense? Is it cool for every library to monkey patch its own domain's worth of nouns to be properties of every number? 2.centimeters, 2.users, 2.widgets? I can get with natural expressions for date math, but how about something more like Time("2 years from now") Then I can read that to mean we are constructing a time, described by the parameter.

jupp0r 5y ago

Rails itself depending on ActiveSupport, that's the problem. If users were to be able to use ActiveSupport or not, depending on their preferences all would be well. Imho there isn't a good reason for Rails to depend on the monkey patched ActiveSupport parts and it could be factored out into less magicky functions inside Rails.

andreareina 5y ago

There's a third option: explicit opt-in of extensions, with better support for finding where .whatever() is defined. Gets you ergonomic helpers where they're beneficial, scoped to just the modules you pull them into. Too late for Ruby but this is how Rust traits work right?

andrewcarter 5y ago

I've felt a lot of the same frustrations on iOS projects with swift. Lots of people add tons of extensions and helpers, and folks learning on these codebases don't learn iOS, they learn the playground that the developers of the project made, it's not obvious what's built in and what's custom. The extensions are less composable, harder to navigate, and often end up really ramping up complexity when you end up with constraints and generics and protocols and all kinds of really fancy "nerd stuff" that really isn't needed in an iOS codebase. I used to have a theory that folks did this because, well, Apple has basically "solved" what make an app is. Everything you need is there, it's all pretty easy to use, it's "boring" in a good way. Maybe this is how developers scratch the itch of needing to do a lot of "real programming"? Maybe I'm just getting old!

draegtun 5y ago

> This unique feature of Ruby has been leveraged by DHH back when he created Ruby on Rails framework This isn't unique to Ruby and is possible in other languages. For eg. in Smalltalk you could create this DSL... 1 day ago.

iovrthoughtthis 5y ago

Just wanted to say that the authors libraries, especially ROM [0], are incredible and have played a huge influence on me as a developer. I learned a lot using and diving through the code. [0]: https://rom-rb.org/ https://rom-rb.org/

solnic 5y ago
Ah thanks man, I'm very happy to know this. ROM 6.0 is going to be a major improvement Stay tuned!

masa331 5y ago

Why there always have to be somebody telling you arbitrarily what's right or wrong even for such a harmless and creative things such are a programming languages or concepts and why i always open articles like that even that i know how bad it makes me feel. I really wish i will finally remember this next time and i will spend the time coding hapily instead, sometimes with ActiveSupport, sometimes not, maybe even with Dry-whatever, if i'm able to overcome Solnic's negative agendas.

solnic 5y ago
What makes you think I have negative agendas? My "agenda" is quite positive, I want a Ruby ecosystem where we play by the same rules and Rails is no longer a special snowflake. This way we can evolve faster.
- masa331 5y ago
  Your articles are very negative. Basically everything involving Rails is bad and wrong by them. That's what i mean. I want Ruby ecosystem, where everybody is free to do their things the way they want, by the rules they want, for whatever motivations they have. I want to have my special Rails snowflake and i don't want it to ever change because it constantly enables me to build amazing things AND enjoy the process also. And i'm willing to let you have your way and i will respect it but only if you can do the same without being negative about it in every other statement. If somebody chooses to support Rails and Rails only in their library i think it's very fine and i think the same if there is a library doing the same thing for only Hanami. Or a library supporting both. Or a library not really supporting anything in a special way. I also think it's fine when there is a library which sole function is to monkey patch Object with #forty_two method. And fine it is because there are no rules from you or anybody else forcing me to actually use this thing. So, i will just not use it, right? So for me this open and free "we" is the only "we" there is and also the only one i want to evolve anyhow.
  - solnic 5y ago
    > Your articles are very negative. Basically everything involving Rails is bad and wrong by them. That's what i mean. I provide critique that some (probably many) Ruby developers don't like and disagree with but my intention isn't to bash something and make it "all bad". I don't recall saying that everything involving Rails is bad and wrong. I had conference talks sharing my appreciation for Rails and various parts of its philosophy that I agree with and try to incorporate in my own projects. There are also things I don't like that are very problematic and I share this with the community as well. > I want Ruby ecosystem, where everybody is free to do their things the way they want, by the rules they want, for whatever motivations they have. Imagine a ruby gem that becomes super popular because it provides some neat features that plenty of companies can benefit from. Then, for whatever reason, this project introduces some great performance optimizations but they are achieved through monkeypatches. Unfortunately it turns out it breaks Rails in some weird, subtle ways, that are hard to debug. Rails core teams starts getting lots of bug reports about some seemingly unrelated problems, just to realize that it's not a problem in Rails, it's a problem in another library. Does this make any sense? Nope. That's why people don't monkeypatch in their libraries. From what I gathered, there's some initiative to move Rails to use Refinements via ActiveSupport, if this happens, then the problem is solved. > And i'm willing to let you have your way and i will respect it but only if you can do the same without being negative about it in every other statement. It's interesting that you mention respect here - ActiveSupport doesn't respect the rest of the ecosystem. By simply adding new methods to Kernel, Object, NilClass, it reserves them and you really want to avoid having same methods in your library. If you want to tell me "but nothing prevents you from doing this" then you're right, except that I have to think about this because if my lib doesn't work with Rails well, I might as well not build it in the first place because adoption would be non-existant.

solnic 5y ago

FYI I changed the title to "Rails and its Ruby dialect". Thanks for all the comments. https://solnic.codes/2022/02/02/rails-and-its-ruby-dialect/ https://solnic.codes/2022/02/02/rails-and-its-ruby-dialect/

herbst 5y ago

I love Ruby and until I started to earn money with it as in a normal job I refused to touch rails. It felt wrong as someone used to pure ruby, Sinatra, and the whole syntax philosophy behind it. I had the luck to work with one of the Rails Devs in my work place and really learned to love it, the thing that makes rails great really is the structure. Taking over a 10 year old rails project written by a newbie? Well not to big of a problem. Taking over the same project by someone who knows rails is always a pleasure. Like you know exactly where a bit of code would be found, it doesn't feel like taking over legacy depts but like a fun new adventure to explore. As web dev who used to work with PHP before that was mind blowing. In the PHP world every bit of code was different enough that everything 'legacy' was something nobody wanted to work with. It's less about the dialect but the smart structure and MVC