Live data from Hacker News

Today I accept that Rails is yesterday’s software

medium.com

91–100 of 166 posts

Re: Today I accept that Rails is yesterday’s software

#91
post #84

Earlier quoted context omitted.

ORMs get a lot of undeserved flak for being considered "training wheels for SQL" but they can save you from writing an awful lot of boilerplate code.

Activereord certainly saves me a lot of time. I think the reason orms get a lot of flak is that people see them usedin wildly inefficient ways that could have been solved with a simple join or other basic sql operation. Or alternatively people to to comical levels of twister to stay within the framework and create a parallel implementation of Sal. But yeah if you use them judiciously they can remove some drudgery.

If your ORM can't handle joins you're just using a bad ORM, period. Pick a better one.

Re: Today I accept that Rails is yesterday’s software

#92
post #70
post #49

Earlier quoted context omitted.

Rails has a bright future ahead despite what this article states. Consider for a moment that most projects just need to figure out product-market fit before we know where to throw the money to scale. Rails remains to this day the tool I go to for building web applications because it's so well suited for building something quickly. Sure the effort to make it scale is present but I see any scaling effort as big regardl…

> Rails remains to this day the tool I go to for building web applications because it's so well suited for building something quickly. Sure the effort to make it scale is present but I see any scaling effort as big regardless of framework or language. This is why I continue to use Rails despite being interested in this that and the other new thing. It's very productive in terms of getting something up and running. I…

Twitter is the poster child for dumping Ruby.

Even if Rails is God's gift to CRUD app prototyping at some point you have to ask if building a tech stack on something that is going to fail hard as soon as you get popular is providing a good service to those who are paying you for the quality workmanship.

Re: Today I accept that Rails is yesterday’s software

#93
post #54
post #5

Being "yesterday's software" is a necessary step. It's the final part of the Gartner hype cycle: maturity. https://speakerdeck.com/tehviking/surviving-the-framework-hy...

Here's the video: https://www.youtube.com/watch?v=0MojR1XUEc0 As an aside, how do people consume slide decks? It doesn't seem as interesting without the associated lecture...

Thanks for posting this! There's a more recent recording with a bunch of updates here: https://www.youtube.com/watch?v=9zc4DSTRGeM

Re: Today I accept that Rails is yesterday’s software

#94

I remember early Rails, around 0.13, pre RC, the community was small the future seemed bright. Little did we know the horrors of what it would turn into. Most of the professional people left when they saw the security circus, the endless holes and design flaws. I learnt then - avoid any web framework which has pragprog pushing a book behind it. The new one to avoid because the masses are already circling around it is…

IDK much about Rails but Phoenix is different. There's not much magic or much hidden behind the scenes.

https://dockyard.com/blog/2015/11/18/phoenix-is-not-rails

Re: Today I accept that Rails is yesterday’s software

#95

The question is where do you go from here if you're a Rails shop? The last place I worked had 80% of their products running Rails 2 and 20% of them running on Rails 3. No product was ever both completed AND caught traction since. Do you stick with Rails 5 for the next project? Do you meander over to Python or Node?

Dockyard, a Rails agency, is moving to Phoenix I think.

Re: Today I accept that Rails is yesterday’s software

#96

Earlier quoted context omitted.

Perhaps you might consider completely stopping reading Medium posts. Much of what is wrong with HN is the fact that people here think Medium gives them instant credibility. (To be more specific, I object with how professionally-done Medium posts look, in contrast with their content, which often seem amateurish at best.)

That is the other conclusion I came too. The click bate title of it is enough to cause issues though. There is a consensus on this website though that Rails is good enough for ideas I want to get out there so I will stick with learning it, so far it has been fun.

Rails has a lot of life left in it. Still my favorite platform for gettin shit done

Re: Today I accept that Rails is yesterday’s software

#97

I've been doing enterprise backend development (java/spring, scala, akka) for a while and occasionally miss the practice of sitting down and creating a fullstack app myself, which I used to do with php and crappy html. But then I sit down and try to work with existing Ruby/Rails codebases and hit a mental block. I guess example #1 is method_missing. I get it, it's a huge time-saver and lets you do all kinds of cool t…

How about writing tests that enforce invariants?

I have been doing clojure dev for a little bit, and here's what I do -

- Run tests in the background continuously (lein expectations will give you that. or you can write your own shell script)

- Do small checkins, frequently to git

- Write tests that enforce invariants. Haven't gotten to test check yet - but I guess that would be even better.

The trouble with types is they push you into a corner early, and after a while people will be coding to zombie constraints - the constraints that were there before, but not true anymore. They are also verbose, and need tooling to get you out of the corner. If the requirements change a little bit, it could be that, your old solution goes against the grain of the new problem, which is very hard to get rid of without rewriting the code.

With dynamic languages, I find that I think more about the problem, than trying to do constraint satisfaction with other entities in the code, not to mention the language itself.

Re: Today I accept that Rails is yesterday’s software

#98

It's not Rails. Web software development in general has simply plateaued across the board. We're out of new frontiers to innovate around and the work from now on is about playing custodian to the innovations of the past. Unless something spectacularly interesting comes along, the priorities of the web are now all about supporting what's already been built. Either by maintaining something hastily built and cracking at…

What about stuff like Elixir? Not innovative but it's interesting to explore the applications of Erlang's VM (fault tolerance, high availability, the concurrency model, stuff like supervision trees) to web applications.

Re: Today I accept that Rails is yesterday’s software

#99
> Swift, Rust, Go, and the rest of tomorrow’s languages, can you marry modern thinking, build a community with simple as a core design goal, and save web development from itself?

Go is great for plumbing, you can get network utilities up and running pretty fast with no dependencies so it's easy to deploy, that's its niche. Now try writing a complex eCommerce website, a news site, or any large app backed by a complex data model in Go...

I started to use Asp.net CORE on Linux with Postgres the other day and frankly, I don't want to hear about Go and its "simple" type system anymore when I can just use C# and do projects in minutes without fighting the language. Go is at at most a safe C with channels (without macros which make it worse than C in term of features).

My point is neither Swift,Rust or Go are silver bullets which will fit every use cases in Web Development. Neither is asp.net core,but for my use case there is no debate as to what I should be using.

Rust,Go and Swift aren't tomorrow languages. They are languages that fit a specific use case like every other language.

Re: Today I accept that Rails is yesterday’s software

#100
post #25

Just use Java people. You can bootstrap a Spring project in 10 minutes and it will have every feature (ORM, security, caching, MVC) available with just a maven dependency or you can roll your own and it will work fine. Strong typing, good performance, sensible stack traces (if you don't overdo annotations) and all the testing and monitoring tools you could ever dream of.

This comment is what I feel like replying with to every article about some "fast iterating" language. IMO the only reason to use rails if you don't actually understand how web development actually works. Why would you pick a slower language and platform like ruby/rails when java/spring is right there available to anyone?

Fast-iterating is only useful when you have a small team and are getting off the ground. Every project spends 90% of it's life in maintenance and will be handed off between dozens of developers who will just ask "WTF is this?" no matter what you do. Java provides a lot more traceability and determinism as well as verbose idioms that make it easier to deal with. Like I've said many times, Java doesn't solve programming problems, it solves organizational problems.
Post reply on HN