I read through the description. Funnily enough, it's a second time I ask a question "what does Ruby have?" and the response provides something very specific to Ruby that does not idiomatically translate to other languages in a way that someone in polyglot environment would immediately understand a need for.
Statically typed languages usually have other, better ways, to associate metadata with the types, if necessary. Or avoid having such a requirement at all.
> For instance, in a social network, a user might have tags that are called skills, interests, sports, and more. There is no real way to differentiate between tags and so an implementation of this type is not possible with acts as taggable on steroids.
Isn't that's just having a property/field on a struct/class/type/object that contains the list of tags? Active Records seem to be effectively EF Core's tracked entities but with seemingly more "magic" under the hood (something that ORMs are often criticized for, including catching undeserved strays by EFC).
In general, I remain very negative towards Ruby and Ruby on Rails because most feedback that I hear leaves an impression of "so it has some of the advantages similar to top modern web frameworks in C# and Java/Kotlin but with a huge bag of breakage risk with codebase growth, a need to extensively cover code with tests and static analysis to cover for mistakes that are impossible in statically typed languages, and one tenth of performance on a sunny day".
Now, I don't think it's a bad choice in a vacuum, but it's important to consider the overall experience and practices used in a language A vs B, and whether either is used correctly.
As someone who started his career writing Ruby (but has since migrated to statically typed languages), I agree with your criticism. One big problem I had with the Rails community was the overemphasis on libraries/frameworks that make the code superficially look nice ("just put this dependency in your Gemfile, and it will automagically work") but aren't actually well-designed enough to be composable. The moment you're gonna have to do something out of the happy path, you're often out of luck.
The tagging problem in particular isn't such a hard problem that you' should need to pull in an extra dependency just for that. It's basically just a nested set of hash maps, the "hardest" part about it is the persistence - and I do believe it's worth spending maybe 2 hours on a proper DB schema in exchange for having code you own and understand.
There are other libraries in the Ruby ecosystem that take different approaches (dry.rb for example, which IMHO, strikes a better balance between the expressivity of Ruby and solid design), but they're not all that popular.
> Isn't that's just having a property/field on a struct/class/type/object that contains the list of tags?
I have never used the library, but it seems you get a lot more with just 2-3 lines of configuration (e.g. for a tag context named „interests“):
- The ability to find the n most or least used tags with a single method call
- The ability to track which user tagged a record
- The ability to find records with the same tags
- Calculation of tag statistics for a tag cloud
Now, all that would certainly be possible with EF. But many libraries for Rails give developers a very simple way to configure a feature, and deliver very expressive methods to use the feature. Which is an important property imo, since it often makes obvious what the code does, even for newcomers.
This is probably an effect from Ruby itself, where the standard library is quite expansive and has many often-used patterns built in. For example, calculating an arrays maximum value is just
arr = [1,2,3,4]
arr.max
Meanwhile, in JS:
arr = [1,2,3,4]
let max = arr[0];
for (let i = 1; i < arr.length; i++) {
if (arr[i] > max) max = arr[i];
}
And to address the README of the above library: I think it is a bit confusing because it starts with a comparison with another library, expecting readers to already know how tagging worked there.
> - The ability to find the n most or least used tags with a single method call - The ability to track which user tagged a record - The ability to find records with the same tags - Calculation of tag statistics for a tag cloud
What's the chance that this is the exact set of features that you're gonna need and not a slightly different set of features? E.g. maybe your users are part of teams and you need to know which tags were set by a given team? Or maybe your tags are hierarchical? Will the library be flexible enough to accommodate that?
It just seems that this library makes a lot of assumptions about the business logic of your application - but that can change at any point and then you're possibly stuck with a library that you have to weirdly workaround, or rip out entirely.
I would understand that tradeoff if the library solved an actually complex use case, but every competent developer should know how to implement these use cases from scratch in a relatively short amount of time, and while it undoubtedly takes longer than just adding 2-3 lines of config, what you get in return is code that you own and understand and can modify in whatever way you want.
The following is probably going to be a closer comparison:
let arr = [1, 2, 3, 4];
let max = arr.reduce((a, b) => Math.max(a, b));
Or C# and Rust (which will be >100x faster at finding max value[0][1]):
var arr = new[] { 1, 2, 3, 4 };
var max = arr.Max();
let arr = [1, 2, 3, 5];
let max = arr.iter().max();
Ruby does nail the minimalism in this code golfing example, but it does not offers uniquely high productivity to the end user, which is a frequently brought up point in defense of interpreted languages whenever their shortcomings are mentioned. Lacking static typing, Ruby users have to resort on e.g. Sorbet, which is a worse experience and numerous comments on HN seem to provide negative feedback on it.
I do actually hate to mention performance every time, but it's difficult to not do so when apples-to-apples comparison can be made. Compiled statically typed languages with GC offer similar or better (because the code is verified by compiler, not Sorbet) productivity without any of the drawbacks that come with Ruby.
This is to illustrate the point about the languages that do come with rich standard library, that also happen to go to great lengths at ensuring that shortest way to express something is also the fastest whenever possible.
Statically typed languages usually have other, better ways, to associate metadata with the types, if necessary. Or avoid having such a requirement at all.
> For instance, in a social network, a user might have tags that are called skills, interests, sports, and more. There is no real way to differentiate between tags and so an implementation of this type is not possible with acts as taggable on steroids.
Isn't that's just having a property/field on a struct/class/type/object that contains the list of tags? Active Records seem to be effectively EF Core's tracked entities but with seemingly more "magic" under the hood (something that ORMs are often criticized for, including catching undeserved strays by EFC).
In general, I remain very negative towards Ruby and Ruby on Rails because most feedback that I hear leaves an impression of "so it has some of the advantages similar to top modern web frameworks in C# and Java/Kotlin but with a huge bag of breakage risk with codebase growth, a need to extensively cover code with tests and static analysis to cover for mistakes that are impossible in statically typed languages, and one tenth of performance on a sunny day".
Now, I don't think it's a bad choice in a vacuum, but it's important to consider the overall experience and practices used in a language A vs B, and whether either is used correctly.