[andycroll]

I can definitely accept that Rails is now somewhat old hat.

And agreed that the Rails 2 to 3 jump was (and still is for many codebases) a tricky and difficult path.

However, I'd argue that doing your 'startup' in [Rails/COBOL/PHP/Logo/Java] is probably a decent idea if you have good engineers who can build something stable relatively quickly. Technology is _rarely_ the problem in any given startup.

If scalability and speed is a problem, congratulations, you're a success.

Rails is still good at giving you the tools to build decent CRUD-ish apps pretty fast and deployment is thankfully a solved problem.

Rails is not the new hotness, but it's still great at getting prototypes out the door and can scale you a long way. I think I'm cool with that.

> our front end has gone from Prototype to jQuery to Coffeescript to Angular to React with major productivity improvements each time

Also rewriting your front-end four times doesn't seem that productive.

[kylnew]

> If scalability and speed is a problem, congratulations, you're a success.

I can not emphasize this enough. A lot of solutions are absolutely good enough for a startup's needs. You obviously don't want something completely throw away, but too much concern over tools & performance is kind of like a premature optimization for your whole business.

[mooreds]

Right. Just finding something that you can build on (and get started yesterday) with the team you have. Of course, it doesn't hurt to pick from one of the top 10 languages so that, if you do succeed, you have a talent pool to pull from.

But this is definitely a case of the perfect being the enemy of the good.

[mattdeboard]

> rewriting your front-end four times doesn't seem that productive

So very, very true. You could keep a front-end developer employed for years just rewriting the same application in the latest JS tech.

[bpicolo]

At the current rate, none of your rewrites finish

[ken47]

I know static vs. dynamic typing was not covered in the article, but all things equal, it should be easier to onboard new devs into a statically typed codebase.

[robmccoll]

I run into this constantly. Static typing is great. If it compiles, I've already avoided half the runtime problems that typically plague big Python code bases.

[borkabrak]

Could you elaborate on what you mean?

I'm not arguing; just curious.

[ken47]

New devs do not have a cache of the codebase in their mind, therefore their mental compiler (because that's what you're utilizing any time you code in a dynamic language) is more prone to make mistakes than devs who know what parts of the codebase to "compile" when they make modifications.

Some may argue that tests can theoretically cover all these bases. I would counter that in practice, tests almost never come close to serving as a poor man's compiler.

And of course, not even a dev who is experienced with the codebase could replace a true compiler, but I'd assume that this is deliberate trade-off, if there were competent technical decision-makers involved

[prewett]

I worked on a reasonably large Python codebase once, and it was definitely more frustrating than a statically typed language. I'd see that function takes an argument named "session". Great, what can I do with that? So I'd have to do `print dir(session)`, run it, and figure out how to hit that function, and then look up the documentation for that class. It's so much easier when the function actually tells you what it is expecting.

I'd also have plenty of times that I referenced a variable and forgot to create the assignment. In a static language I'd get a compile error, but in Python I'd get everything all set up to test and then get a run-time error indicating I did something stupid. Never ceased to frustrate me.

[technion]

Erlang really helps you understand these, because it's dynamically typed, but the dialyzer will produce errors as a form of static optional typing.

I wrote some code a few days ago that looked like it worked. A few days later I ran the dialyzer, and it pointed out a certain code path could never be reached, because there was a comparison of an atom to an integer.

I would never have recognised that bug otherwise, because even my unit test just called that function with an integer, instead of the atom it was being called with.

Dynamic typing runs deep in what PHP/Ruby/Python offer - build it and get it running fast. Not thinking about complex types is a good thing in small projects.

But at a codebase of a certain size, static typing really helps minimise subtle bugs.