Hacker News Reader

Comment by confidantlake | Hacker News Reader

I have spent a lot of time with node(express), Java(Spring) and rails. I see a lot of complaints about node, but node with typescript has been a joy to work with. It is lightweight and has a type system. I know where every piece of code is coming from, there is no magic involved. I either wrote the function in that file, I am importing it, or it is a method on a js object. I only have know one language for both front end and back end. A better standard library would be nice.

Rails is nice in terms of getting the project set up, not bikeshedding about the tooling, and working with the db. But the actual coding has been painful for me. I really dislike working with a non typed language. I dislike optional parans in function calls and optional braces for hashes. I dislike all the magic of rails. I never know what is going on because there is some functionality that inherits from a rails class or some other part of the code base. I would rather write a bit more code for a bit more clarity. Maybe if python were typed I would like Django? But python has all of that nonsense around virtualenv.

Spring has been ok, but not great. Too much bloated abstract factory creator nonsense. Dependency injection never really clicked for me. All of these annotations. I quite liked plain Java but Spring just felt like this monster.

All in all node(express) has been the nicest for me.

View on HN

> I dislike all the magic of rails. I never know what is going on because there is some functionality that inherits from a rails class or some other part of the code base.

This is also my only complaint with Rails.

I'm a programmer, not a wizard, and I'm not good at magic.

I never really understood the criticism about "magic" in Rails.

We are surrounded by magic (which only means things we can not realistically be bothered to take the time to really understand, in contrast to things which are incomprehensible). I have no real clue why the terminal works. I have no real clue why my OS works. I have no real idea how TCP/IP does its thing. Sure, I can use them – but I couldn't really explain and much less recreate them.

What I need in all the above is replicability. I do x, and I know y is going to happen. Get x, do y. This is true in Rails.

If I really wanna know more Rails is open and easily explorable. No one is preventing me from finding out how any piece of the "magic" works.

"Magic" class inheritance is a thing in JS as much as it is in Rails.

What is so special about Rails and "magic"?

When multiple teams work on the same rails project, you're bound to have someone enhance some class somewhere, and all of a sudden, your isolated class is doing things it's not supposed to do, or at least you think it's not supposed to be doing it. You try to debug it, but there are no types no way for the tools you're using to let you know easily, here is where this specific piece of logic coming from.

In Typescript, entities have types and when you misuse something the typescript checker tells you while you're coding why, that's not what you're supposed to do. You can super easily track down the type and navigate the code base to the source and adapt either your code or edit the source. Easily. With rails, you're often required to do mental gymnastics to debug simple things, after the fact

Let's not pretend javascript Promises and async/await are not magic in the same way some of Rails is. Lots of gotchas and unintuitive behavior, let alone cryptic error messages and stack traces. At least Ruby generally gives pretty useful stack traces. When something breaks, it gives you a pretty clear indication of exactly what line it happened on and what the problem is.

I love Rails (though criticism of its magic is fair), but this isn’t a good analogy. Async/await is literally syntactic sugar over the Promises abstraction. There’s nothing magic about Promises, and certainly nothing magic about async/await. In fact, I’d argue you’re in for a slower learning curve if you believe there to be magic in these areas.

> In fact, I’d argue you’re in for a slower learning curve if you believe there to be magic in these areas.

I 110% agree with you.

This is Rails striking again!

"Don't look at the magic, just memorize it." might as well be Rails' slogan.

Convention over configuration really just means "Memorize all my conventions, and don't ask why I picked them".

Great for the case where your use-case is in line with the chosen conventions and you don't want to think all that hard (or you just need to pump out content - like a contract agency). Pretty terrible for just about everything else.

Promises/async/await seem very different than Ruby's (and Rails') metaprogramming to me. I'd need an example of a cryptic stack trace to know exactly what you're referring to--half the problem is because of the overuse of anonymous functions that bork the trace. There's an easy solution to that (and it makes the resulting code easier to test as well).

the fact that there is a long chapter in a book series written on the edge cases of javascript[0] leads me to believe that it's not generally well understood either.

0. https://github.com/getify/You-Dont-Know-JS/blob/1st-ed/async...

JS uses an event-loop (which is really just a variation of a message/event queue that we've been using for GUI based applications for decades now). If you understand this, asynchronous code in JS is pretty easy to understand.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Even...

You can go from nothing to mostly full-fledged promises in about 200 lines of code: ex - https://www.promisejs.org/implementing/

async/await is pure sugar on top of promises (it's literally just wrapping the rest of the function in a .then() for you, and coercing the return value of your function to always be a promise)

IMO that's an explicitly different issue than a comparison between Promises/async/await and Ruby's metaprogramming, though.

Not to mention that part of the issue with Promises is the various polyfills invented before broad acceptance, which is a separate can of worms, and a different type of complexity than the (relatively) heavy use of metaprogramming in Ruby (relative to JS).

Promises and async/await are absolutely not magic. Every JS engineer who is competent quickly learns how the event loop works and how promises work.

> When multiple teams work on the same rails project, you're bound to have someone enhance some class somewhere

It really isn't that common just like it isn't that common to do it in JS or in Python. Some people used to do that shit a decade ago, it became frowned upon and I don't really see it anymore.

It might come from the pervasive use of metaprogramming / DSLs in Rails and many other Ruby libraries.

I think rails should have explained a bit more about what rails does... every single rails method call like has_one or belongs_to inside a controller is just a method call that sets up a few methods based on the name of the thing you pass into it. not that much magic there. it's just ruby. in fact the single best thing to know that they are not some spooky things to be feared but they are just simple method calls outside the scope of a method.

class Foo; puts "foo.rb was parsed"; end

is a simple example of nothing is really special.

> I never really understood the criticism about "magic" in Rails.

I'll state my case as clearly as possible: The magic in Rails REQUIRES memorization... freaking everywhere. And it provides virtually no hints to jog your memory.

There's just too much tooling, hidden away out of sight, and applied through shenanigans with Ruby that other languages/frameworks make MUCH more obvious.

Simple trivial example? Rails fucks with imports left and right. Rails allows you to not even write a require statement half the time - it's just going to load things from places. Hope you have that list memorized.

Does it save you some time? Yes.

Does it make the code look "Cleaner"? Sure.

Does it make my life a fucking chore every time I have to run a damn console to find the source location of an object at runtime because it's entirely unintuitive about where it freaking came from? Damn right it does.

---

If you started early in your career with Rails - you probably don't notice this. But if you have experience with a solid selection of languages (ex professionally I've used: GoLang, C, C++, JS/Typescript, C#, Java, Netlogo, Rust & Ruby) I find the discoverability in Ruby/Rails about the lowest on the list.

Very fast to work with if you happen to have it all memorized. But that's about the only compliment I can give it.

I have to work with a lot of legacy codebases day to day, but generally it's get in, figure it out, make a change, test it, and go. With Rails, I just end up in that "figure it out" loop over and over.

In my book it's a write-only coding environment like everyone used to complain about with Perl and PHP. People crank that stuff out really fast and move on and leave future generations to suffer. But they love it, of course.

How much effort did you put into learning Ruby and Rails properly? It's easy to get started but rather hard to master and it sounds like you're invested in other tech.

Right back at ya: "Which version of Ruby and Rails?" :P

Because to me - RoR is in the death spiral period that the original ASP.Net was in before Microsoft threw the whole thing out and started over with the Core version.

Namely: Rails trys to give you opinionated best defaults, but the "best defaults" have changed dramatically since the framework came into existence. So you end up with 6 very different set of opinions as the framework has evolved, and the documentation is poor (honestly, at least ASP.net had okish docs - I find Rails docs pretty damn bad) and you get a complete wash on 3rd party sites trying to find relevant info for the version you happen to be using.

Also - Unlike MS and ASP, Rails doesn't even fucking try to keep naming consistent. They seem to favor making the syntax as close to natural language as possible, often deprecating the old syntax in favor of new method names solely "because it reads better". Which drives me freaking nuts.

Inertia will keep it running for a long time, but it's not the thing I would pick for greenfield projects anymore.

I'll take legacy Rails over legacy Java or legacy PHP or legacy .NET but to each his own. Good luck!

Some random thoughts:

These are fair criticisms. These kinds of problems can also be difficult to demonstrate to others who may help.

For example "some function `f(x)` gives 5 when it should give 7" will get an answer in 5 minutes on stack overflow, whereas "my thing's not working and I don't know why" will receive 4 downvotes and no answer in the same time.

I tend to be the kind of learner who doesn't sit down for 30 days and read the docs cover to cover, but rather I start using the new tool on day 1 and figure out what I need to know as a I go. But rails rewards the former approach (i.e. reading through the rails guides - or even just skimming them). This may take a few weeks, but it gives the ability to at least know where to start to look if something has gone wrong.

> And it provides virtually no hints to jog your memory.

I kinda agree. I feel like this should be easily addressed (although I'm not totally sure how).

> GoLang, C, C++, JS/Typescript, C#, Java, Netlogo, Rust & Ruby) I find the discoverability in Ruby/Rails about the lowest on the list

What's interesting to me about this comment is that among the languages I'm familiar with that you list, the difference between the best discoverability and the worst feels way larger than the difference between the worst one and Ruby. To me, C is barely any better than Ruby; sure, Ruby lets you define methods/types at runtime, but C doesn't even _have_ methods, making finding all the things you can do with a given type way worse in my opinion. Plus, you can still have some wonky generated stuff with macros, although I'll concede that's usually less common than Ruby metaprogramming. Java, C++, and Go are a bit better, since you get a namespace instead of just a random identifier without context, but these namespaces are generally split across multiple files, so in practice I would need to rely on tooling to do this for me, and at least with RubyMine this wasn't in practice _that_ much worse.

Don't get me wrong - there are definitely some C/C++ codebases where the macros have gotten way out of hand. But in general, they're both typed - which helps SO freaking much.

Ex: C doesn't have methods, but if you store most of your data in structs then you can easily do two things:

1) find all the places where the header defining that struct is included

2) Do a global search for the struct name

Both will present you with a nice list of places that data is used, and show the functions that accept it as an argument.

Where as with Ruby - I basically have to use RubyMine to get anything even sort of working, and even then it chugs along very slowly trying to do it. Solargraph in VSCode doesn't really work at all (at least 50% of the time it finds no definition for me) and just using a basic editor is a nightmare. Sometimes you can do a global find for "def [classname]" but that only gives you the definition, not any of the places that use/modify it.

Basically - Ruby is one of the few languages where I feel like global search just doesn't work well, and it also eschews import/require/include statements when used in Rails. It's just a tangled mess, and there's NO way to unwind it without tooling, and even the tooling struggles (RubyMine is a guaranteed way to get my fans running at full speed for large projects, and it's the best I've used).

Large Rails projects are the worst I’ve ever encountered as far as being able to find the code that’s actually going to run when I’m looking at a function call in some code. Even with Rubymine, the jump to definition support is a joke compared to typescript, Java, etc…

You just see these functions and there is no require in the file to tell you where they come from. Rails just loads that shit from somewhere. It could be from a mixin, it could be from one of the 50 classes in your hierarchy, who the hell knows. You press jump to definition and rubymine just fucking chokes and gives you like 30 different method definitions with the same name in different places.

Yeah, that's a good summary of my frustrations.

I don't know how much blame to put on Rails, Ruby, or the teams I worked on, but in the end it was very frustrating.

Aside from that I like Ruby a lot, and Rails only a bit less. But it's a big aside :)

Hey @here i have had the same issue with tracking what is executed when jumping into a new code base, sometimes the code base is so large that instead of contributing you start learning what exists. There is AppMap, google maps for codes, used it quite a few times and unlike rubymine, you can track functions, methods easily by tracing views with just instant clicks. Here is the site https://appland.org/ and they have a vscode extension to ease the process of recording maps

I understand the "too much Magic" criticism of Rails from novices & intermediate Rails developers, but once you reach a sufficient level of mastery, I think this goes away.

After using Rails every day for 12 years I know pretty much all the ins and outs, and what is "magic" to others is just the robust tooling I love. Just like any tools, they are overwhelming and daunting when you don't know how to use them, but once you become proficient with them, they make your life so much easier. While it might be difficult when the "magic" doesn't do exactly what you want for your edge case, when you have a sufficient level of mastery, it's easy to find a way to adapt/modify/override the tooling and make it do what you want. Further, many times the tooling is there to keep you from doing things you probably should not be doing, and this kind of strict, opinionated, best practice enforcing philosophy has gotten me out of trouble at times, and I think it makes it much easier for engineers to move between Rails codebases and start being productive even faster.

I've done plenty of Node/JS/React and I honestly do not understand how people can prefer to use these stacks over Rails. For full stack web dev, Rails is such a pleasant place to work every day.

Also, Rails has moved away from the magic over the years, learning where it is and is not appropriate.

I've been doing Rails for literally decades. I understand the magic but I still struggle to figure out what's going on in larger codebases. The amount of context you have to pull in to understand what a particular block of code is doing can be huge.

> I've been doing Rails for literally decades.

Rails is 17 years old.

Yep I've been using since some the beginning.

That's based on the 1.0 release. Many of us were using rails before 1.0, which is not quite 20 years, but it's close enough.

Express isn't really like Spring, Rails or Django. Express is very simple and may be good for someone learning the basics, but how is a novice web developer supposed to know what is missing? There concerns from security, authorization, sessions, and many more that Express doesn't handle out-of-the-box.

When I said rails was nice for project setup, it was things like what you mentioned. Definitely easier to do those things in rails.

In express there are packages for those things, ie https://www.npmjs.com/package/express-session. Agree it would have been nice as part of the express library.

> ... how is a novice web developer supposed to know what is missing?

That is a great question. Is it the job of the tooling to prevent a novice developer from shooting themselves in their foot? Do we need higher-level abstractions in our frameworks that are analogous to memory safety in programming languages? Perhaps.

Alternatively, I don't think that security practices are particularly hidden. Anyone who's used the web knows has used a login form. I would give most novice developers the benefit of the doubt that they're going to be curious and look into that.

I would argue that it is, in part, their responsibility to learn these things. It's our responsibility perhaps as stewards of the secure web to teach and enforce best practices. I don't think baking in these best practices into frameworks does these developers any favors, except that it allows them to focus on something else.

I often think of languages like Haskell that could offer the clarity and expressiveness and the static types I want, but the developer experience and killer software (react, phoenix, rails) has just never been there.

TypeScript to me is the compromise I'm willing to settle on. It is also lackluster from many aspects but day by day it gets a bit easier.

If you haven't already found it, you should look into IHP (https://ihp.digitallyinduced.com/). It aims to build the convenience of Rails on top of Haskell's powerful type system. I've not yet built anything serious in it, but I've been following its progress, and it's looking really good so far.

Im happy you posted this.

Im a noob starting a project in Spring and I get lost in the jargon. I find that all the Spring knowledge I’ve gathered is to know what is NOT written in the code that Spring is doing for me.

In other words, feels like knowing Spring is being able to read between the lines and placing annotations more than building with it. Which is fine, but it’s easy to get lost when starting out.

It’s also for me to find help since the community seems much smaller and none of my friends are interested in helping out because they don’t want to learn Spring.

I felt the same. The documentation is so sparse. Can someone suggest a book or a website that builds concepts bottom-up?

I tried this route and what I found is either outdated or was of poor quality and the code examples didn’t compile. It’s easy to get the barebones up and running but once you need to start customizing is when things have many different ways you could go about getting them done.

Take a look at https://quarkus.io you won't feel overwhelmed.

Yeah, Spring is incredibly 'magic' heavy. Works great when you know the exact right annotation incantation, but it's a pain to actually understand what's going on.

I've found the official documentation to be very detailed, so it's helpful if you really need in-depth knowledge, but if you don't it's a bit hard to parse out the relevant bits. Copying something from the official guides seems often the easiest way...

In regards to the community, I didn't find it to be much smaller? The stack overflow tag is very active. I have the same experience that nobody I know wants to learn Spring out of their own volition though.

Python has optional static typing, which I think is getting better with each new release, e.g. allowing `T | U` for union types in 3.10.

Types can be checked with mypy: http://www.mypy-lang.org/

For Django, there are these two typing packages:

- https://pypi.org/project/django-stubs

- https://pypi.org/project/django-types

I can't vouch for them, but it looks like they're being actively developed.

I like the idea of full-stack JavaScript (or TypeScript), but last time I tried to use Node for a back end, I couldn't find anything that compared to libraries/frameworks like Django, Rails, SQLAlchemy, etc.

Idk if its just me but I find the testing frameworks for expressJS to be _awful_ -- chai and mocha work great but throw in sinon and its like pulling teeth.

The lack of good documentation is painful and often treats me like I don't already know the concepts involve.

Sequelize isn't as intuitive as Django's ORM either imo.

I recently set up a good old Django backend with REST framework. Frontend in Next.js

Turned out to be painfully slow to iterate. The ORM needs constant attention to join or prefetch queries.

Switched to Prisma and it's an utter joy. If the typescript has no errors then there won't be runtime errors.

Sequelize is a multi generational mess. It's a huge time waster.

> Sequelize is a multi generational mess. It's a huge time waster.

Could you elaborate on that ?

I personally like the functional aspect of sequelize.

Just that there are several generations of API. This makes TypeScript pretty much useless / impossible.

Working with Prisma: if it compiles (and you don't have a business logic error), then you usually won't get any runtime sql errors.

You don't have type safety with sequelize.

Ah yes, that's definitely true, automatically generated getters and setters are a pain with sequelize. It's not impassive to have type safety though, it's just complicated.

I had to write my own types around the existing ones to get getters and setters to work.

prefetch_related and select_related are pretty straightforward, but for more complex stuff the Django ORM can be a hindrance.

I haven’t checked out Prisma. Thanks for the tip.

Sure, I always have to spend time checking logs and tuning the queries like that. By default, Django selects everything. I used to discover that joins and prefetches were hauling in large text fields when I only wanted an id or a slug.

Prisma has a great API for this, and it's easy to tune. By default is prefetches and selects related even several levels of joins deep.

We're using django-stubs and we've been pretty happy with it. We've started the project with it, which was fairly simple. There's one or two model field types that are not supported but those can be skipped. We're using pre-commit to run mypy, this makes sure that we never commit a state that isn't type-checked.

> I dislike all the magic of rails.

Let me assure you, there is 0 magic in Rails. Just because something is available to you via a convention doesn't mean there's magic, it means you haven't read the docs and don't understand the convention.

Couldn't disagree more, but I think you're taking the term "magic" too literally.

There is a ton of magic in Rails. It consists primarily of magic. I've been doing Rails since <1yr of introduction (Ruby for longer than that, and Lisp for longer than either). I'm very familiar with metaprogramming. Metaprogramming fits the canonical definition of magic in this context.

Ruby, and Rails, also makes it very easy, and seductive, to add more magic. This is powerful, but dangerous. Like Lisp macros. Understanding the magic is not just a matter of "understanding the conventions" and reading the docs.

Everytime you see something you don't know where it's coming from, it's magic. Every time I interacted with Rais ive seen it, you have to know that some file somewhere registered or autoloader something else, etc. You don't see the imports to find it, you have to grep the repo instead and sort through all the matches.

Autoloading is the worst feature in rails and it should be ripped out: https://erock.io/2021/11/01/on-autoloading.html

Same experience with a medium sized Rails project here. I joyfully ejected after several months, I needed a detox from the untyped mess, every singe library was different, there were no coherent apis/interfaces at all. All Rails patterns were replaced with some random "smarter" counterparts, dry-rb here, some "better" orm developed in a shack there, all glued together. I recognized it's not the issue with Rails per se, it's the Ruby devs culture and I'm not compatible with it (even though the team was quite good, just a lot of cruft to deal with).

> I dislike all the magic of rails.

This is my #2 problem with Ruby, and it's also the reason why a lot of folk love it. I think of macros in the same way I think of RegEx, if you're writing one you better hope it works perfectly because chances are that you'll be the only one to maintain it.

Other Ruby "features" that I dislike:

1. Blocks + Procs + Lambdas are all function-adjacent. Can't we just call them functions?

3. Out of bounds indexes on Arrays/Maps return nil.

4. method_missing() is super cool and super abusive. Again it feels like magic when functions come from nothing.

Ruby on Rails is awesome to write, horrible to maintain. It’s the fastest way to build a web app but good luck with staying productive once you have 100 engineers working on it and a million lines of rails soup to wrangle.

GutHub, Shopify, Coinbase, Square, AirBnB, etc. , can probably answer some of your concerns.

GitHub feels super slow so I can't say I'm all that surprised to hear it's a rails app.

Gitlab is also Rails :) But wait it's probably super slow. You should try Jira heard it was wriiten in Java. Must be a fast app then.

> Blocks + Procs + Lambdas are all function-adjacent. Can't we just call them functions?

Well, Ruby has functions, they're just called Procs. Lambdas are a special, more strict breed of Procs, and blocks are just (pretty complex) syntax sugar for passing a Proc to a method. The main function-like concept is always a Proc.

> Out of bounds indexes on Arrays/Maps return nil.

Calling the #[] or #slice method on an Array with an out-of bound index returns nil, calling the #fetch method raises an IndexError or returns an arbitrary default value. You can use whichever suits the situation.

So its been a while since I used Rails but when I did I enjoyed it. In particular, say what you will about DHH I think having a fairly "opinionated view" on how the framework should function makes it much easier to deal with. Every time I need to do something full stack with Node I feel I need to go back and figure out what the current state of ORM's are.

However the reason I don't use Rails as much is that I'm not writing a lot of "full-stack" apps. A lot of the work these days is gluing together various SaaS services. Okta/Firebase for Auth, Contentful for CMS, Stripe + Webhooks for Commerce etc. I just don't do anywhere near as much "CRUD" style programming as I used to do earlier in my career, which is both a comment on my career and the state of programming today.

I'd love to see a project that wraps up a bunch of best-of-breed technologies and creates a full framework and doesn't try to be all things to all people. ie React for Front-End, Bookshelf ORM, Express Server etc (pick your favorites, but have an opinion that evolves but only in one direction.

Have you tried Remix yet? It's very early but I think it finally hits the sweet spot between rails and "modern" javascript frontend.

Hahahaha for real !

Same here. For any new project I use my own minimal express setup. Super easy to deploy and even easier to scale.

DI/IoC is a separate thing from the ecosystem; the benefits are just as strong in JS or Ruby--it's just that in JS/Ruby some of the benefits aren't as noticeable because of language malleability and openness.

Reply on news.ycombinator.com