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

Use Rails

jmduke.com

Post reply on HN
Print view View original

31–40 of 88 posts

Re: Use Rails

#31

Post by causal »

phtrivier wrote: post #12

> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.) This is the part that's going to sting. I suspect, given the general admiration for Paul Graham on YC, many people subscribe (if only unconsciously, and at least to some degree) to the idea that using techno X (where X would be Common Lisp in the case of PG, but everyone will insert t…

When software engineers start a business, it's easy for them to hyperfixate on technical decisions because those are the types of problems they understand well enough to optimize.

Re: Use Rails

#32

Post by hakunin »

jupp0r wrote: post #22

Rails is great, until it's not. Many of whe successful companies built on Rails were started in a different world without lots of external APIs (OpenAI anyone?) to integrate with, user expectations around central identity, authz and other things you'll want to talk to in order to serve a request. In 2024, I wouldn't start a company or project based on a language and framework that doesn't have a great concurrency sto…

Just out of curiosity, what are you doing with a great concurrency story in a company you start in 2024?

Re: Use Rails

#33

Post by ekidd »

axelthegerman wrote: post #23
ekidd wrote: post #18

Rails is absolutely fantastic for projects below 10,000 lines with 1 or 2 contributors, especially if you want a classic forms-based UI. And you can get a huge amount done under those constraints in Rails. But as of couple of years ago, Rails came with a number of drawbacks: 1. There was no really viable system of static typing that a significant number of people were enthusiastic about. See https://www.reddit.com/r/…

Static typing vs not has clear pros and cons. I do appreciate that JS/TS offers you a choice but I personally prefer Ruby the way it is. Your other comments are basically: - ruby/rails has a great 3P package system - oh and yes you can choose "bad" ones - ruby/rails let's you quickly write great code - oh and yes you can just as quickly write "bad" code

I have worked on a decent number of dynamically-typed Ruby and Python systems in the 50,000 to 250,000 line range, written and maintained by teams. This has never felt like a strong use case for dynamic typing. You end up losing:

- A lot of IDE support. The loss of documentation tooltips, in particular, can be painful in a team environment.

- The ability to change an API and immediately see all the affected code. This affects refactoring speed when making big cleanups. Massive updates I could do in a few hours in Rust might take 2 weeks on a big Rails project.

- Team-wide clarity on exactly what goes into key data structures. Can something be null? Does it allow numbers, or only strings? Etc.

With two developers and a small code base, you can keep most of this information in your head. And Rails is still unmatched for terse, clear code, plus off-the-shelf modules for many common tasks.

I'm not even sure that Ruby could be retrofitted with a really worthwhile type system, to be honest. JavaScript already required a lot of black magic, and in some ways, Ruby is even more dynamic. So perhaps Ruby is better left as-is, even if that makes it a poorer choice for projects that would benefit from static typing.

Re: Use Rails

#34

Post by _heimdall »

phtrivier wrote: post #12

> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.) This is the part that's going to sting. I suspect, given the general admiration for Paul Graham on YC, many people subscribe (if only unconsciously, and at least to some degree) to the idea that using techno X (where X would be Common Lisp in the case of PG, but everyone will insert t…

I've seen a really interesting pattern play out a few times now.

A startup needs to raise money and hitches onto the latest tech stack that grabs investors' attention. The startup raises on a valuation inflated based partly on the tech stack itself, meaning enough attention isn't given to the actual product or business model. Ultimately the startup runs into money problems when they can't live up to the tech stack hype and the valuation that went with it.

I saw this first hand with a startup picking Plaentscale early on. There's nothing wrong with the product and it solves certain problems really well, but I saw one particular startup grab it early because it was getting a lot of attention and completely missed that the limitations of Planet scale ran smack in the face of what the startup wanted to build.

Re: Use Rails

#35

Post by samlambert »

_heimdall wrote: post #34
phtrivier wrote: post #12

> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.) This is the part that's going to sting. I suspect, given the general admiration for Paul Graham on YC, many people subscribe (if only unconsciously, and at least to some degree) to the idea that using techno X (where X would be Common Lisp in the case of PG, but everyone will insert t…

I've seen a really interesting pattern play out a few times now. A startup needs to raise money and hitches onto the latest tech stack that grabs investors' attention. The startup raises on a valuation inflated based partly on the tech stack itself, meaning enough attention isn't given to the actual product or business model. Ultimately the startup runs into money problems when they can't live up to the tech stack hy…

what limitations? PlanetScale has public companies running on top of it. If a startup found limitations then its a skill issue.

Re: Use Rails

#36

Post by jkoudys »

vertis wrote: post #19
phtrivier wrote: post #12

> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.) This is the part that's going to sting. I suspect, given the general admiration for Paul Graham on YC, many people subscribe (if only unconsciously, and at least to some degree) to the idea that using techno X (where X would be Common Lisp in the case of PG, but everyone will insert t…

The key here though is that choosing a bleeding edge tech is more likely to be a problem because it's fairly untested. I can tell you what ALL the problems with rails are. For the most part they won't even start to bite you until you hit scaling problems. By the time you hit scaling problems with Rails you can probably afford to pay engineers to solve the scaling problems, and/or port off at that point. I love svelte…

I was big on Rails scene when it was huge in 2008, and saw a big exodus from it. I found so many of the "Rails" problems were solved by learning two languages: ruby, and sql. People would go to crazy lengths to avoid looking at the queries they'd actually run. I can admit to not really learning ruby as a language by itself, and can now see how much better my old code would've been if I wasn't just blindly shoehorning Railscasts in there.

Similar problems for people who learned angular but not typescript, laravel but not php, etc.

Re: Use Rails

#37

Post by jkoudys »

causal wrote: post #31
phtrivier wrote: post #12

> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.) This is the part that's going to sting. I suspect, given the general admiration for Paul Graham on YC, many people subscribe (if only unconsciously, and at least to some degree) to the idea that using techno X (where X would be Common Lisp in the case of PG, but everyone will insert t…

When software engineers start a business, it's easy for them to hyperfixate on technical decisions because those are the types of problems they understand well enough to optimize.

Yep. The problem with the story of bikeshedding is that it assumes people know bike sheds but not nuclear reactors. There are plenty of cases of people who are great at nuclear reactor design but have no idea how workers should park their bicycles.

Re: Use Rails

#38

Post by jupp0r »

rco8786 wrote: post #30
jupp0r wrote: post #22

Rails is great, until it's not. Many of whe successful companies built on Rails were started in a different world without lots of external APIs (OpenAI anyone?) to integrate with, user expectations around central identity, authz and other things you'll want to talk to in order to serve a request. In 2024, I wouldn't start a company or project based on a language and framework that doesn't have a great concurrency sto…

My company (large, well known tech co) actively instructs engineers to not use concurrency features, in a language that is known for having "great concurrency", unless they have a really, really good reason to. The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively t…

You never make outgoing HTTP calls, talk to a database or do any other IO? Genuinely curious.

Re: Use Rails

#39

Post by jupp0r »

hakunin wrote: post #32
jupp0r wrote: post #22

Rails is great, until it's not. Many of whe successful companies built on Rails were started in a different world without lots of external APIs (OpenAI anyone?) to integrate with, user expectations around central identity, authz and other things you'll want to talk to in order to serve a request. In 2024, I wouldn't start a company or project based on a language and framework that doesn't have a great concurrency sto…

Just out of curiosity, what are you doing with a great concurrency story in a company you start in 2024?

Make HTTP calls to OpenAI? Pusher? DynamoDB? KMS? SQS? Make a datababse query? Anything that you cannot or do not want to run in your monolith service.

You make it sound like it's sufficient to have concurrency support in 2024. My point is that it's necessary.

Re: Use Rails

#40

Post by _heimdall »

samlambert wrote: post #35
_heimdall wrote: post #34

Earlier quoted context omitted.

I've seen a really interesting pattern play out a few times now. A startup needs to raise money and hitches onto the latest tech stack that grabs investors' attention. The startup raises on a valuation inflated based partly on the tech stack itself, meaning enough attention isn't given to the actual product or business model. Ultimately the startup runs into money problems when they can't live up to the tech stack hy…

what limitations? PlanetScale has public companies running on top of it. If a startup found limitations then its a skill issue.

This was when foreign keys still weren't supported by Planetscale. The specific data model was heavily relational and queries were very inefficient without foreign key support. Distributed writes were also important, and if I remember right those weren't supported either though that's a really common limitation.

Assuming a particular tool works for all situations because it works for some is a mistake though. Plenty of companies use all kinds of tools, they're picked to match the specific use case and there is no magic bullet.

Post reply on HN