The regular thread of people piling in to criticise dynamic languages. Instead perhaps people could suggest a better language/framework that is more productive than Rails, and has had a long lifespan in a large codebase?
That said Microsoft's ASP.NET MVC would be a good contender for your call to suggest a better language.framework.
It is indeed very productive. It has a massive package ecosystem, great documentation, a very long lifespan (not as old as Rails, but probably about 10 years old now). ASP.NET MVC is all over the enterprise so it is well proven, plus StackOverflow if you want a high traffic example - there are probably many more. Where I think it beats Ruby in particular is the C# language is really excellent.
C# is my favourite language for getting things done and I've tried Ruby, Java, Python, Haskell, Basic and Javascript and gone into some depth with all of those. The reason is the excellent language features, one of the first to have async/await, good generics system, Linq is awesome, there is even some dynamic types support if you need it - which is nice for web page stuff while you are experimenting and then can 'shore it up' with a class later on.
The downside of C# I think but I need someone else to confirm is it is probably a bit confusing for a newbie, because of the vast number of features and many ways of doing things because of it's history. Not so bad if you have been doing it for years.
Another downside with ASP.NET is different ways of doing things in .NET Core so lots of relearning to do and tutorial roulette where if the tutorial is using .NET Core you may not find it easy to integrate into your classic application. Although I think RoR would suffer such upgrade issues I am sure.
IMHO there isn't much to gain with static languages when doing web development. A good framework is much more important. Static languages are awesome when coding business rules, though.
One person can keep a rough mental model of how the project fits together in their head, which lets them have good intuition about contracts between different subsystems.
When you have 5 developers on one project, that intuition quickly breaks due to developers mental models being slightly different. That's where having a type-system really helps.
I'd argue that the you lucked out in that the stack was able to be developed by one person, and that's what enabled it to be dynamically typed with relatively little loss.
It's once you have 3+ coders working on the same code-base that static types really start helping.
I consider myself working alone to be more than one person when I come back to something I haven’t touched in months. For all practical purposes, I feel like I’m reading someone else’s code.
A statically typed language makes it much easier to make changes in that situation without worrying about unforeseen breakages.
The defaults are quite terrible. For example the original developer put everything in the default.py file because there is nothing in the framework that suggests to create multiple controllers or models. The idea of auto generating and auto applying migrations is extremely dangerous IMHO. The ORM is pretty verbose and it pollutes the code with all those db(). On the other side, Django pollutes the code with all those Model.objects so it's not worse than that.
Still, Rails is terrific. If it wasn’t for Rails Java today wouldn’t be as productive either.
I don't have a hate-on for Ruby on Rails; my last job was as a Rails dev and I liked it. I still like, even though I haven't used it in a while (simply because I have no need). It also definitely has some advantages over Go.
But Go offers some great advantages: type safety; still fairly productive; boring understandable Just Works™-kind of language, and has most required components in stdlib (you need a few external dependencies, but not many, although how many depends a bit on your approach as well).
The biggest downside is that there's no standard web framework, and that a lot of Go devs seem to eschew them, too. There are some good reasons for that in some contexts (RoR is not a solution for everything either, that's why Sinatra exists), but it has the effect that a lot of organisations crank out their own internal semi-frameworks. Basically it's Greenspun's tenth rule.
Go-buffalo is probably the closest thing to Go, but I haven't had the opportunity to check it out in depth yet. There is also Revel, but that has some unfortunate design decisions IMHO, and isn't something I would recommend.
Is Go a complete drop-in replacement for all RoR use cases? No; not yet anyway. But I think it is for a lot of cases.
> ... The biggest downside is that there's no standard web framework
I hate to say it, but this why I feel justified in earning 50% higher pay than the younger devs on my team who are more passionate, more ambitious, faster, and put in more hours, yet always want to rewrite the boring web code in whatever is the new cool language of the year.
I mean if you feel it's worth it to stay late and work weekends in order to reinvent the same old boring code to deal with marshaling HTTP to types, process forms render templates and Json, etc - precisely the things that were mature and battle tested in dozens of other frameworks years ago - I guess that's fine if at least you're learning why it's such a bad idea (unless your job is to wrote such a framework instead of actual business requirements).
But your managers and especially your customers could care less that you did so.
But I've also found that writing new applications in Go has some good benefits over e.g. RoR. Things like processing forms and whatnot is all in the standard Go library. No need to reinvent anything.
I understand some people feel frustrated with "new tech of the yeah, yawn" (JS frameworks being the canonical example), but I don't think that standing still is a good option either. There is probably some reasonable middle ground.
The unique implementation of automatically satisfied Interfaces and first class functions (ie. easy to inject dependency) in particular makes testing very easy and designing code using these abstractions for testability also improves modularity.
For database, generally you just use the standard library to access and well tested database drivers provide the actual access mechanics. So if you want you can actually decouple tests checking the business logic side of database (eg. instantiate and hit an in-memory dB locally during testing - or even use a completely different driver if you're not using a weird "flavor" of SQL) from actual connectivity testing (where you wrap things into a transaction in a real mirror dB)
Coming from a rails background, this was the closest out of the box testing experience. Tests are generally handled within a transaction and also offer fixtures and other goodies. Definitely recommend giving it a test drive.
https://gist.github.com/kyleterry/55468cb4ff9ce2e9f0156491c4...
Works pretty well.
So, spending a year and a half on a major version upgrade of your web framework is "productive" how exactly?
I mean, whatever time you think you've saved by using Rails during the initial prototyping phase (and I don't think even that's true), you'll more than pay for in maintenance costs.
Obviously, there's a break-even point there that's different for every framework and every application. But I think the ongoing popularity of web app frameworks suggests that a lot of people find the tradeoff acceptable.
Personally I'm fascinated with Clojure but it doesn't yet have the ecosystem (for me as a Clojure noob) to easily punch out product prototypes. Likewise I've messed with JS frameworks and they're fun but they don't offer me proven established patterns; too many competing and fast-moving choices. I'd rather find my market fit first then worry about scaling / paying off tech debt.
Again, what's your suggested model? To me Rails offers a semi-boring yet productive middleground between high and low ceremony. TAANSTAFL.
Again, even if "rapid prototyping" was a thing in Rails (i.e. rapid as opposed to what?) you start paying back the price tenfold once your project becomes moderately complex, test coverage or not.
So if your question is specifically "What's a good stack for a blog I'll never touch again or maintain with X and Y integration, tomorrow", then ok, cool, Rails.
> literally any modern web framework in a static language
I was part of a SaaS startup using Java Spring and the verbosity and front-loaded design costs slowed our iteration enough that we couldn't respond to market input and stalled.
My next SaaS engagement was with a language more maligned than Ruby - Perl - and while the codebase was mildly fugly we could move quickly and I tell you what the founders made serious bank.
> you start paying back the price tenfold once your project becomes moderately complex
This is a problem you want to have because you have skin in the game. Better to start paying back your debt than to never kick off. Back to you - you didn't address my question - if you were to launch a product idea, what static stack would you pick? Elm is the only choice that comes to mind, and that's pretty niche. Ask yourself why. (I'm not dissing elm, it looks lovely)
There's no definitive answer here. Rich Hickey makes some excellent talking points about static vs dynamic. I'm not saying you're categorically wrong, but you haven't presented any science to support your dismissive tone. TAANSTAFL. Pick the right tool for the job. I wouldn't use Rails to build whatsapp, but for many midsized SaaS products Rails is a cromulent choice.
You may accuse me of shifting the goalposts, but do notice I said modern above. I'm not up-to-date with Java anymore, but iirc Play [0] would be worth checking out.
> This is a problem you want to have because you have skin in the game.
I'm saying that this is a problem you don't have to have at all.
> Back to you - you didn't address my question - if you were to launch a product idea, what static stack would you pick?
In the context of SPAs, I'd choose some of the Purescript React libraries and some generic Haskell REST/Websocket server, like Warp/Servant (this is a stack I've used in production).
For a standard web app, I'd go with Yesod [0], which is a somewhat Rails-like framework, but it fully leverages the advantages of static types, i.e. it turns things like dead links, trying to inject user input into a DB query without escaping it first, invalid queries (i.e. querying a person by product id), and many more into compile-time type errors.
> I'm not saying you're categorically wrong, but you haven't presented any science to support your dismissive tone.
Still, to claim that the context of the current thread at least doesn't suggest that Rails is a maintenance nightmare would be disingenuous at best.
> Pick the right tool for the job.
That's what we're discussing here, right? I can't see when Rails would ever be the "right tool" for anything (except for the one use case I alluded to above) but that's obviously subjective, rendering that phrase utterly meaningless.
I'll check out Warp and Yesod, although tbh the next stack I'd like to try is Clojurescript/Spec/Figwheel. Spec driven design seems to offer some of the benefits of static typing with the flexibility of dynamism.
One of the most cited qualities of languages like Haskell are their "refactorability" - i.e. one can routinely rip out the guts of a 100KLOC codebase and replace fundamental data structures and functionality in order to implement new features in a couple of hours, no problem whatsoever.
In Rails, I'd do everything in my power to not touch any "important" code if I can get away with it, because no matter how good the test suite, it's still a test suite. It shows the existence of bugs, it doesn't prove their absence. Many people claim that's not a problem in practice, but I personally tend to avoid more fundamental code changes in dynamic codebases precisely because of that fact.
To drive that point home, I'd trust a Haskell codebase without a test suite more than a Rails codebase with an average to good test suite.
Also, it seems to me that "moving fast" is directly at odds with the topic at hand, upgrading Rails. If Rails allowed one to move fast, then surely upgrading Rails shouldn't take a year and a half, even in a big codebase?
> Spec driven design seems to offer some of the benefits of static typing with the flexibility of dynamism.
Definitely, though it's not a replacement for types. Also, the probably more important thing here is that Clojure is functional, making a whole class of bugs stemming from mutability and OOP impossible.
If you're planning to go down the Clojure/spec route, you might want to check out Ghostwheel [0], a lightweight DSL which seems to be gaining a lot of traction lately.
2) A year and a half of how much effort?
> The project originally began with 1 full-time engineer and a small army of volunteers. We grew that team to 4 full-time engineers plus the volunteers.
They had four full-time people working on upgrading Rails at some point!
Interesting, I didn't know Ruby has been around just as long as PHP. I still would choose PHP if my opinion matters, just from my experience with the slow performance of ruby on rails when I gave it a go just a few years back.
PHP - 23 years
Ruby - 23 years
Java - 23 years
JavaScript (nodejs) - 22 years (9 years)
https://en.wikipedia.org/wiki/Dynamic_programming_language#E...
Python - 28 years
That said, it's frightfully close to 31 years... [1]
The few languages were web-first were often chastised for not being complete languages.
Python can use a framework like Django to reach the web more effectively.
Compared to..
A language like PHP in the beginning was more directly coupled to the web (for better or worse).
I’d suggest most frameworks are better than rails for long lifespans. They just frontloaded productivity, and it shows. The UI and functionality of github is largely the same as in 2010.
And then stuff that was sensible then probably shouldn't have changed much.