Hacker News new | past | comments | ask | show | jobs | submit login
Is Rails still relevant in 2018? (eq8.eu)
306 points by bdcravens on Aug 28, 2018 | hide | past | favorite | 333 comments

I mean... Let's pause for a minute and remove the year, and remove the language / framework. What are we trying to accomplish?

If we know something really well and there are enough developers to support an ecosystem and the talent pool in your <however you decide your region> is big enough just use whatever you want.

PHP in 2018? SURE.

C++ in 2018? SURE (You masochist)

Rails in 2018? Youre damn right I would.

GO in 2018? OK. Fine. Whatever.

This is highly opinionated, but our jobs are to make stuff that works in a predictable, less risky way. Do that.

...our jobs are to make stuff that works in a predictable, less risky way. Do that.

This is very true, but it doesn't mean "Use the thing that's worked in the past because that's less risky." Languages get better and tooling improves, and if you're still using one that isn't keeping up then you're increasing risk. These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job.

You shouldn't jump from one language to another every few months, but you should keep a close eye on what other languages are doing and ask yourself if switching would improve the code you write.

> These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job.

All of these things existed long before Ruby on Rails gained in popularity. Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees. Certainly not in every situation, but enough that it doesn't make sense to dismiss them out of hand.

> Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees.

with strongly typed languages it's harder to perform exploratory coding. This drives a kind of backpressure on the design stage of development where it becomes more prudent to design your classes and interfaces before you start coding, because changing interfaces part way through development is a much larger undertaking than in, say, Javascript. On the other hand, strongly typed languages provide a lot of guarantees that have to be coded for in dynamic languages. This is why I prefer gradual typing - you get the best of both worlds.

> with strongly typed languages [...] it becomes more prudent to design your classes and interfaces before you start coding, because changing interfaces part way through development is a much larger undertaking

Quite the opposite. With strongly typed languages, it becomes safer to make changes, because the compiler will catch mistakes. On top of that, with mature strongly typed languages, there is tooling which takes advantage of the types to help you avoid mistakes in the first place.

It's safer to make changes, but you can't rapidly mess around with different structures without having to perform housekeeping on your types. This primarily applies to OO code, which is primarily where I draw my experience from - I find FP code is easier to refactor even with strong types because it doesn't enforce as rigid a structure.

I love the idea that typed languages create backpressure. I have very little confidence in peoples' ability to create well-designed (in software architecture terms) projects.

This is not true in general. There is nothing intrinsic to static types that is incompatible with exploratory coding. If you want to turn all your type errors into runtime crashes, then some statically typed languages will even let you do this (e.g. deferred type errors in Haskell).

Python is a strongly typed language and language dynamism has no relationship to strong typing. you're likely thinking of static typing. With Python's type annotation feature as well as the work being done with MyPy, Python is also beginning to grow some static typing behavior as well.

First of all, zzzeek, thanks for your great software. While working on SQLAlchemy, have you ever run into situations where you really missed static typing? Do you ever see yourself wanting to introduce Python's static typing behavior into that project, and why or why not?

I did nothing but Java from around 1998 to 2002 and then again around 2006-2008, and there is definitely a deep satisfaction when you have built your giant statically typed castle and compile it and then it runs the first time. In Java though, obviously the verbosity that implies, particularly when I was using it pre-generics, most certainly erased any productivity gains and made for code that was very difficult for new people to understand, tests were in particular extremely hard to write. So at least with Java's widely criticized model, it was sort of nice-ish but hard to say it was worth it.

What Python is doing with typing I think is going to be amazing though. Just not sure if I'll have time to embrace it fully within my own projects.

Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees.

The benefit they offer is fewer checks so you can deploy things faster.

It's the same benefit you can get if you take your car to a mechanic who doesn't bother to check the wheels are attached properly after they've changed the brake discs.

But one can add checks after the design/features settle; it's not all or nothing. Using the mechanic analogy, if you are requesting a custom car, the mechanic can shape the look and feel first, and then verify everything once you made up your mind.

Most CRUD (such as tracking applications) is just marshaling attributes around and about, not really doing much math on them. Forced type checks can be repetitive busy work and hogs screen real-estate.

Funny when it comes to semaphores in software industry, it's harder to understand than just trying to understand it as is.

>> You shouldn't jump from one language to another every few months, but you should keep a close eye on what other languages are doing and ask yourself if switching would improve the code you write.

Shouldn't that last sentence be "... if switching would improve the end product or service you are delivering." The focus should be on what people are paying you for. Better code doesn't always mean a better product, or be a smart business decision.

The two are equivalent in most cases. There's a relatively small set of problems where the choice of programming languages will have an effect on the product that doesn't come down to the code being more understandable and more amenable to change.

Pretty much speed is the only concern for the vast majority of web applications, it isn't really that big a concern for most web applications, and even then it's less about choosing the fastest language and more about limiting yourself to a still pretty broad set of "faster" languages.

Speed of development, or runtime speed? Language won’t matter for runtime speed except in the .1% of high load apps. In my experience speed of development will vary quite a bit based on language and quality of frameworks. I went from C# shop to Ruby/Rails and the pace increased substantially, though cultural differences are intertwined with language choices.

Runtime speed, as an example of one of the few considerations when choosing a language that isn't related to code quality and maintainability.

I agree though that it's not relevant for nearly all web applications (and even for those where it is, it doesn't require that everything is done in a performant language)

> The two are equivalent in most cases.

Yes and no. The most elegant technology solution in the world does mean squat if it doesn't solve the problem the client / user needs solved.

Technology and solution are not the same thing.

Sure, but the choice of language is rarely a factor in this, barring very specialized subdomains where library support is limited to a few languages. There's very few web applications that couldn't have been written in virtually any modern language.

I think ideally they are the same, but doing a re-write isn't cost free - opportunity cost as you're not doing feature customers care about, new bugs being created, old bugs re-appearing etc etc.

Cue the descent into static vs. dynamic typing.

"C++ in 2018? SURE (You masochist)"

I know this is tongue in cheek, but if one is doing anything related to real time graphics programming I'm not aware of any good alternatives.

C# is slowly getting there thanks to Unity efforts with HPC# and Microsoft's improvements on SIMD support, stack allocation and slices.

Then on the browser you are stuck with GLSL 3.0 shaders, or any JS library that generates them on the fly.

But yeah for the layer that actually talks to the metal, it is still going to be C++ for many years, specially thanks to the ongoing language improvements since C++11 revision.

Metal and DirectX shaders are C++ dialects, and Google is driving the effort of making HLSL having first class support on Vulkan as well.

Oh, and NVidia has designed they latest GPGPUs specifically to run C++ code optimally.

I'm a fulltime Unity lead developer and I love C# as a business logic (or game logic) language, but it becomes quite ugly for hot code that is perfomance-critical. Once you get thousands of objects that you have to process every frame, you have to throw the usual C# object-oriented style and things like Linq (and I'm a fan of Linq!) out of the window and write code that reads like C. And when you get to object pools, well, that's practically the same thing as writing your own allocator (only instead of allocating arbitrary memory, you allocate objects).

Seriously, for this kind of tasks there's nothing better than C/C++ - and I write this as someone who is actively AFRAID of power of C++ and uses less powerful tools whenever and wherever possible (because I don't want all that power to shoot in my own leg).

No one said that one needs to use LINQ with C# all the time.

Likewise no one is using C++ with MI and 9 level deep hierarchies for game engines anymore.

C++ is one of my toolbox languages, which I know since C++ARM days, yet I am also open minded that it shouldn't be the only way.

I am old enough to remember when C, Modula-2, Basic and Turbo Pascal, AMOS were the "Unity" of MS-DOS/Amiga, because for this kind of tasks there's nothing better than Assembly and everyone had a copy of Zen of Assembly Language.

Then the speech was updated to there's nothing better than C when compilers improved, and it took PS 2 with its C++ SDK to eventually force game devs to grudgingly accept C++.

Which now reigns on all things GPGPU, but it doesn't mean we should be happy with just one language.

And even though it is one of my favorite ones, I dislike the lack of modules (maybe C++23 with luck) and the copy-paste compatibility with C that endangers the software I use written with it, because on many teams static analyzers and guidelines are foreign words.

"things like Linq"

It's really easy to accidentally create a simple Linq query that underneath turns into O(N^2) and suddenly the production application crawls to a halt. Actually happened.

That's why you should know where to write code optimized for perfomance and where to write code optimized for readability.

It's the latter 95% of the time.

"It's the latter 95% of the time."

Still, that's no excuse to write readable code that for example runs in O(N^2) when there would be just as readable O(N) alternatives.

This is a true statement, which very rarely applies to actual Linq usage.

Well Unity engine itself is written in C++.

True, hence the HPC# effort to make it possible to port some C++ subsystems into a C# subset.

The effort is lead by two well known figures in the game scene.


Specially relevant because their opinions regarding C, C++ and high performance game code are also well known.

There is a growing Rust game development community [0] but of course C++ still has the edge.

[0] https://www.reddit.com/r/rust_gamedev/

I think he means "C++ in 2018" to build a standard webapp, which definitely is masochistic because you can be much more productive on e.g. Rails. Just like how using PHP to build a real-time graphics engine is also probably masochistic.

It's getting better. I've been starting to dig into Crow to see if it might be a worthwhile option as a C++ web app framework:



(Relies on libboost https://www.boost.org/)

Seriously, it makes putting together a simple API a breeze. I haven't had the chance to try anything more complex yet.

People who don't know say these things. Try writing web applications in C/C++, it's a deluxe development situation. Where do you think web browsers come from? Everyone afraid of C/C++ are shooting themselves in the feet.

When I started to learn Rails, the intro was a Twitter-like messaging app. Somebody that knows what they are doing could turn that out in an hour.

Is the situation in C++ frameworks very far off?

The same. Using Restbed, a C++ embedded web server framework, a twitter messaging app is about an hour of work.

I write integrated servers with the web server, the database server, a video server, and a facial recognition application all bundled together in C++. The application screams: try 1/16th the memory footprint of a traditional multi-server Internet application, it is 4000% faster, and can run on a $100 Intel Compute Stick. Try this in any other language...

What C++ web server library/framework do you use? Or did you roll your own? For the database, are you using SQLite or something else?

Restbed is the C++ framework, and yes, we use SQlite.

I'm doing the same thing, and I've got a couple questions:

How do you handle redundancy, e.g. if your Intel Compute Stick goes offline for any reason? How do you handle crashes of your applications?

Is this for an art installation or does it have a more business-oriented purpose?

Government contracts; software is used by covert agencies.

Swift or Objective-C with Metal, so far so good. Console-quality graphics on phones and tablets.

> I'm not aware of any good alternatives.

Vulkan/C? Metal/ObjC†/C? From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†.

† depending on your definition of "real time" (soft vs hard), both kernel-wise and GC-wise.

"Vulkan/C? Metal/ObjC†/C? "

Vulkan and C are a sane option. Although, with C and linear algebra one starts to miss C++ operator overloading and existing libraries like eigen [0] or glm[1] with their graphics and computational geometry targeting API:s really soon.

If one deploys only to OS X/IOS, Metal and ObjC, sure.

"From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†."

With the added complexity of the binding layer, and sub-par collection of existing examples and resources. With C++ both OpenGL and Vulkan have excellent didactic material, including:

https://vulkan-tutorial.com/ https://learnopengl.com/

[0] http://eigen.tuxfamily.org/index.php?title=Main_Page [1] https://glm.g-truc.net/0.9.9/index.html

For Rust, there's [1] for OpenGL and [2] for Vulkan.

I don't know about Vulkano, but Glium is much more pleasant to use than the raw OpenGL API.

[1] https://github.com/glium/glium

[2] https://github.com/vulkano-rs/vulkano

The sentence in the top of the readme for the github repo is: "Glium is no longer actively developed by its original author."

Which links to: https://users.rust-lang.org/t/glium-post-mortem/7063

Which pretty much states that Glium is not a really long term viable solution at the moment.

I've toyed with cool open source libraries for 20 years. I'm too old to get caught up with something new and shiny only to find out it wasn't structurally sound.

That is why C++ is a good choice. It has huge traction. The ecosystem is basically bullet proof. It has lot of practical libraries that are so well used that while not bullet proof themselves, it is likely they will stay alive as long as you need to compile your code.

Immediately after that, it says: "That said, PRs are still welcome and maintenance is continued by the surrounding community."

> Which pretty much states that Glium is not a really long term viable solution at the moment.

Except what that post-mortem is _really_ saying is that OpenGL is not a long-term viable solution. The whole post-mortem is about the fact that OpenGL drivers are so buggy that you can't write portable code to target it.

"OpenGL drivers are so buggy that you can't write portable code to target it."

Sure, that's why generic non-platform specific OpenGL wrapper is a bad idea, unless you have an army of engineers to apply kludges and workarounds. I'm sorry the author had to find out this the hardest way. The quality of OpenGL drivers has always been like this.

One way of writing portable OpenGL is to look at what some popular game with open source is doing, and copy their approach, because the likelihood of a) the bugs that title triggered are mostly fixed and/or b) they managed to avoid the biggest potholes.

E.g. look at what Quake or Doom III does, etc.

For the several dozen EA games I worked on, in C++, all operator overloading was banned. Too many fools play dumb tricks with operator overloading, so it was declared illegal. I don't miss it, as it is a fool's tool.

There is a better word for this.. People who use operator overloading are a bunch of shmucks (Stupid fools), as my Jewish grandfather would say :)

EA should try banning fools instead . There are many other tools that have to be used appropriately, especially in C++.

Jai? (Obviously not yet a good alternative, but worth being aware of in case it perfectly suits your project...)


Any language with a FFI (i.e. ~all of them) can be used to interface with DLL:s with a C interface. That was really not the point...

Depending on what libraries you need, Nim and D seem like decent alternatives.

"Nim ... seem like decent alternatives."

Note that I specified real time graphics development as the focus area here for C++. While I don't want to get into platform wars, on that front Windows is a really strong contender, for various ecological reasons.

Nim does not seem to be well supported on windows [0]. The typical cyphers for poor windows support in open source projects, that seem to hold true for Nim, are that:

a) No mention of MSVC support as a compiler option b) Installer does not install the complete required language runtime, and the end user must hunt the missing DLL:s by themselves. c) Need to manually configure various paths

While these are not a technical blocks, they imply strongly that Windows support is not one of the key priorities for the project. "Here you go, have a nice language - and oops, good luck debugging our runtime". Whereas in industrial quality setups that have lot of users you can pretty much expect it to work out of the box.

[0] https://nim-lang.org/install_windows.html

Wow. We really need to fix our install page if people are reaching this conclusion.

Hey, Nim dev here. I can assure you that Windows is incredibly well supported by Nim.

> a) No mention of MSVC support as a compiler option


> b) Installer does not install the complete required language runtime, and the end user must hunt the missing DLL:s by themselves.

The DLLs are all included in the .zip file. Even if they weren't, you do not need to "hunt" them, there is a link for them at the bottom of the download page.

> Need to manually configure various paths

You don't. It's easy to think that when you only read the headings though :(

Here is an excerpt from under the heading:

> The zip file includes a simple application called finish.exe that can attempt to add the first directory into your PATH. This tool also checks for the presence of a C compiler and can install MingW, the GNU C compiler collection for Windows.

The installation isn't perfect, we did have an installer in the past but it proved more trouble than it was worth (NSIS is very archaic and INNO is a PITA). Despite this, you won't find many languages with Windows support that is as good as Nim's.

Hey! Cool to read you response.

My initial comment may have been a bit uncharitable, and I'm sorry - I chose clear communication instead of overt politeness. I might not resemble the core audience of the language in any way :)

I based my response to the first page mentioning windows install:


This is the first page I end up from both https://nim-lang.org and Google.

My instinctive response was based on a pattern matching from trying to run various open source projects on Windows the past 20 years, and how the projects choose to communicate their install narrative. I.e. the "ciphers" I mentioned in my posting above.

Rust needs additional compiler as well, this is how they communicate it: https://www.rust-lang.org/en-US/install.html

"The installation isn't perfect, we did have an installer in the past but it proved more trouble than it was worth (NSIS is very archaic and INNO is a PITA)."

WIX toolset may be an option http://wixtoolset.org. Not having a Windows installer generally appears amateurish nowadays (I know a plain zip is just as good but that's what people do and is generally expected nowadays).

Even Latex which was an incredible mish-mash of various components you needed to... acquire, is now available through just clicking the installer: https://www.latex-tutorial.com/installation/

"...Despite this, you won't find many languages with Windows support that is as good as Nim's."

You could mention msvc in the initial install page since you need it. There was a specific time when projects had good economic and technical reasons not to depend on Visual Studio on windows. Not so much anymore, since it's free for individuals.

Installer landing pages for languages which don't signal my "fragile-not-well-supported" sense:





The Ocaml Install page is on the edge, but, that is compensated by a pedigree of being well known and having credible industrial users (i.e. Jane street):


I know you are a small team and have other priorities than your web page... the installer and mentioning MSVC on the install page would go a long way in increasing the likelihood of at least trying the project for random people running Windows.

Thank you! I'll take your feedback on board :)

There's absolutely nothing wrong with C++ if you use a small subset of it, like for example Carmack did in Doom 3.

The only problem that arises with C++ is when people want to use EVERYTHING in the language, because if it exists, it has to be in my project, right?

If you're using a small subset why on earth is it the right language? I had the misfortune to try to mentor a new quant who felt they had to write C++ "for speed" . But refused to use the STL as they were going to use a subset. So they wrote Fortran-like C++, array as the only data structure, bad lookup algorithms and leaked like a sieve.

Things are in the language for a reason - if you've got the issue then you use the feature.

I hardly ever recommend C++ these days as it's not worth the slower dev time. There are a few cases where run-time really does trump everything else and it's still appropriate.

In that case the code will be templated to within an inch of its life, because that's how to write real C++.

Because with small subset you get pretty and understandable code with reasonably fast build time.

Although STL implementations are getting closer today (regarding underlying speed), unless you plan to lock to particular implementation, even version, you'd better use subset ;)

Are you a quant? What do you use instead of C++? Python/cython? I’m not convinced C++11/17/20 cannot be used in quant but I am not in the business (i’d Love to though).

Let's just be honest: today's dev's can't write in C/C++ because they don't have the formal training. They are primarily script language devs who can't work at the low level required by C/C++. The formally educated programmers who were taught low level large-scale systems programming are too few to create the programmer farms you all work it (which I left for scientific software development, where the devs are older and we all work in C/C++ or assembly.)

You don't need formal education to understand why some things are the way they are in C++, you need to understand how a CPU works. A small amount of assembly programming is sufficient for that - it is actually very simple to understand, just hard to write nontrivial programs...

I'm very interested in leaving the dev farms for something more interesting. I'm taking steps in that direction, but do you have any advice on how you escaped into scientific software dev?

Not OP, but worked in science before. What you want is not to work in science on software dev ;) Scientists usually write extremely ugly, messy code, just to make it working and finalize paper for publishing. Remember, their focus is paper not code nor properly workable program.

Things like testing, agile, tickets, code indentation, patterns - none of that you'll find there.

If you aim for serious environments like Wolfram Research or MathWorks, that could be different. If you aim for quantitative firms, usually you'll find there scientists writing prototype in mathematica/matlab/r/python (messy again) and devs who will re-write it in c/c++/java/asm.

Thanks for the suggestions! I hadn't thought about places like Wolfram Research or MathWorks. I'll keep my eye on those. I'm working on picking up more C++ since that seems to be what everything I'm interested in is using.

Keep in mind these are "conservative developers" - they work in C/C++ - meaning a preference towards C styled C++, a preference towards maintainability, and a preference away from the latest features of C++. That is being a developer, yet in a tech shop. There are lucrative alternatives too:

When one looks outside the traditional technology industries, there are a huge number of technology jobs as the tech person in a non-tech industry, being forced into the tech world. These tend to be C-Suite level jobs, so picking up an e-MBA is also be pretty good idea - to know how to talk and operate in their terms, how and why what you're doing for them is what you're paid to do. They have no idea, and very likely a history of being burned by low level tech consultants.

Thanks for the info. I'm kind of burned out on the shiny new things, so C and maintainability sound like a breath of fresh air. I think reading an OS paper from ~1983 that described what is effectively Kubernetes (with working prototype written in ML) really drove home how little the fundamentals of our industry change.

The way I describe my career goals now is: I want to work in a domain where quality and performance is the product.

I hadn't considered getting an MBA and using it in that way, that's something that I will take a hard look at. Thanks for the advice!

Great point. I used to use C++ a lot on Nintendo video games, government contracting, etc. I always used a subset. Three of my favorite current languages are Haskell, Common Lisp, Scala - and I use small subsets of those languages also. I think it makes sense to look at complex languages filtered by what your needs are and decide on a set of features you really need. For me, this makes my code easier for me to read and modify in the future.

It's widely noted that this "select what you want out of the language" works best if you're working by yourself or in a very small team, with no inclusion of third-party code, or no such code that doesn't conform to your restrictions.

It really is best if the language doesn't include the kitchen sink in the first place, if you want the code to be clean in the most general circumstances.

WebGL? I do get that hardcore games are more suited to compiled code non garbage collected though.

I suppose WebGL is okay for shader prototyping, for example using Shadertoy [0]. However, you can use it only within the context of a browser framework. That is still not the optimum deployment nor development platform for a variety of scenarios.

The original joke though, was that C++ was for masochists. I'm not sure developing a web application is any less painfull...

[0] https://www.shadertoy.com/

I used to think like that specially given how poorly many demos run on mobile devices that don't have any issues dealing with ES 3.x games.

However the demos one gets to see from production work at Siggraph are quite impressive when running on proper desktop cards.

>>C++ in 2018? SURE (You masochist)

How exactly do you think AAA games are made? It's all C++ because there's literally nothing else out there which would give you the same performance(and also nothing that is supported as widely by Sony/MS/Nvidia/ATI).

AAA games tend to be C++ plus a range of other languages appropriate for specific tasks.

It's like saying your Ruby while ignoring SQL and HTML/CSS/JavaScript which combined represent far more lines of code and development time.

This was pretty much my response as well. If there are lots of people who can write it, and write it in such a way that it's maintainable, go with what you like most.

This is pretty much my thought. I lead a jumpstarted development effort for a startup last year (we used an agency to get through the initial build). We looked into several options, but ultimately decided to use Rails. Why? We all knew exactly what we could expect from Rails and we knew we could get it to work in the way we wanted without too much hassle.

Sure, we might hit growth problems in years but we can cross that bridge down the road.

I consulted on a site that could get 50 million unique users in any given month, sometimes with large bursts of traffic.

A heavy read site is trivial to scale these days. Serve static assets from CDNs, fragment cache the views, horizontally scale when needed. Rinse, repeat.

Exactly. I've also been involved with read-heavy Rails sites serving well in excess of 1000reqs/sec, and I know that others sites (Shopify et al) do way more. As you point out, it's all about having an intelligent caching strategy and extensive use of CDNs.

Most scaling issues I've seen on well-designed Rails sites have been to do with the DB, not the framework!

I think C++ has some pretty solid libraries. I particularly like gRPC and Thrift.

Rails really nailed the problems of web development as it was 10 years ago by (rightly) pointing out that 97.2% of web projects were all about making an application server talk nicely to a relational database and then generating a front end that reflected the data model and that had javascript that Just Worked (everywhere).

Web dev is in a different place now. Developers don't generally install and maintain application servers from the ground up. Scriptalicious was superceded by jQuery, which in turn was supplanted by vanilla js actually becoming useful. Relational databases are not quite as dead as some people would lead you to believe, but other types of DB are much more common now (key-value stores, search indexes, etc).

Rails was probably one of the last truly open source projects (Most OS these days is to some degree 'owned/developed' by Big Tech) to get big traction and for that it deserves credit. Just the idea that a Danish web consultant could hack together something that became popular and which then allowed him to literally retire and become a racing driver before he hit 30 should inspire us all.

Rails is good for two things: Fast iterating and fast on-boarding new employees.

If you want to start a startup, and you know Rails, use Rails with Postgres.

Do the complicated shit (data science, video uploads, etc) in your other language if you have complicated shit. Use a different subdomain or get nginx to fork the endpoints for the complex shit if it needs to be public.

I've known plenty of people, myself included, that tried something else because of "reasons" but the real reason was I wanted to try some new language or framework but it gets old fast.

> I'm gunna use Riak!

I said. Then I needed to do some random task that would have been trivial in SQL.

> I'm gunna use Go!

I said. Then I spent hours fiddling with types and boiler plate code and catching errors.

These are not solving problems startups have. These technologies solve problems that huge companies have. My only gripe with Rails is that I think it should be JSON-first, not HTML-first, because almost everyone needs an API these days and many people use front end frameworks for HTML, but whatever. It's not that hard to override that stuff.

Agreed with all of these points.

> I think it should be JSON-first, not HTML-first

Isn't that the case in Rails 5? https://guides.rubyonrails.org/5_0_release_notes.html#api-ap...

Yes, I'd forgotten that that was option I should have addressed. The issue is that I want things like cookies to be supported out of the box for things like Ember, even if I want other API consumers to use locally stored tokens. But you're right. There is some attention going that way.

Check out the Rail API gem. It's default in Rails 5 and makes JSON and HTML the default.

> Just the idea that a Danish web consultant could hack together something that became popular and which then allowed him to literally retire and become a racing driver before he hit 30 should inspire us all.

While being successful in all those aspects, DHH is still very active in the development of the framework. He is currently also the CTO at Basecamp. Not really what I would consider being retired.

Also he didn't get rich at least to begin with off Rails as such, which is free open source but off Basecamp which as he is fond of pointing out charges customers money in the old fashioned way. (As opposed to raising VC.)

I have a vague memory of reading an article by him shortly after he got the investment from Jeff Bezos when he spoke in terms of being "retired" (sadly ungoogleable now because "david heinmeyer hansson retired" just gives lots of hits for motor-racing). Of course things change, and he is definitely working now, although his working life seems to consist of very well paid, powerful, interesting and part-time positions, so I think the point stands :)

You're speaking as if Rails is useless now, when in reality it's still a great tool depending on the job, especially since Rails has an API-only mode that works great with the modern SPA front-end ecosystem (sidenote: not every app needs to be a SPA). I built a company with it that provides a developer API, and that has a modern SPA front-end. Rails is still useful, especially for startups.

(And DHH didn't literally retire--he runs his company, Basecamp, which is built on Rails, which he actively maintains.)

> Web dev is in a different place now.

Yup, but why? This is still true:

> 97.2% of web projects were all about making an application server talk nicely to a relational database and then generating a front end that reflected the data model and that had javascript that Just Worked (everywhere).

> Yup, but why?

Mobile and mobile-first thinking, perhaps. "webdev" is far more js-driven than it was 10-15 years ago. I'm not sure whether that's good or bad, but imo that accounts for much of the difference. 15 years ago I could build entire applications with a minimum of JS, and they were acceptable to clients. That's not really the case any more - there's more demand/need/expectation of js in web projects today.

The need to talk to relational database is, ime, as strong as ever, while the need for supplemental data stores is growing, but is rarely the primary focus for any system already in existence.

> there's more demand/need/expectation of js in web projects today

On the backend too?

There are headless Rails applications. Is that what you are talking about? If I understand it correctly, it's essentially a Rails server that exposes an API that a Javascript client uses.

okay so to achieve a good mobile experience, you need a responsive layout and some sort of pjax rendering. That still doesn't explain the massive weight of current front-end solutions.

> ...jQuery, which in turn was supplanted by vanilla js actually becoming useful.

jQuery is written in vanilla js so vanilla js can do anything jQuery can. I'm always irritated when people claim that vanilla js can't do something X can do.

It's hyperbole, but the point is that vanilla JS couldn't accomplish it easily without a lot of headache.

Handling browser compatibility alone made jQuery extremely useful back when it first emerged.

It could be accomplished just as easily by writing your own function just as jQuery did.

My point is that such wording, as above, gave people the impression that jQuery was not javascript and you could not accomplish things in vanilla js. Such false impressions are still around today.

I dunno - I don't think you're gonna win that battle. When a library is sufficiently advanced it often becomes a distinct entity (linguistically, at least) from whatever it's built upon.

See also: React, Pandas, Numpy, Boost, etc.

It might be confusing to those without the context to understand that e.g. React is built on vanilla JS, but I think it's pretty clear to most people that jQuery is built on JavaScript.

In fact the term "vanilla JS" mostly started in response to jQuery itself, so if anything I would argue that the term "vanilla JS" is to blame for what you're talking about.

> by writing your own function just as jQuery did

Sure, and we could all just design our own chips, hand code our own binary to create our custom programming language we use for everything... But humans have a neat ability to benefit from other humans' work.

An attempt to compare writing JavaScript to designing our own chips is a typical response I see from certain individuals online all the time. No knowledgeable person would ever do such a thing but I see it on reddit, and other amateur forums, all the time.

You're making a large and incorrect assumption.

But don't worry, I see this on Reddit and other amateur forums all the time.

RoR is relevant as long as the community is active, as long as there is job demand (see crossover, Stackoverflow, etc.).

It is an excellent framework with gems to act as plugins (rack middleware) to serve websockets, forums, admin interfaces all with a few lines of configuration. Google, Microsoft, Facebook all maintain Ruby libraries in GitHub. So as long as you are doing Joe's textile website, it is the right tool.

Cloud scaling rails can be expensive, as apparent from horror stories [0] but a few manually managed instances with a load balancer and good web servers can go a long way.

It lacks development time relative to python which cater to domains such as data processing and artificial categorization. With extension libraries such as helix [1] which utilize rust to create native extensions and enough development time it has the potential to dominate those fields in the future.

One honorable mention is JRuby and while it isn't kotlin in terms of efficiency, it still lets you use Java libraries when you need any sort of domain libraries.

In conclusion, I'd say it is still pretty relevant today.

[0] https://news.ycombinator.com/item?id=5228200 [1] https://usehelix.com

>Cloud scaling rails can be expensive, as apparent from horror stories [0] but a few manually managed instances with a load balancer and good web servers can go a long way.

I think they are doing something about it. Ruby 3x3 and Rails 6.0. One of the problem is resources, there isn't a massive company like Google / Facebook / Amazon backing Ruby and Rails with Man power and funding. It is all open source.

I am wondering if any is using helix. There were previously another idea Rubex [1] from SciRuby, making Ruby / C Code collaboration easier.


> So as long as you are doing Joe's textile website, it is the right tool.

I don't think Rails is the best tool for that. A static site or Wordpress are probably a better fit.

> Cloud scaling rails can be expensive, as apparent from horror stories [0] but a few manually managed instances with a load balancer and good web servers can go a long way.

It definitely can be, but I think most apps people are working on don't have a scaling issue (at least of the technology sort). When there is a scaling issue, it's often something related to the database (bad indexes, poor instance type, or N+1 queries)

I think there is more to textile than displaying and selling clothes. But, YMMV.

Sure, but much of that process isn't customer facing. I tend to draw inferences when I read "website" as opposed to "web application".

Is this a personal and subjective opinion of yours, or some sort of documented distinction?

It's also good for new projects & new startups.

The demand for Rails people is still there. One just has to be good at it.

Where are all the jobs where you don't have to be good at it to get hired? :-)

Search for PHP jobs.

Of course it is. The question is kind of silly. For basically any startup, my advice would be: unless and until you can credibly explain a genuine reason why you can't use Rails - use Rails.

I'm not some crazy fanboy but until someone can actually name a seriously competitive, batteries-included, all-in-one framework* which delivers everything, or even most of, what Rails does - it is very relevant and you ignore it to your serious disadvantage.

* your list of 30 random npm packages does not satisfy the requirement

> your list of 30 random npm packages does not satisfy the requirement

I like Rails, but to be fair, doesn't Rails also require a list of 30 random gems? Unless things have changed, authorization and authentication aren't even built-in, so people have to navigate random third party gems, and remember, you don't want CanCan, but you want the fork, CanCanCan. Again, I like Rails, and maybe it's still the nearest to an all-in-one framework, but I think somebody who took the next step and created a truly all-in-one framework would win big.

My current project:

  $ grep -c ^gem Gemfile

It's not a matter of how many packages are required; that isn't the issue. The reason "30 random npm packages" doesn't satisfy the requirement while Rails does is that Rails provides a high-level framework for integrating those disparate packages into a single cohesive application, while with npm packages you have to write that framework yourself.

Perhaps the best example I can give for this difference is Devise, an authentication plugin for Rails. Have a look at the instructions for setting up Devise on Rails: https://github.com/plataformatec/devise#getting-started You just add the dependency and boom, you instantly get a database migration for storing authentication data in your database, automatic integration with Rails's email notification system, a single command you can run to generate all boilerplate files, and a single line of code you can add to your controllers to automatically enforce authentication for any particular action. With a similar authentication package in a Node application you'd most certainly have to set all that up manually.

> doesn't Rails also require a list of 30 random gems?

    my-MacBook-Pro:production-web-site me$ grep ^gem Gemfile | wc -l
I have mixed feelings about this. On the one hand, the framework isn't strongly coupled, tested as a whole, and opinionated like in Java and .NET land.

On the other hand, overriding the "default" Rails behavior for e.g. logging or SAML is pretty easy as long as you can find a gem compatible with the versions of all your other gems. This can easily spiral into out of control technical debt where you're stuck using gems from 6 years ago out of fear you'll tug on one of them and bring the entire house of cards tumbling down, but I've consistently been surprised at how little effort has been required to do gem upgrades as long as they're planned carefully.

Authentication is built into Rails, albeit in a less "batteries included" way than something like Devise. You'll have to code your own user model, but `has_secure_password` will give you perfectly fine security around storing passwords.

And while gems like CanCanCan are great, not every application needs them, and it's relatively straightforward to set up authorization logic directly for most simple cases (i.e. something like "users control their own things, admins control everything".

You're right in the sense that I've very rarely seen sizeable apps that are mostly "stock" Rails outside of things literally developed by Basecamp.

Django fits that description.

Came here to say the same thing, and add that with Django, you have access to the amazingly vast landscape of Python libraries. Just being able to spawn Celery jobs is a huge plus.

Couldn't see any advantage over Sidekiq, Resque and friends. Not saying it's bad but just that the Ruby community has got your back for any web development need you might have...when working with Django I didn't get the feeling I am working with superior libraries.

An advantage of Celery is that it doesn't require payment for an enterprise version to add things like scheduled tasks.

If you're talking about Sidekiq there's free open source solutions for that in Rails world. https://github.com/moove-it/sidekiq-scheduler https://github.com/ondrejbartas/sidekiq-cron Besides Sidekiq is just one out of many.

Good to know, cheers

One thing I'll say about Node is that the module names seem to be semantic for the most part, unlike the cute names gems seem to get. Walk into a Ruby developer's office and if you see a white board scribbled with random words, you don't know if they have reached the point of stress where their mind has started to break with reality, or if it's just a list of gems for their new project :-)

I think Django comes close to Rails with regards to productivity. Granted, Django has slightly more overhead to get started, but Django also includes an admin interface and a built-in auth system, which Rails does not.

I work in a lot of Django shops and my Ruby is nowhere near as good as my Python but I'll pick Rails every time if I'm working on a side project. Why? Because the development velocity when using it is unparalleled. I can have an MVP up orders of magnitude quicker than I can with Django/Flask/Twisted. You're absolutely right on the Admin interface and auth, but auth is a gem install away [1] and Django's admin won't fit my requirements more often than it helps; I can seldom justify exposing it to end users and it's a hideous undertaking to extend it meaningfully (I gather this is one of the reasons it is a bit of a laggard compared with the rest of the framework. We only got mobile support out the box in 2.0 for example [2]).

Other reasons I enjoy Rails:

- Scaffolds allow me to have CRUD support for any model I want with one command (combined with auth, I have Django's admin, more or less)

- JSON views without a third party library (surely this is pretty standard for a web framework in 2018 in most cases?)

Other reasons I don't enjoy Django so much:

- I can't think of an eloquent way to phrase this but Rails values my time. With Django I'm doing menial minutiae like creating a directory for my app's templates before it'll serve a page. Why? I know 'magic' is anathema to the Python community but context switches like this shouldn't be there when I'm trying to get an app up and running at speed

- I feel like it's stewardship is bordering on begrudging: Why are websockets (and JSON for that matter, but I've touched on that) not present in a 'kitchen-sink' web framework? I'm not sure why we're worrying about master/slave DB terminology [3] when there are axiomatically more pressing technical and adoption-related issues at hand.

Django is a fine web framework, and perhaps the best-in-breed for Python, but it feels miles behind where it should be at this point and I'm not really sure why.

[1] - https://github.com/plataformatec/devise

[2] - https://docs.djangoproject.com/en/2.1/releases/2.0/#mobile-f...

[3] - https://github.com/django/django/pull/2692

You might know Python but it sounds like you don't know Django very well.

Django does have built in JSON support[1]. There's also Django Rest Framework[2], which while not built into the core, is well supported and hardly a burden to add.

And finally, Django's "scaffolding" functionality is built around its models. You define your model as a plain Python class inheriting from Django's model class, and then the various generic[3]/"scaffolding" views work by being told what model they're for, with the ability to override and extend whatever you want to.




I fear you've contrived to miss both underlying points.

In order to access a JSON endpoint in Django, I need to install DRF, integrate it with Django, configure it, edit my urls.py and perhaps set up a serialiser. I won't detail the procedure in your first link because I think you very well know that is simply a response object with a crude serialiser and a content header set. The inclusion of both misses the point, which is that in Rails, I would simply navigate to /model-name.json (so in fact, yes, it is absolutely a burden to go through that when you compare the two). That's it. No parsing. No route configuration. No concerning myself with edge-cases unless I'm doing something odd. Requirement satisfied, and I can sleep soundly knowing I'm not bequeathing some custom car-crash on whoever inherits my codebase. Debate aside, I wholeheartedly encourage you to try out this framework sometime - I've found going from Django to Rails to be an absolute joy to develop with.

Generic Views. Ah. Well that has its own set of problems. Why am I wading through the docs (or more accurately ccbv.co.uk because the actual docs are a verbose, time-sinking miasma; recall that in my previous comment, I am championing the development-velocity of Rails in contrast to Django) to discover which method from which class I need to override to implement the functionality I need? I can intuit a lot more now, after doing this for years, but why do I need this knowledge at all? It is the job of the framework to abstract and ameliorate bullshit. Corollary: why is it that every Django codebase I inherit has at some point converged on its natural state of 'car-crash' because of the combination of a bunch of rigid inheritance chains and my predecessors not putting in an escape hatch? At risk of being a bit of a zealot, MI is almost always an anti-pattern and I would prefer the flexibility afforded to me by composing things in the traditional fashion.

In Rails, I would build a model like this in my shell: `rails g scaffold Blog title:string content:text`. That's again, literally it. From that, I now have a Blog model with title and content, created and updated fields, controllers (or 'Views' in Django parlance for some reason) and both HTML and JSON views ('Templates', in Django-land), unit tests, assets for my asset pipeline (we don't have to run collect static btw - it seamlessly transitions into production because it was designed on the basis that people might actually be deploying their projects), my equivalent of urls.py has been updated to accommodate my new model and I have full CRUD functionality at this point. Genuinely, I implore you to try this framework. Django has come a long way since I first used it but it's nowhere near the level that modern frameworks like Phoenix [1] (you should give this a go too - the third party libs aren't quite there yet but it's a really well thought-out framework) are at, and I'm genuinely curious as to why.

[1] - https://phoenixframework.org/

We'll have to agree to disagree about Django. I think Django and Rails both offer good developer productivity/velocity, they just make different tradeoffs. Django tends to be more explicit, which might lead to a slightly higher learning curve, but after that I've found it's easier to trace through Django applications to understand what's happening.

I've seen my fair share of terrible Django and terrible Rails applications. Bad code can be written in any language and framework.

Don't get me wrong, Django definitely has its pain points, but I think it offers a very competitive alternative to Rails.

I definitely agree with you on Phoenix though! Elixir/Phoenix is my current stack of choice. I actually think they do a really great job of capturing the high points of both Rails and Django while also improving on the weak points of both as well. (For example, Phoenix offers a lot of the "magic" of Rails but it's all backed by explicit code that Phoenix generates while creating your project.)

The source of Rails ease-of-use appears to flow from Ruby's object model, which I have yet to see a more elegant one outside of the Smalltalk ecosystem. Ruby's semantics just seem to be a natural fit for the web, where visual presentation of information seems to almost demand a truly-flexible set of tools.

You want a smooth progression of tooling that you can approach and slowly clarify ever-finer approaches to over time. The object model is the base of the pyramid, it's the thing you rely on when nothing else solves the problem, you know you can always invent a new kind of object hierarchy by refactoring to BasicObject, obliterating stdlib semantics with a veritable flamethrower. I've never put such a thing into production, because I know there's always less drastic ways to define, mold, shape, and extrude abstractions.

With less semantically-fluid languages, you wind up relying on the same few tricks over and over and over again, because they solve problems, albeit poorly and opaquely. This flows, again, from the underlying approach to typing. Python is dynamically typed, which keeps it from being totally unworkable any time you need to do something special or cross-cutting, which is absolutely a need in the web world, but it's structured enough to where you need to devote library-level amounts of thought into coming up with clean, semantic abstractions that are easily traversed, something Ruby just comes with out of the box.

I would wholeheartedly agree that the object model confers a large advantage to Ruby; I hadn't considered your Python point but you're absolutely right - there are demonstrably fewer ways to solve certain problems. I sometimes wonder what Python would look like if it were easier to differentiate between an attribute lookup and a method call.

>Why are websockets ... not present in a 'kitchen-sink' web framework?

They are.

Django Channels: https://www.djangoproject.com/weblog/2016/sep/09/channels-ad...

Right. Last I checked it was being brought into the fold but it hasn't been - I still have to install a third-party library to get what is rapidly becoming a normal thing to have in a web-framework. My point was more "why isn't this in my kitchen-sink framework" more than "I don't know how I would go about integrating websockets in Django"

I did full-time Ruby on Rails development for between three and five years. These days, a huge chunk of what's "included" in Rails is stuff I don't need, and a huge chunk of what's not included in Rails is absolutely essential:

Stuff included in Rails I don't need:


* Heavyweight controllers

* Server-side HTML templating

Stuff not included in Rails that I do need:

* Basic DB-level sanity checks, such as uniqueness constraints that actually work

* Any kind of real frontend framework

Stuff that I desperately want that Rails makes fundamentally impossible:

* Sane concurrency

* Not having to pull my hair out over random values in my codebase magically turning into "nil"

The best pattern for developing basic web applications that I've seen lately is basically:

* Use React for the UI. (If you prefer another front-end framework, I don't really want to fight about it, but React is pretty damn good.) Host your statics, well, statically.

* For your backend, use the simplest possible mechanism that receives HTTP requests and emits JSON. If you're married to Ruby, Sinatra does this. Flask does this. Node and Go and Java all have relatively simple mechanisms for this. The mechanism doesn't matter. Route HTTP requests to function; return JSON (or some HTTP response object that encapsulates your JSON) from function.

* For interacting with a relational database, use sprocs. SQL isn't hard; ActiveRecord is probably the best example of the Rails antipattern of, "make easy things easier, and hard things harder".

Elixir/Phoenix is the spiritual successor to Rails. Same philosophy of batteries included, developer productivity focussed etc. But with lots of great new shiny things, for example websockets is built directly into the framework, its not an add-on. Its not a direct upgrade, but if you value Rails definitely check it out

The Elixir community would LIKE it to be a spiritual successor for Rails, but it really isn't. If only because of the learning curve of understanding Elixir. Sorry to disappoint anyone but Phenoix is not going to be the new Rails/Django.

> If only because of the learning curve of understanding Elixir. Sorry to disappoint anyone but Phenoix is not going to be the new Rails/Django.

The learning curve isn't too bad.

I've been a Rails developer for quite some time and am picking up Elixir / Phoenix in my spare time while building a single side project. This is my first real attempt at picking up a functional language too.

The project I'm building is an ambitious project (users, accepting stripe / paypal payments, lots of data modeling, real time aspects, decent amount of logic I haven't implemented in other more familiar frameworks, etc.) but thanks to the community and open source projects to look at I'm making reasonable progress.

Of course I'm not as productive as I am in Rails but that's because I'm only putting in a few hours a week into this project (while learning Elixir / Phoenix as I go).

I like Elixir and Phoenix but I agree with you.

First I think a very large number of developers don't care for functional programming.

Then Phoenix is mainly run by only two persons, Chris McCord and José Valim (who also manages Elixir and Ecto). If I compare the pace of development and what you get out of the box with PHP/Symfony (I don't know RoR) it's quite clear that Phoenix is not there yet (without even speaking of the difference in ecosystem size).

Having said that I'm excited for Phoenix 1.4 https://github.com/phoenixframework/phoenix/milestone/17

Elixir/Phoenix is great, and it's first-party support for websockets is an excellent selling point! That said, I feel compelled to mention that rails does have websockets built into the framework now too, as of Rails 5.

There is no comparison between those two socket implementations. There's several orders of magnitude difference between what elixir and Ruby will support on a single server there.

Please, let's lose this Elixir = Ruby.new nonsense. Once you get beyond the superficial syntax similarities between Elixir and Ruby the 2 languages couldn't be further apart. Ruby is mutable/OOP whilst Elixir is immutable/FP. Diametrically opposite so anyone who is heavily invested in Ruby's OOP mindset is going to have a shock if they dive into Elixir.

This is the most salient point in the elixir thread so far. If you are heavily invested in OOP, no functional or immutable language is really going to do it for you. Period.

Except for 2 things: Finding developers. while it's possible it's much harder that say Java. You'll be in trouble if you are not in a metropolis and need 5+ rails developers. Long term sustainability. While it will work for your MVP, at some point you will need to rewrite it in a language that sclaes to 10.000s of lines of code and that will be painful.

Yes, this is a commonly overlooked consequence of adopting Rails. Here in London recruiters are falling over themselves trying to hire Rails developers as so many companies built their stack on Rails. However, once you leave the capital demand for Rails more ore less evaporates. Rails only thrives in tech hubs, probably due to its association with startup culture. Once you leave the capital PHP, Java and ASP.Net dominate.

Once you leave the capital everything evaporates.

RoR has always been rather impenetrable to me, more-so than some late-stage/terminal Node-based projects. I recently wanted to remove IP logging in a RoR application but I was unable to find the relevant code anywhere, the only hits that grep spat out where the migrations and I couldn't figure out how to rip all that out. In the end a project developer pointed me to the correct file and I had to change a single line (according to their guidance, I had no idea this line even related to IP logging) which fixed it.

I don't think that this is something I want in my project, I think I'll keep with .NET and Go even if I don't get the "competitive batteries-included all-in-one framework" packaged in.

(Well and there is always the issue that most larger RoR projects like to pull a lot of resources. And seriously the biggest three VMs on my host are an RoR application and the SQL Server which runs both MySQL and PG and the only node.js app I run)

Rails is definitely a framework where it requires some knowledge of the framework to really be effective. The adherence to convention over configuration means that a whole lot of things are pretty opaque, and if you don't know the conventions it can seem impossible to know how something is happening (logging is a great example). Javascript is the opposite extreme - nothing is assumed and everything is explicit, so there's a clear and obvious spot (at least in well architected programs) where something is configured.

When you know the framework well, however, I find one of Rails' strengths is that it massively decreases the time it takes to get familiar with a codebase. There's never a question of how a developer has organized their code, or configured logging (to take your example), because it's not a choice that Rails gives you - every project is going to work the same.

> I recently wanted to remove IP logging in a RoR application but I was unable to find the relevant code anywhere, the only hits that grep spat out where the migrations and I couldn't figure out how to rip all that out.

Usually you'd just create a custom logger[0] and tell Rails to use it[1]

[0] https://ruby-doc.org/stdlib-2.5.0/libdoc/logger/rdoc/Logger....

[1] https://guides.rubyonrails.org/configuring.html#rails-genera...

It wasn't putting the IP in the log but in the database and along the username and session data, there is an open ticket about that behavior too. Since I'm in Europe/Germany, this kind of data storage would have been a no-go even before the GDPR.

It sounds like you had to remove the Trackable module from Devise - which would indeed be one line of code to change in a Rails app, but quite hard to figure out if you didn't know. However, Devise is a third party gem which is often used with Rails but isn't actually a part of Rails, so can you really blame Rails for this? (And, unless it's for a very specific string, is grepping a codebase that you have no understanding of ever really a successful strategy?)

I blame the coding practises of the rails devs, not the gem itself.

Grepping can be a successful strategy, esp. when you know what you are looking for and you can search the database column in the code

I can't in all honesty understand why you wouldn't just Google "rails login current_sign_in_ip", the top three hits for which would probably all put you on the right track. I would say grepping through the code of third-party libraries would be something I'd do only in desperation when working in an unfamiliar codebase. But hey, each to their own!

Oh, don't worry, I did Google that. Just didn't work because none of the results helped or put me on the right track or were just plain too confused to be understandable.

How do you think .NET Core 2.0 MVC compares to Rails nowadays? I've been insanely productive with it. Willing to give Ruby/Rails a try, though.

Faster in every sense.

Go with Ruby/Rails if you don't need the JIT/AOT compilers and high performace GC algorithms.

Just FYI - Ruby 2.6 has JIT, not far off being released: https://www.ruby-lang.org/en/news/2018/05/31/ruby-2-6-0-prev...

I prefer .net core.

But it's missing scaffolding and stuff like that.

One reason is that the founders don't know rails and it's far from obvious to pick up.

Another would be that sometimes a train is not the most practical transportation to travel a few blocks.

Not saying that it is better but Laravel is mostly rails copy. And has huge active comunity.

Share code between client and server side to get client side prediction and server side validation.

I'm exploring Nest [0] for my next project. It is a "glue framework" on top of Typescript and many Node libraries, with an Angular like style. Every Node library used has a framework module which provides the integration with the framework [1] so it appears to be both flexible and easy to use. I am just starting to explore Nest and I'm liking it, my previous experience on the backend was on Django for many years and Nest seems like a breath of fresh decoupled air, coming from this heavy monolithic experience.

[0] https://nestjs.com/

[1] https://github.com/nestjs

I've been interested in trying out Nest too. While I've just been toying around with it, it seems to strike a nice balance between fast to write and easy to scale (in terms of growing the codebase). Hopefully then the path from MVP -> full product becomes smoother.

It also makes good use of what Typescript has to offer, which IMO is very much welcomed.

I've been using nest as well on a project. It's nice, but it's miles behind Rails.

Why do you think an all-in-one framework is an advantage? As soon as you want to switch something out you end up fighting the framework and the tutorials. Better to start with dedicated libraries that each do one thing - it's inevitably where you're going to end up.

(Not that I'd consider an untyped ecosystem in the first place, especially one as fond of "magic" (e.g. monkeypatching) as rails. I have sympathy for just getting something working as quickly as possible, but there comes a point where you're storing up too much trouble even for the short term)

> it's inevitably where you're going to end up

If the project's successful. The chance that most of what we're building with Rails hits the required escape velocity to require something other than Rails is a "Nice Problem".

For the vast majority of things people are building for the web, "CRUD+Auth+Billing" is all that's needed, maybe with a few API hooks into something more novel running on different infra.

If you then need it, then you can just build out a few more services with a few more API hooks, and then transition to a non-Rails stack as required.

It's great if you have unlimited resources to spend the time setting up the perfect tech base for a project for if it does eventually require scaling above what, Basecamp for example, can handle - but that seems like wasted resources for a great deal of orgs that don't have that level of backing.

Of course, if you truly need something novel, then it's a moot point, if you can't achieve what you need to with a stack, then just don't use it.

> If the project's successful. The chance that most of what we're building with Rails hits the required escape velocity to require something other than Rails is a "Nice Problem".

> For the vast majority of things people are building for the web, "CRUD+Auth+Billing" is all that's needed, maybe with a few API hooks into something more novel running on different infra.

> If you then need it, then you can just build out a few more services with a few more API hooks, and then transition to a non-Rails stack as required.

True as far as it goes. But if we're just talking about a prototype for validating product/market fit, with the intent to transition to a more maintainable stack as and when that becomes necessary, what's the problem with "list of 30 random npm packages" as a starting point?

Rails can take you much further than MVP though, as evidenced by all of the companies that reach breaking point with it. Basecamp, Github, Shopify - all reached proper business status on Rails (arguably Twitter too, although business is a bit of a stretch...).

We can argue it from both ends, but I see Rails as the middle ground, and allows you to go from MVP to $XXm ARR on the same stack. A hacky MVP with 30 npm packages doesn't have a clear path up the tree to grow without serious changes, and a custom architecture is useless if you don't get any users.

> A hacky MVP with 30 npm packages doesn't have a clear path up the tree to grow without serious changes

I see it as the opposite: it's clear which functions are the responsibility of which library, and it's easy to replace the ones that are becoming blockers and leave the ones that aren't. Whereas with Rails if you keep it monolithic then upgrades always become a huge pain point, but if you try to cut out pieces of it you're going against the grain.

(I used to love TurboGears nearly a decade ago, because you could use it like a monolithic framework to start with but it was explicitly a collection of standalone libraries underneath, and so once you started needing to do different things to individual pieces it was easy to. The modern web ecosystem could do with something like that, IMO (though personally I'm sticking to ScalaJS for the type safety))

> what's the problem with "list of 30 random npm packages" as a starting point?

The dude starting with rails will probably be done with the MVP before you decide _which_ 30 random npm packages to use.

I'd probably just copy/paste from my current project TBH, which takes all of 5 seconds.

I think the types argument is bullshit but it's just my opinion. Do python or ruby devs really feel they are less productive than java devs because they have no types? What I see happening is languages like java becoming more dynamic (var etc) and languages like ruby/python getting better IDEs (auto completion will continue to improve).

I'm absolutely terrified of refactoring in big python, ruby, or javascript codebases, because there's less chance that I'll be able to find all the side effects of changing something. Tests help, but maintaining high-enough test coverage over possible code paths can be harder and less useful than working with a type system and writing fewer tests.

> What I see happening is languages like java becoming more dynamic (var etc) and languages like ruby/python getting better IDEs (auto completion will continue to improve).

I agree that that's what's going to happen in the short term, but var doesn't mean becoming dynamic; type inference doesn't compromise soundness at all. I think it's going to be much easier for sound type systems to get good-enough inference (indeed Hindley–Milner already offers "perfect" inference: you don't need to write any explicit types if you don't want to) than for dynamic languages to retrofit soundness. And while one can live with a few unsound constructs as long as it's locally clear when unsoundness is happening, as soon as you have pervasive soundness issues with action-at-a-distance your type system becomes almost useless.

> Do python or ruby devs really feel they are less productive than java devs because they have no types?

Yes, I do.

OK, it's a fair opinion to have. But that's all it is, an opinion. Also - what makes you stick to python/ruby then?

I don't know about ruby and python but in JS there a significant number of projects that aim at adding a type system on top of the launguage

I don't think it's such a huge trend, if it was Python wouldn't be one of the top 3 most popular languages in the world. Yes, there is typescript for Angular. Outside of that how often is it used? Pure JS is still used tons.

It may not be a "huge trend", but those investing into static typing reap the rewads. Facebook rewrote messenger in ReasoML, bugs reported by users went from hundreds a year to less then ten. Fearless refactoring is another plus, the compiler will find everything you need to change to make the program run correctly.

Python 3 has type annotations and there are static type analyzers for it.

Var is hardly more dynamic. Type inference is comes from statically type functional languages.

Java's var is only for type inference so nothing to do with dynamic typing.

> Why do you think an all-in-one framework is an advantage?

Because it has allowed the community to develop a whole lot of well-integrated, batteries-included libraries that span the from the model layer to the frontend.

I hate to break it to you, but Rails doesn’t span the frontend. Hell, the frontend isn’t even written in the same language.

Of course it does. Not in SPA-javascript, but there's a ton of support for erb views:


I’m aware of this; I did Rails development for like five years. Server-side HTML templating isn’t a complete “batteries included” frontend solution anymore. In fact, it’s usually the first part that gets thrown away.

What makes you think Ruby is untyped?

I think they meant “dynamically typed”.

Django fits this bill.

Curious why someone would pick rails over php in 2018. Existing pool of developers perhaps.. Any other reason?

Because even in 2018 PHP is still PHP?

What does PHP mean to you? What are your personal views?

From a language perspective it's stable, fast, easy to deploy. Why wouldn't you choose to use it? For most it's not a difficult language to learn and start using.

Here's why I wouldn't choose it. When I look at a screen of idiomatic, PSRx-compliant PHP code I'm lucky if it contains 10 lines of code. Most of the space is occupied by KR-style space-wating layout plus blank lines between every line of code. Then there are the half-screen doc comments. Ruby, by contrast, is concise and code-focused instead of boilerplate-focused.

PHP makes it really easy to write insecure software, because the first googleresult is often outdated and hacked in a short time by automated scripts.

The defaults of functions/methods in the standard library are often insecure.

if you want to write good PHP i can recommend following resources: https://paragonie.com/software Would use their stuff if i wrote PHP https://www.phptherightway.com https://phpdelusions.net even though the name sounds abrasive it is a good resource on dbaccess if you want to know specifics. It is from a guy with several SO gold badges.

laravel can do all that

Right tool, right job, etc. I built and run an internal tool for a company that went from a very dated coldfusion setup, to a cloud crm (expensive), to now simply using the rails application I built for them with fantastic sorting, searching, mass updates, login features, and export capabilities, you name it. It's has over 1M db records and is plenty fast for any mix of criteria.

Really cheap to run, low-low-low maintenance. I don't even need to touch it except if there are some security bugs that need to be patched and heroku handles backups automatically. In the event heroku has problems I run my own cron-job that does backups of the psql database and the application itself is put under version control.

I'm not sure there is another framework I could have pieced together such a smooth application with anything else in the amount of time and resources I had available plus without having to worry about it ever breaking because of some weird bug. Stability is very important for many businesses.

Once in a blue moon a new feature is requested and doesn't take long to make some changes. Now, would I use rails to fire up a basic website like I did in the past? No. I'd grab a static-gen like Jekyll and maybe some PHP to handle mail if needed.

Almost every, and probably every, language that has been used for serious production is relevant in 2018. COBOL is still one of the most important languages in the belly of a lot of financial and public software.

You wouldn’t build something new on cobol if you could avoid it of course, but rails is not cobol. Ruby and rails are still good at getting things out the door.

I wouldn’t personally touch it, but that’s because I’ve never heard about anyone using it in my country. If you live in a place where a lot of shops use ruby and rails, then why not?

Changing tech isn’t easy, so you should only do it if you’re motivated. We’ve been doing more and more JS/Node where I work because it’s really good at getting things done quickly, sort of similar to why you’d chose ruby and rails. However I’ve been a C# developer for years, and I’m nowhere near as good in the JS environment as I am in .Net. I’ll get there eventually of course, but I probably wouldn’t without the internal motivation of actually enjoying the change, partly because JS is so great at getting things done.

The key questions to me when chosing a language would be, do I really want to learn it? Why do I want to learn it? And also, is anyone in my area hiring for it?.

> We’ve been doing more and more JS/Node where I work because it’s really good at getting things done quickly, sort of similar to why you’d chose ruby and rails

I assume people make them comparisons because both ecosystems have a lot of third party libraries, which means if you want to add some functionality there’s probably a library out there for it. I don’t really feel that comparisons like this are really that accurate though (and are often made by people who don’t have experience with Rails).

If you are using something like Node or Go you need to have knowledge about which libraries you need to use (bearing in mind that often changes every year or so, compared to the Ruby ecosystem which is a lot more stable) and write all the glue logic to make them work together yourself. With Rails you can literally build a blog by running a handful of commands and editing a couple of views, and have something up and running in less than 15 minutes.

The beauty of Rails is that it’s opininated enough, that you can build a pretty decent application just by using what it gives you out of the box. Yes you may want to add Sidekiq for better performance of background jobs, or Devise to avoid all the repetitive code you need to handle user accounts, or add RSpec because TestUnit is the devil, but those aren’t required to get something done.

I only meant to compare them in the sense that they are both really good at getting a working prototype up and running fast.

You’re absolutely right that this requires knowledge of packages for node/js. We haven’t been using a whole lot of modules to achieve this, but we certainly haven’t used just Node/JS either.

For whatever it's worth: at Matasano we saw more Rails apps from startups than any other framework.

At Latacora that has changed dramatically; we see Django a lot, rarely Rails, but most commonly we see Go, Python, Node, and Java API servers with React frontends and minimal frameworks.

From my vantage point: Rails is still relevant and still a viable option for building new stuff, but it is less relevant than it used to be.

I see the same trend on Indeed.co.uk. In the last year or so there have consistently been about 40% more Django roles than Rails in London. At Angel.co, however, Rails is still more popular. I put this down to the general increase in Python adoption rather than anything specific to Django.

How does Laravel rank in there?

To my knowledge I've never been asked to look at a Laravel app.

To me, every framework or web oriented language out there should have a big tutorial similar to


because it covers a lot of things regarding classic everyday web development which is extremely useful to beginners. So just for the existence of that book I'd say yeah, Rails is still relevant.

There is also this one for flask which builds an web app from start to finish for people who like Python.


A lot of ruby books features the design and development of complete medium sized application from start to finish in various domain.

That's the kind of thing beginners should learn instead of 'Docker' or 'React' because they've heard everybody constantly talking about the latter.

I second this, Hartl's RoR tutorial is one of the best introductory books to a framework that I have ever read. I wish every framework would take notes from that tutorial.

> I would keep learning plain Ruby, Elixir, Phoenix and JavaScript as my side tools

> I wouldn’t spend too much time learning programming languages outside that list as you need more tools in your toolbox but too many tools may get your toolbox cluttered

You suggest not cluttering your toolbox, but your recommendation is a list of completely interchangeable dynamic languages?

I wouldn't call Ruby and Elixir interchangeable, even if they happen to look superficially similar on the surface.

I would recommend learning either language outside the context of a framework like Rails or Phoenix, though. There's immense value in knowing the underlying libraries (Rack and Plug, respectively) and the HTTP servers underlying those (Cowboy and Unicorn/Puma/whatever-is-popular-nowadays, inverse-respectively). Once you know those, you'll either gain an appreciation for the existing frameworks or have the know-how to improve and/or replace them.

Javascript, Ruby, and Elixir are emphatically not interchangeable.

Elixir is compiled, the other two are interpreted.

JS is supported natively by all browsers and is at its core an event-driven functional language, the other two are not.

Ruby is probably the comfiest OOP language out there, and certainly the one with the best standard library.

These are not the same languages.

> Ruby is probably the comfiest OOP language out there, and certainly the one with the best standard library.

What does Ruby's standard library have that makes it superior to Python's?

I've found it easier to work with strings in Ruby than in python. Not sure if it's "better."

> Elixir is compiled, the other two are interpreted.

How can a language be intrinsically compiled or interpreted?

Sure, Befunge is one example of a language that's notoriously hard to build a compiler for but easy to build an interpreter for, but surely that can't be said for Ruby and JavaScript. V8 is a good counter-example to the claim that JavaScript has to be interpreted.

>How can a language be intrinsically compiled or interpreted?

This is a great example of an academic nondistinction that is completely worthless in practical matters.

It is highly relevant because we in industry are the ones who actually have to work with and scale all these needlessly slow piece of shit language implementations. Implementations that get a pass because nobody can be bothered to have this conversation. Languages that are dynamic or good for scripting, rapid prototyping or whatever the hook is do not need to be implemented using slow and inefficient techniques and shouldn't get a pass for it. Similarly terrible languages shouldn't get a pass for being terrible just because they happen to have fast implementations.

It's precisely in academia where it is a worthless nondistinction, there a language doesn't even need to be implemented to be studied. For instance lambda calculus predates the programmable computer.

In context, it's entirely reasonable to assume an implicit "the only realistic implementation of X to choose for production work"

And V8 isn't a realistic implementation of JavaScript for production work?

While as a fan of one particular language I tend to agree, I found http://www.jerf.org/iri/post/2908 a somewhat convincing argument that perhaps my view isn't so well-rounded as I thought.

What's the critical difference between BEAM bytecode and Ruby bytecode? It's IMHO not a very important distinction if the compilation happens ahead of time or when the program is started, but maybe that's not what you're talking about? I'm not really familiar with the internals of these two.

I commented a few months ago that if I was starting a new company today I’d use Rails without hesitation. https://news.ycombinator.com/item?id=17355776

Well, I’m starting a company and our current prototype is Rails. I don’t regret my decision at all, although after spending the last four years writing exclusively Python it’s been a little jarring. The muscle memory is still there though and after two weeks I’m almost back to 100%.

I really missed Active Record and all of the conveniences there around migrations. When you’re prototyping and constantly evolving your data model - but still intend to throw real traffic at it - flexibility here with the hardened foundation of PostgreSQL is vital.

The framework and language aren’t red hot anymore but they are far from dead or even stagnant. There’s a tremendous amount of active development happening in Rails.

Meanwhile I’ve been learning Elixir via a course called “Elixir for Programmers” and love it a lot. I didn’t want to risk building things on Phoenix at this stage. It’s full featured and likely more than capable but the smaller ecosystem and it being a first production app for me wasn’t worth the risk. I’m dying to put the actor model and OTP to work in an environment where it would really shine.

Anyway... still loving Rails and Ruby! A lot! With SASS, Haml, rake tasks, lots of data fixture tools etc... and no BS with React and webpack, slow pipelines and maintaining two codebases for an API and a Frontend... you’re left with lots of functionality being built daily. It’s great.

Don’t get me wrong, React is awesome and it’s certainly the new foundation of UI development. But... the ecosystem is still learning to walk imho. Redux isn’t the answer. GraphQL is great on paper but the way people use it is not ideal (coupling data to ui). Long way to go before I’d go 100% JS.

This reminds me to book a ticket to rubyconf.

To be fair the technology stack is almost irrelevant when you are starting a company. write it in perl, python, rails, hell write it in old school cgi and use c++. It all comes down to how many sales did you make today. The clients will rarely care what language was used behind the scenes.

That’s a pretty myopic way to look at it. Sure, use what you know and forget the branding of your technology, I agree. But you need to be cognizant of short term vs long term gains, gasoline you can pour on the fire (libraries and integrations), the team you are going to build, the deployment story, the ops story, etc...

I’ve seen companies that made poor technical decisions up front spend years paying for those mistakes. One could argue that those mistakes are what even put them in the position to where they could pay em down... but there is definitely a way to measure twice/cut once and save yourself from a world of hurt while still moving quickly and making sales.

My point was that the technology in a startup is nearly irrelevant if you don't have sales.

Step 1-1000 of building a startup is selling.

It's not an irrelevant choice. Your talent pool will look very different with each of the options you mention.

At a minimum you should be writing your first iteration of a product in something that's clear and easy to understand, if only so that the effort of translating it to something else when needed is less painful. Rails is a great candidate for that.

But even with that being said, prototypes and v1s have a nasty habit of continuing along far past their originally intended expiration date, and if your only criteria is what gets sales today with no regard for future maintainability, you're taking on a very significant debt that is going to be hard to repay when you do need your tech to be easy to work with and performant.

I refuse to write Perl. If enough people feel the same way, Perl is not a good choice.

Long term perhaps but short term it means increased salaries.

You're not wrong.

Or you are not the right choice to hire...

Its kind of ridiculous that in this industry we are expected to jump on new trends every couple of years to stay current, rather than learn how to use the tools that we do have well. Sure we get some benefits, but 90 % of the time it seems we are just chasing fads.

(Yes is my answer to the question).

This is the only correct response.

I’ve been doing this a long time, and it’s demotivating to see every new generation of noob developer turn their nose up at the work of the generations before.

It’s not as if Rails has stagnated - it keeps getting better with every release. You could be excused for wanting to switch from Java servlets and PHP apps back in the day, because the Rails dev experience was that much better. But all of this Javascript crap is just re-writing for the sake of re-writing. And it happened so quickly - not even six years ago, Rails was the obvious choice for a new web app. Technologically, what has changed since then? Very little.

People unironically ask if Rails is “still relevant”, and then switch back to their (hideously slow, JS-based) editor to grind out spaghetti code in node, not even stopping to wonder why their NPM dependency tree has sixteen different versions of the same json module.

Such a waste.

That happens mostly in front end, backend world moves slower. It's why I just don't like front end coding anymore, I feel like I have better use of my time than learning a new framework every 3 years.

Front end is way worse, but a few years ago we were all told to jump on the Mongo bandwagon. Now we have serverless. Sue these things do have use cases but they are oversold a lot of the time.

If you ever want to play "shock a hipster" tell them when the underlying language came out that their framework depends on.


Rails is still probably the most productive* web framework out there. It's got a mature ecosystem that covers it's weaknesses.

* productive as in easy to get started, easy to iterate, easy to get things done.

Granted you know Ruby well and like coding in it. The amount you need to learn if you don't know RoR or Ruby is huge... You might get some stuff running fast copy pasting some example but claiming that it is all super easy to do anything meaningful is misleading.

This was exactly my experience. I struggled building with Rails, and every day was an uphill battle trying to learn the machinery. I switched to Node, and feel my better. My structure isn't nearly as pretty, optimal, or efficient now, but I'm actually learning the base concepts and understanding what I'm doing.

The example of why Elixir is less productive makes 0 sense:

Doh Phoenix and Elixir are trying to do all the best to help developers be productive, when you are a technology that promises such a huge scale you need to introduce practices that need to be decoupled => bit slower for developers.

Good example of this how a “model” writes to database. Module (with schema) need to call a changeset, changeset call repository, repository writes to database (example). That’s 3 manual steps where in Rails you have in in one.

Phoenix & Ecto work that way because 1) Elixir is functional, and 2) ActiveRecord mixes a lot of concerns that suck in the longterm.

IMO the real thing holding back Phoenix/Elixir is deployment & operational issues. It's being worked on a lot with Distillery, but from what I understand there's still a lot of kinks to be worked out.

I personally think the deployment story heavily conflicts with container management. I’m going to give edeliver on real hardware a go at some point and things should work very well and be very simple.

Only if you want Erlang clustering or hot upgrades. In the usual army-of-one deployment scenario, Elixir and Erlang work inside a container just fine.

Sorry I wasn't clear; what I'm saying is using the default deployment story with Erlang/Elixir is actually simpler than Kubernetes in most cases.

The article mentions: Root of all evil is state. No its not, but again we love to make generalised sweeping statements (i.e small statement that can be quoted and people think of them some kind of wisdom) The problem is that "mutable shared state" is hard to manage and can lead to various kinds of problems. There are many tested patterns/libraries around that you can use to manage it rather than trying to implement your own solution.

> Root of all evil is state.

That's such a funny thing to say. You'd be hard pressed to have a program without state. Every program is made up of a combination of 3? components: logic, data(state), and time.

The thing that differentiates different programming languages and tools is what abstractions they build around those three things and how they are exposed to the programmer.

I think that there is no better alternative to Rails to write the back-end for web/mobile applications in a very efficient and maintainable way, unless you have very demanding (and uncommon) requirements for performance and "web scale".

I also think that the most important part which is missing to make it even more relevant is a much easier (opinionated, convention-over-configuration and DRY) way to connect rails with React and similar frameworks. Something like generators to synchronise your data with a state manager in the front end (eg Redux). I even have some ideas about this, I just wished I had time to work on it.

Optimizing for happiness is very good advice for beginners. The failure mode for beginners is to get overwhelmed, discouraged, and then give up. So it makes sense to pay more attention to how happy a particular programming environment makes you, and worry less about how marketable it is.

The short version:

> Yes. But I have a crush on Elixir.

The article doesn't say much else.

Yes, I gave up 1/4 of the way in because the author was waffling.

It will be relevant until somebody does a monolithic Web application framework that is better in a way that it so compelling that it's obvious. A microservices architecture is not always the right choice.

Django, Laravel and other established frameworks can be a bit better or a bit worse, depending on your criteria.

Buffalo (Go) and Phoenix (Elixir) are the only competitors that I know of that could match Rails at it's own game, and also have compelling advantages over it. Both have smaller ecosystems right now.

(Source: I've been working at a Rails shop for 6 years).

The need for a build environment itself limits Ruby deployment to developers. This becomes a real problem for end user apps and expecting end users to compile is perhaps expecting too much. And now you need a build environment in deployment.

And with this comes potential dependency hell, an app like Discourse pulls in over 140 dependencies. This means either you are a Ruby developer who can debug compile or version conflict issues quickly or have a lot of time to go down various rabbit holes.

Many casually suggest Docker but this simply doubles complexity as now not only does the end user need to know Ruby but also Docker. This means understanding networking, port forwarding, volumes, state separation and single process environments just for starters before we even get to the app.

For in house apps none of these are deal breakers but one wishes language developers thought more seriously about the deployment story.

Docker is the answer. Hire a separate production engineer to handle docker if your devs are not interested in ops.

A tremendous amount of apps still go the Heroku deployment route, where deployment is a git push.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact