8 ms·

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

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 11y ago
> 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 11y ago
  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.
ken47 11y ago
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.
- borkabrak 11y ago
  Could you elaborate on what you mean? I'm not arguing; just curious.
  - prewett 11y ago
    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.
  - ken47 11y ago
    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
  - technion 11y ago
    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.
mattdeboard 11y ago
> 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 11y ago
  At the current rate, none of your rewrites finish

kylnew 11y ago

> 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 11y ago
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.

ken47 11y ago

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.

borkabrak 11y ago
Could you elaborate on what you mean? I'm not arguing; just curious.
- prewett 11y ago
  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.
- ken47 11y ago
  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
- technion 11y ago
  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.

mattdeboard 11y ago

> 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 11y ago
At the current rate, none of your rewrites finish