4 ms·

> Yes, the learning curve can be steep, and the “magic” can sometimes be frustrating. This is possibly the absolute worst combination of factors possible. The

by pdpi 2y ago

> Yes, the learning curve can be steep, and the “magic” can sometimes be frustrating. This is possibly the absolute worst combination of factors possible. The learning curve makes it bad to ramp up with, and the magic makes it bad in the long term. It's a framework that wants to be used for monoliths, and tooling is essential to manage the complexity of large monoliths, but you're stuck with a language that's extremely hostile to tooling, using patterns that make it even more hostile to tooling. So, really, what you're left with is a framework that's only actually good for the early-mid stages of a project, and only if you're an existing Rails user who doesn't have to pay the ramp up price.

gjsman-1000 2y ago
What’s the alternative?! You can either have a massive Python project and struggle with a lack of types and a tenseness that becomes unreadable at huge sizes; A Laravel project that’s PHP, which despite being way, way, better than it used to be (types! traits! union type returns! faster than ruby! weak maps! [0]) still has a few footguns left; Or you can have a JavaScript monster. The worst of all worlds. Your complexity complaints times 10. A nightmare than in 10 years will make a 2008 PHP project look well-organized. A project that has thousands of packages you’ve never read. On the edges, you’ve got microservices (which turns into a mess); or you can go fancy with Go and Rust (have fun managing the budget). There’s also, of course, C# and Java, but come now, it’s 2024, you’re probably coupling them to a JavaScript monster anyway. TL;DR: Every large project becomes a mess. Pick your poison. One is hardly worse than another’s. Best to have the devil you know. Even if you do things perfectly with a FAANG level budget, AWS and Azure still have outages. [0] https://m.youtube.com/watch?v=ZRV3pBuPxEQ https://m.youtube.com/watch?v=ZRV3pBuPxEQ
- karolist 2y ago
  The alternative is GoTH stack - Go + Templ + htmx if you want it simple. Personally I'm currently enjoying a combination of Go with connect-go on the backend for some API routes and Astro with React for all others. Keycloak for auth if you can stomach it. I've tried many stacks in the last 6 months, including Rails. Too many outdated gems, too much magic, generators from gems doing who knows what with undo only possible because of Git. A lot of these posts like in the OP are written by dinosaurs [1] and I mean no offence, at some point you have to give modern stack a chance, the developer UX with hot reloading that works without hacks and plethora of ready to use components in React world is just great. 1. https://peterxjang.com/blog/modern-javascript-explained-for-dinosaurs.html https://peterxjang.com/blog/modern-javascript-explained-for-... this was written in 2017 but is still relevant, shows how much the ecosystem stabilised.
  - gls2ro 2y ago
    How do you do session management in this GoTH stack? I am not proficient in Go, but I assume that you will go in two directions: 1. Either write the code for it yourself 2. Install a package Here is where Rails shines: it comes with a battery included so for example, session management is as simple as doing: session[:user_id] = user.id User.find(session[:user_id]) I don't need to write my own code to handle this basic feature of a web app not do I have to decide what package to use. Regarding the "modern" tech stack: What is so modern about Go + Templ + htmx? Rails can work with htmx and has a wide range of templating options for HTML. And if modern means static typing, I have bad news for you: types are old. I don't want to say that GoTH is not a good stack. It could be a good stack, but choosing it because it is more modern than Rails is not the real reason. > Too many outdated gems, too much magic, generators from gems doing who knows what with undo only possible because of Git What gems have you tried? For building an API with Rails if that is what you can go a long way with Rails in API only mode.
    - karolist 2y ago
      Hey, thanks for the response. First off I want to say that Rails is not a bad stack if that's all you know, it definitely built tons of SaaS companies and that alone means you can go far with it, I'm not here to change your mind. It's also very fundamentally different from barebones Go approach where you do need to pick your modules, define your project structure and have a deeper understanding of request lifetime in general because you are supposed to manage it yourself, things like precise timeouts [1]. In Go, it is typical to do session management with middlewares, do JWT based auth, you can attach specific user info to request context so it is available to handlers post middleware actions. [2]. Go is very barebones with many control knobs and can throw people used to monoliths off, but it's really not that complicated and you don't need to write lots of code to handle things like sessions, post Go 1.22 the built in routing mechanism got good enough to not need any packages for that at all [3]. Regarding ORM, I've grown to dislike them eventually, even though I've used gORM which is very popular in Go land. Currently my SQL queries are handled by sqlc (example) [4] which compile the queries down to type safe Go code at build time. Types are old of course, and I didn't mean modern = GoTH or static typing, I guess modern in my comment was for node based frontend dev with React/Astro, I won't expand on this in this comment, it's getting long as is. Strong static typing is ridiculously good once you develop with it for a while, editor support and guarantees you get in the sense "if it compiles, it likely works" begin paying dividends soon after the project grows a bit. Not Rust level, you can write weakly typed Go if you want but that's not the default. I have type guarantees even through frontend/backend or backend-backend boundaries with gRPC/connect without writing any marshal/unmarshal code myself. Regarding outdated gems, I can't recall now, I tried looking up my history but didn't really find anything specific. I started with barebones with devise for auth and some redcarpet markdown parsing. I had troubles setting up hot reloading, AFAIK it should work OOB with Rails 7 but didn't, then I tried hotwire-livereload [5] which pulled in Redis but also worked sort of janky. Contrast that to how great Vite based project live reloads work for modern frontend or how simple and fast Go backends live reload with Air [6]. To end, if Rails works for you and you know Ruby already then it's a great stack, I didn't like certain things and magic and view Ruby as a dead end skill career wise so in the end I ended up not using it. I use Go daily at my dayjob so it makes sense to just use what I already know. 1. https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts https://blog.cloudflare.com/the-complete-guide-to-golang-net... 2. https://www.digitalocean.com/community/tutorials/how-to-use-contexts-in-go https://www.digitalocean.com/community/tutorials/how-to-use-... 3. https://go.dev/blog/routing-enhancements https://go.dev/blog/routing-enhancements 4. https://docs.sqlc.dev/en/latest/tutorials/getting-started-postgresql.html#schema-and-queries https://docs.sqlc.dev/en/latest/tutorials/getting-started-po... 5. https://github.com/kirillplatonov/hotwire-livereload https://github.com/kirillplatonov/hotwire-livereload 6. https://github.com/air-verse/air https://github.com/air-verse/air
- pdpi 2y ago
  My best experience with long-term maintainability has been a pretty minimal Kotlin/Undertow/Jdbi stack. Today, modern Java (>=21) would've been fine too.
hakunin 2y ago
Ruby can parse itself, it has test coverage, vulnerability auditing, SQL auditing, static and runtime analysis and type enforcing tools… Rails has an incredibly convenient REPL that's built into every dev error page, a one-line integration with every error, analytics, and log-tracking service under the sun, that will give you all of the insight into production runtime for basically zero effort. You install Sidekiq or GoodJob in a couple of lines of code, and suddenly you have the entire background job system to tap into for any delayed or periodic workflows that can be offloaded, bundled with monitoring and administration UI. All you need to do is learn how to do software design, but even there Rails starts you off with arguably the best design decisions you can make at early stage: focus on your entry points (controller actions for requests, rake tasks for CLI), and start extracting domain objects as you learn more about your domain. Am I missing something? Where's the "hostility to tooling"?

by pdpi 2y ago

gjsman-1000 2y ago

What’s the alternative?! You can either have a massive Python project and struggle with a lack of types and a tenseness that becomes unreadable at huge sizes; A Laravel project that’s PHP, which despite being way, way, better than it used to be (types! traits! union type returns! faster than ruby! weak maps! [0]) still has a few footguns left; Or you can have a JavaScript monster. The worst of all worlds. Your complexity complaints times 10. A nightmare than in 10 years will make a 2008 PHP project look well-organized. A project that has thousands of packages you’ve never read. On the edges, you’ve got microservices (which turns into a mess); or you can go fancy with Go and Rust (have fun managing the budget). There’s also, of course, C# and Java, but come now, it’s 2024, you’re probably coupling them to a JavaScript monster anyway. TL;DR: Every large project becomes a mess. Pick your poison. One is hardly worse than another’s. Best to have the devil you know. Even if you do things perfectly with a FAANG level budget, AWS and Azure still have outages. [0] https://m.youtube.com/watch?v=ZRV3pBuPxEQ https://m.youtube.com/watch?v=ZRV3pBuPxEQ

karolist 2y ago
The alternative is GoTH stack - Go + Templ + htmx if you want it simple. Personally I'm currently enjoying a combination of Go with connect-go on the backend for some API routes and Astro with React for all others. Keycloak for auth if you can stomach it. I've tried many stacks in the last 6 months, including Rails. Too many outdated gems, too much magic, generators from gems doing who knows what with undo only possible because of Git. A lot of these posts like in the OP are written by dinosaurs [1] and I mean no offence, at some point you have to give modern stack a chance, the developer UX with hot reloading that works without hacks and plethora of ready to use components in React world is just great. 1. https://peterxjang.com/blog/modern-javascript-explained-for-dinosaurs.html https://peterxjang.com/blog/modern-javascript-explained-for-... this was written in 2017 but is still relevant, shows how much the ecosystem stabilised.
- gls2ro 2y ago
  How do you do session management in this GoTH stack? I am not proficient in Go, but I assume that you will go in two directions: 1. Either write the code for it yourself 2. Install a package Here is where Rails shines: it comes with a battery included so for example, session management is as simple as doing: session[:user_id] = user.id User.find(session[:user_id]) I don't need to write my own code to handle this basic feature of a web app not do I have to decide what package to use. Regarding the "modern" tech stack: What is so modern about Go + Templ + htmx? Rails can work with htmx and has a wide range of templating options for HTML. And if modern means static typing, I have bad news for you: types are old. I don't want to say that GoTH is not a good stack. It could be a good stack, but choosing it because it is more modern than Rails is not the real reason. > Too many outdated gems, too much magic, generators from gems doing who knows what with undo only possible because of Git What gems have you tried? For building an API with Rails if that is what you can go a long way with Rails in API only mode.
  - karolist 2y ago
    Hey, thanks for the response. First off I want to say that Rails is not a bad stack if that's all you know, it definitely built tons of SaaS companies and that alone means you can go far with it, I'm not here to change your mind. It's also very fundamentally different from barebones Go approach where you do need to pick your modules, define your project structure and have a deeper understanding of request lifetime in general because you are supposed to manage it yourself, things like precise timeouts [1]. In Go, it is typical to do session management with middlewares, do JWT based auth, you can attach specific user info to request context so it is available to handlers post middleware actions. [2]. Go is very barebones with many control knobs and can throw people used to monoliths off, but it's really not that complicated and you don't need to write lots of code to handle things like sessions, post Go 1.22 the built in routing mechanism got good enough to not need any packages for that at all [3]. Regarding ORM, I've grown to dislike them eventually, even though I've used gORM which is very popular in Go land. Currently my SQL queries are handled by sqlc (example) [4] which compile the queries down to type safe Go code at build time. Types are old of course, and I didn't mean modern = GoTH or static typing, I guess modern in my comment was for node based frontend dev with React/Astro, I won't expand on this in this comment, it's getting long as is. Strong static typing is ridiculously good once you develop with it for a while, editor support and guarantees you get in the sense "if it compiles, it likely works" begin paying dividends soon after the project grows a bit. Not Rust level, you can write weakly typed Go if you want but that's not the default. I have type guarantees even through frontend/backend or backend-backend boundaries with gRPC/connect without writing any marshal/unmarshal code myself. Regarding outdated gems, I can't recall now, I tried looking up my history but didn't really find anything specific. I started with barebones with devise for auth and some redcarpet markdown parsing. I had troubles setting up hot reloading, AFAIK it should work OOB with Rails 7 but didn't, then I tried hotwire-livereload [5] which pulled in Redis but also worked sort of janky. Contrast that to how great Vite based project live reloads work for modern frontend or how simple and fast Go backends live reload with Air [6]. To end, if Rails works for you and you know Ruby already then it's a great stack, I didn't like certain things and magic and view Ruby as a dead end skill career wise so in the end I ended up not using it. I use Go daily at my dayjob so it makes sense to just use what I already know. 1. https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts https://blog.cloudflare.com/the-complete-guide-to-golang-net... 2. https://www.digitalocean.com/community/tutorials/how-to-use-contexts-in-go https://www.digitalocean.com/community/tutorials/how-to-use-... 3. https://go.dev/blog/routing-enhancements https://go.dev/blog/routing-enhancements 4. https://docs.sqlc.dev/en/latest/tutorials/getting-started-postgresql.html#schema-and-queries https://docs.sqlc.dev/en/latest/tutorials/getting-started-po... 5. https://github.com/kirillplatonov/hotwire-livereload https://github.com/kirillplatonov/hotwire-livereload 6. https://github.com/air-verse/air https://github.com/air-verse/air
pdpi 2y ago
My best experience with long-term maintainability has been a pretty minimal Kotlin/Undertow/Jdbi stack. Today, modern Java (>=21) would've been fine too.

hakunin 2y ago

Ruby can parse itself, it has test coverage, vulnerability auditing, SQL auditing, static and runtime analysis and type enforcing tools… Rails has an incredibly convenient REPL that's built into every dev error page, a one-line integration with every error, analytics, and log-tracking service under the sun, that will give you all of the insight into production runtime for basically zero effort. You install Sidekiq or GoodJob in a couple of lines of code, and suddenly you have the entire background job system to tap into for any delayed or periodic workflows that can be offloaded, bundled with monitoring and administration UI. All you need to do is learn how to do software design, but even there Rails starts you off with arguably the best design decisions you can make at early stage: focus on your entry points (controller actions for requests, rake tasks for CLI), and start extracting domain objects as you learn more about your domain. Am I missing something? Where's the "hostility to tooling"?