9 ms·

The regular thread of people piling in to criticise dynamic languages. Instead perhaps people could suggest a better language/framework that is more productiv

The regular thread of people piling in to criticise dynamic languages. Instead perhaps people could suggest a better language/framework that is more productive than Rails, and has had a long lifespan in a large codebase?

drb91 8y ago
> Instead perhaps people could suggest a better language/framework that is more productive than Rails, and has had a long lifespan in a large codebase? I’d suggest most frameworks are better than rails for long lifespans. They just frontloaded productivity, and it shows. The UI and functionality of github is largely the same as in 2010.
- bitexploder 8y ago
  GitLab is mostly rails and they have been iterating their UI pretty heavily. I think programming languages are just tools and the team(s) wielding them matter a lot more than the language.
- vvillena 8y ago
  Meanwhile, they were able to win market rate so fast that it took a while for competitors to show up.
- int_19h 8y ago
  On the UI, I'm kinda feeling like it's not a bad thing. GitHub UI works. It's neat, most things that need to be done often are easy to find, and otherwise it gets out of my way nicely. Oh, and it doesn't break my browser (links, Back button etc). Why change it?
  - drb91 8y ago
    Well, their PR software could use some serious love. I don’t use github for much else.
  - 51 8y ago
    Bitbucket and Jira use React and are far less usable
- maxerickson 8y ago
  Are you sure you remember how everything worked in 2010? And then stuff that was sensible then probably shouldn't have changed much.
BjoernKW 8y ago
Although arguably not as productive Java fares pretty well in that regard, particularly when it comes to maintainability. Still, Rails is terrific. If it wasn’t for Rails Java today wouldn’t be as productive either.
- alexhutcheson 8y ago
  Yeah Java isn't nearly as bad as it used to be, and it's pretty seamless to write your business logic in Kotlin if Java's verbosity annoys you.
  - AlphaSite 8y ago
    Honestly Java is getting better at a good pace now. It’s nowhere near as bad as the java 6 days.
radium3d 8y ago
I was surprised to learn that github runs on ruby on rails. Interesting, I didn't know Ruby has been around just as long as PHP. I still would choose PHP if my opinion matters, just from my experience with the slow performance of ruby on rails when I gave it a go just a few years back. PHP - 23 years Ruby - 23 years Java - 23 years JavaScript (nodejs) - 22 years (9 years) https://en.wikipedia.org/wiki/Dynamic_programming_language#Examples https://en.wikipedia.org/wiki/Dynamic_programming_language#E...
- bal00ns 8y ago
  Don't forget Python - 28 years
  - zimbatm 8y ago
    And finally, Perl - 30 years
    - kbenson 8y ago
      Thanks. I was going to be a little depressed if after all that someone didn't jump in with Perl. :) That said, it's frightfully close to 31 years... [1] 1: https://perldoc.perl.org/perlhist.html https://perldoc.perl.org/perlhist.html
      - JohnL4 8y ago
        $_&-++()/+&_$@%%":;!!?)(-_# or die
- j45 8y ago
  Many of these languages, while productive in their own ways, almost universally need a framework to extend to the web. The few languages were web-first were often chastised for not being complete languages.
  - jacob019 8y ago
    Not sure what you mean. A basic HTTP webserver can be implemented in a couple dozen lines of code using only sockets in most languages. Something more complex requires more code, which is often packed into a "framework", it doesn't belong baked into the language.
foolfoolz 8y ago
“more productive” is such an impossible argument. This idea that you need to use a dynamic language to achieve fast iteration makes no sense. I’ve been building sites in scala for years and it’s more than quick enough. Scalatra/Akka HTTP for web, slick for DB, lift/play/jackson/circe for json
- vvillena 8y ago
  In the other side, I've done both things (webdev with Scala/Play/Circe/Akka, webdev with Rails) and the Rails stack was so fast to develop with that we could leave just one person to do that job, while the rest kept developing our core logic in Scala. IMHO there isn't much to gain with static languages when doing web development. A good framework is much more important. Static languages are awesome when coding business rules, though.
  - TheDong 8y ago
    Static types and languages help a lot when you have more than one person working on things honestly. One person can keep a rough mental model of how the project fits together in their head, which lets them have good intuition about contracts between different subsystems. When you have 5 developers on one project, that intuition quickly breaks due to developers mental models being slightly different. That's where having a type-system really helps. I'd argue that the you lucked out in that the stack was able to be developed by one person, and that's what enabled it to be dynamically typed with relatively little loss. It's once you have 3+ coders working on the same code-base that static types really start helping.
    - koolba 8y ago
      > Static types and languages help a lot when you have more than one person working on things honestly. I consider myself working alone to be more than one person when I come back to something I haven’t touched in months. For all practical purposes, I feel like I’m reading someone else’s code. A statically typed language makes it much easier to make changes in that situation without worrying about unforeseen breakages.
quickthrower2 8y ago
Not critisizing RoR, it is the grandmother of all of the web frameworks we enjoy in practically every mainstream language. Also it is dynamically typed. I do prefer static types on the code I write because I am less likely to make mistakes and I like to have a more explicit 'contract' in place between code boundaries. However I am open minded to why people prefer dynamic types and I imagine it is all to do with speed of initial development akin to "Move fast and break things" and "MVP". That said Microsoft's ASP.NET MVC would be a good contender for your call to suggest a better language.framework. It is indeed very productive. It has a massive package ecosystem, great documentation, a very long lifespan (not as old as Rails, but probably about 10 years old now). ASP.NET MVC is all over the enterprise so it is well proven, plus StackOverflow if you want a high traffic example - there are probably many more. Where I think it beats Ruby in particular is the C# language is really excellent. C# is my favourite language for getting things done and I've tried Ruby, Java, Python, Haskell, Basic and Javascript and gone into some depth with all of those. The reason is the excellent language features, one of the first to have async/await, good generics system, Linq is awesome, there is even some dynamic types support if you need it - which is nice for web page stuff while you are experimenting and then can 'shore it up' with a class later on. The downside of C# I think but I need someone else to confirm is it is probably a bit confusing for a newbie, because of the vast number of features and many ways of doing things because of it's history. Not so bad if you have been doing it for years. Another downside with ASP.NET is different ways of doing things in .NET Core so lots of relearning to do and tutorial roulette where if the tutorial is using .NET Core you may not find it easy to integrate into your classic application. Although I think RoR would suffer such upgrade issues I am sure.
- da02 8y ago
  Do you run ASP.NET on Windows? Or on a Linux distro?
  - Salgat 8y ago
    At my company we use ASP.NET on both Windows and Linux boxes; it depends on what our dependencies are (some of our older libraries are unfortunately windows only).
Carpetsmoker 8y ago
I've been using a lot of Go to write web applications the last three years, and I find it's a very smooth experience. I don't have a hate-on for Ruby on Rails; my last job was as a Rails dev and I liked it. I still like, even though I haven't used it in a while (simply because I have no need). It also definitely has some advantages over Go. But Go offers some great advantages: type safety; still fairly productive; boring understandable Just Works™-kind of language, and has most required components in stdlib (you need a few external dependencies, but not many, although how many depends a bit on your approach as well). The biggest downside is that there's no standard web framework, and that a lot of Go devs seem to eschew them, too. There are some good reasons for that in some contexts (RoR is not a solution for everything either, that's why Sinatra exists), but it has the effect that a lot of organisations crank out their own internal semi-frameworks. Basically it's Greenspun's tenth rule. Go-buffalo is probably the closest thing to Go, but I haven't had the opportunity to check it out in depth yet. There is also Revel, but that has some unfortunate design decisions IMHO, and isn't something I would recommend. Is Go a complete drop-in replacement for all RoR use cases? No; not yet anyway. But I think it is for a lot of cases.
- fouc 8y ago
  How's testing in go? What about unit tests when you want to hit the database, do you wrap that in transactions?
  - algorithmmonkey 8y ago
    Check out https://gobuffalo.io/en/docs/testing/ https://gobuffalo.io/en/docs/testing/ Coming from a rails background, this was the closest out of the box testing experience. Tests are generally handled within a transaction and also offer fixtures and other goodies. Definitely recommend giving it a test drive.
  - sfifs 8y ago
    Not quite sure what you are looking for but Go was one of the first languages about 7-8 years ago that had unit testing, benchmarking and code coverage built into the standard library and tooling. The unique implementation of automatically satisfied Interfaces and first class functions (ie. easy to inject dependency) in particular makes testing very easy and designing code using these abstractions for testability also improves modularity. For database, generally you just use the standard library to access and well tested database drivers provide the actual access mechanics. So if you want you can actually decouple tests checking the business logic side of database (eg. instantiate and hit an in-memory dB locally during testing - or even use a completely different driver if you're not using a weird "flavor" of SQL) from actual connectivity testing (where you wrap things into a transaction in a real mirror dB)
pbreit 8y ago
There doesn't seem to be much demand for backwards compatibility from a framework. I use Web2py [1] which has remained backwards compatible for 10 years or so but I don't think has garnered much traction amongst high profile projects. It does require a bit of discretion and restraint but is doable while continuing to make progress. 1: http://www.web2py.com http://www.web2py.com
- pmontra 8y ago
  I had a customer with a web2py application. I liked that I could write Python in the HTML files, like Ruby in RoR views. Django castrated templating language is a pain in comparison and a productivity killer. There are some good form helpers, especially for admin applications. Maybe not that useful for public facing ones. The defaults are quite terrible. For example the original developer put everything in the default.py file because there is nothing in the framework that suggests to create multiple controllers or models. The idea of auto generating and auto applying migrations is extremely dangerous IMHO. The ORM is pretty verbose and it pollutes the code with all those db(). On the other side, Django pollutes the code with all those Model.objects so it's not worse than that.
sam0x17 8y ago
Or you could use crystal with amber or lucky framework and get the best of both worlds (C-like speed, typed, compiled, but with many dynamic language features faked with macros, and ruby-like syntax and conventions).
- djur 8y ago
  But also with the standard problems of a new language, a small ecosystem and immature tooling.
  - sam0x17 8y ago
    Those problems can also be a blessing. In the Rails ecosystem you end up with hundreds of gem dependencies that you probably don't need. In NPM, it's 100x worse. That is why, imo, many people cry foul when an ecosystem gets too mature (without realizing that that is why). There can be too few, but also too many packages.
pka 8y ago
> that is more productive than Rails So, spending a year and a half on a major version upgrade of your web framework is "productive" how exactly? I mean, whatever time you think you've saved by using Rails during the initial prototyping phase (and I don't think even that's true), you'll more than pay for in maintenance costs.
- jimnotgym 8y ago
  1) I think Github are a long way past prototyping... they just sold their rough sketch for $7.5b 2) A year and a half of how much effort?
  - pka 8y ago
    > A year and a half of how much effort? > The project originally began with 1 full-time engineer and a small army of volunteers. We grew that team to 4 full-time engineers plus the volunteers. They had four full-time people working on upgrading Rails at some point!
- hnzix 8y ago
  So. What is your suggested alternative stack for rapid MVP prototyping? Personally I'm fascinated with Clojure but it doesn't yet have the ecosystem (for me as a Clojure noob) to easily punch out product prototypes. Likewise I've messed with JS frameworks and they're fun but they don't offer me proven established patterns; too many competing and fast-moving choices. I'd rather find my market fit first then worry about scaling / paying off tech debt. Again, what's your suggested model? To me Rails offers a semi-boring yet productive middleground between high and low ceremony. TAANSTAFL.
  - pka 8y ago
    If you're talking about CRUD boilerplate apps, literally any modern web framework in a static language. Again, even if "rapid prototyping" was a thing in Rails (i.e. rapid as opposed to what?) you start paying back the price tenfold once your project becomes moderately complex, test coverage or not. So if your question is specifically "What's a good stack for a blog I'll never touch again or maintain with X and Y integration, tomorrow", then ok, cool, Rails.

drb91 8y ago

> Instead perhaps people could suggest a better language/framework that is more productive than Rails, and has had a long lifespan in a large codebase? I’d suggest most frameworks are better than rails for long lifespans. They just frontloaded productivity, and it shows. The UI and functionality of github is largely the same as in 2010.

bitexploder 8y ago
GitLab is mostly rails and they have been iterating their UI pretty heavily. I think programming languages are just tools and the team(s) wielding them matter a lot more than the language.
vvillena 8y ago
Meanwhile, they were able to win market rate so fast that it took a while for competitors to show up.
int_19h 8y ago
On the UI, I'm kinda feeling like it's not a bad thing. GitHub UI works. It's neat, most things that need to be done often are easy to find, and otherwise it gets out of my way nicely. Oh, and it doesn't break my browser (links, Back button etc). Why change it?
- drb91 8y ago
  Well, their PR software could use some serious love. I don’t use github for much else.
- 51 8y ago
  Bitbucket and Jira use React and are far less usable
maxerickson 8y ago
Are you sure you remember how everything worked in 2010? And then stuff that was sensible then probably shouldn't have changed much.

BjoernKW 8y ago

Although arguably not as productive Java fares pretty well in that regard, particularly when it comes to maintainability. Still, Rails is terrific. If it wasn’t for Rails Java today wouldn’t be as productive either.

alexhutcheson 8y ago
Yeah Java isn't nearly as bad as it used to be, and it's pretty seamless to write your business logic in Kotlin if Java's verbosity annoys you.
- AlphaSite 8y ago
  Honestly Java is getting better at a good pace now. It’s nowhere near as bad as the java 6 days.

radium3d 8y ago

I was surprised to learn that github runs on ruby on rails. Interesting, I didn't know Ruby has been around just as long as PHP. I still would choose PHP if my opinion matters, just from my experience with the slow performance of ruby on rails when I gave it a go just a few years back. PHP - 23 years Ruby - 23 years Java - 23 years JavaScript (nodejs) - 22 years (9 years) https://en.wikipedia.org/wiki/Dynamic_programming_language#Examples https://en.wikipedia.org/wiki/Dynamic_programming_language#E...

bal00ns 8y ago
Don't forget Python - 28 years
- zimbatm 8y ago
  And finally, Perl - 30 years
  - kbenson 8y ago
    Thanks. I was going to be a little depressed if after all that someone didn't jump in with Perl. :) That said, it's frightfully close to 31 years... [1] 1: https://perldoc.perl.org/perlhist.html https://perldoc.perl.org/perlhist.html
    - JohnL4 8y ago
      $_&-++()/+&_$@%%":;!!?)(-_# or die
j45 8y ago
Many of these languages, while productive in their own ways, almost universally need a framework to extend to the web. The few languages were web-first were often chastised for not being complete languages.
- jacob019 8y ago
  Not sure what you mean. A basic HTTP webserver can be implemented in a couple dozen lines of code using only sockets in most languages. Something more complex requires more code, which is often packed into a "framework", it doesn't belong baked into the language.

foolfoolz 8y ago

“more productive” is such an impossible argument. This idea that you need to use a dynamic language to achieve fast iteration makes no sense. I’ve been building sites in scala for years and it’s more than quick enough. Scalatra/Akka HTTP for web, slick for DB, lift/play/jackson/circe for json

vvillena 8y ago
In the other side, I've done both things (webdev with Scala/Play/Circe/Akka, webdev with Rails) and the Rails stack was so fast to develop with that we could leave just one person to do that job, while the rest kept developing our core logic in Scala. IMHO there isn't much to gain with static languages when doing web development. A good framework is much more important. Static languages are awesome when coding business rules, though.
- TheDong 8y ago
  Static types and languages help a lot when you have more than one person working on things honestly. One person can keep a rough mental model of how the project fits together in their head, which lets them have good intuition about contracts between different subsystems. When you have 5 developers on one project, that intuition quickly breaks due to developers mental models being slightly different. That's where having a type-system really helps. I'd argue that the you lucked out in that the stack was able to be developed by one person, and that's what enabled it to be dynamically typed with relatively little loss. It's once you have 3+ coders working on the same code-base that static types really start helping.
  - koolba 8y ago
    > Static types and languages help a lot when you have more than one person working on things honestly. I consider myself working alone to be more than one person when I come back to something I haven’t touched in months. For all practical purposes, I feel like I’m reading someone else’s code. A statically typed language makes it much easier to make changes in that situation without worrying about unforeseen breakages.

quickthrower2 8y ago

Not critisizing RoR, it is the grandmother of all of the web frameworks we enjoy in practically every mainstream language. Also it is dynamically typed. I do prefer static types on the code I write because I am less likely to make mistakes and I like to have a more explicit 'contract' in place between code boundaries. However I am open minded to why people prefer dynamic types and I imagine it is all to do with speed of initial development akin to "Move fast and break things" and "MVP". That said Microsoft's ASP.NET MVC would be a good contender for your call to suggest a better language.framework. It is indeed very productive. It has a massive package ecosystem, great documentation, a very long lifespan (not as old as Rails, but probably about 10 years old now). ASP.NET MVC is all over the enterprise so it is well proven, plus StackOverflow if you want a high traffic example - there are probably many more. Where I think it beats Ruby in particular is the C# language is really excellent. C# is my favourite language for getting things done and I've tried Ruby, Java, Python, Haskell, Basic and Javascript and gone into some depth with all of those. The reason is the excellent language features, one of the first to have async/await, good generics system, Linq is awesome, there is even some dynamic types support if you need it - which is nice for web page stuff while you are experimenting and then can 'shore it up' with a class later on. The downside of C# I think but I need someone else to confirm is it is probably a bit confusing for a newbie, because of the vast number of features and many ways of doing things because of it's history. Not so bad if you have been doing it for years. Another downside with ASP.NET is different ways of doing things in .NET Core so lots of relearning to do and tutorial roulette where if the tutorial is using .NET Core you may not find it easy to integrate into your classic application. Although I think RoR would suffer such upgrade issues I am sure.

da02 8y ago
Do you run ASP.NET on Windows? Or on a Linux distro?
- Salgat 8y ago
  At my company we use ASP.NET on both Windows and Linux boxes; it depends on what our dependencies are (some of our older libraries are unfortunately windows only).

Carpetsmoker 8y ago

I've been using a lot of Go to write web applications the last three years, and I find it's a very smooth experience. I don't have a hate-on for Ruby on Rails; my last job was as a Rails dev and I liked it. I still like, even though I haven't used it in a while (simply because I have no need). It also definitely has some advantages over Go. But Go offers some great advantages: type safety; still fairly productive; boring understandable Just Works™-kind of language, and has most required components in stdlib (you need a few external dependencies, but not many, although how many depends a bit on your approach as well). The biggest downside is that there's no standard web framework, and that a lot of Go devs seem to eschew them, too. There are some good reasons for that in some contexts (RoR is not a solution for everything either, that's why Sinatra exists), but it has the effect that a lot of organisations crank out their own internal semi-frameworks. Basically it's Greenspun's tenth rule. Go-buffalo is probably the closest thing to Go, but I haven't had the opportunity to check it out in depth yet. There is also Revel, but that has some unfortunate design decisions IMHO, and isn't something I would recommend. Is Go a complete drop-in replacement for all RoR use cases? No; not yet anyway. But I think it is for a lot of cases.

fouc 8y ago
How's testing in go? What about unit tests when you want to hit the database, do you wrap that in transactions?
- algorithmmonkey 8y ago
  Check out https://gobuffalo.io/en/docs/testing/ https://gobuffalo.io/en/docs/testing/ Coming from a rails background, this was the closest out of the box testing experience. Tests are generally handled within a transaction and also offer fixtures and other goodies. Definitely recommend giving it a test drive.
- sfifs 8y ago
  Not quite sure what you are looking for but Go was one of the first languages about 7-8 years ago that had unit testing, benchmarking and code coverage built into the standard library and tooling. The unique implementation of automatically satisfied Interfaces and first class functions (ie. easy to inject dependency) in particular makes testing very easy and designing code using these abstractions for testability also improves modularity. For database, generally you just use the standard library to access and well tested database drivers provide the actual access mechanics. So if you want you can actually decouple tests checking the business logic side of database (eg. instantiate and hit an in-memory dB locally during testing - or even use a completely different driver if you're not using a weird "flavor" of SQL) from actual connectivity testing (where you wrap things into a transaction in a real mirror dB)

pbreit 8y ago

There doesn't seem to be much demand for backwards compatibility from a framework. I use Web2py [1] which has remained backwards compatible for 10 years or so but I don't think has garnered much traction amongst high profile projects. It does require a bit of discretion and restraint but is doable while continuing to make progress. 1: http://www.web2py.com http://www.web2py.com

pmontra 8y ago
I had a customer with a web2py application. I liked that I could write Python in the HTML files, like Ruby in RoR views. Django castrated templating language is a pain in comparison and a productivity killer. There are some good form helpers, especially for admin applications. Maybe not that useful for public facing ones. The defaults are quite terrible. For example the original developer put everything in the default.py file because there is nothing in the framework that suggests to create multiple controllers or models. The idea of auto generating and auto applying migrations is extremely dangerous IMHO. The ORM is pretty verbose and it pollutes the code with all those db(). On the other side, Django pollutes the code with all those Model.objects so it's not worse than that.

sam0x17 8y ago

Or you could use crystal with amber or lucky framework and get the best of both worlds (C-like speed, typed, compiled, but with many dynamic language features faked with macros, and ruby-like syntax and conventions).

djur 8y ago
But also with the standard problems of a new language, a small ecosystem and immature tooling.
- sam0x17 8y ago
  Those problems can also be a blessing. In the Rails ecosystem you end up with hundreds of gem dependencies that you probably don't need. In NPM, it's 100x worse. That is why, imo, many people cry foul when an ecosystem gets too mature (without realizing that that is why). There can be too few, but also too many packages.

pka 8y ago

> that is more productive than Rails So, spending a year and a half on a major version upgrade of your web framework is "productive" how exactly? I mean, whatever time you think you've saved by using Rails during the initial prototyping phase (and I don't think even that's true), you'll more than pay for in maintenance costs.

jimnotgym 8y ago
1) I think Github are a long way past prototyping... they just sold their rough sketch for $7.5b 2) A year and a half of how much effort?
- pka 8y ago
  > A year and a half of how much effort? > The project originally began with 1 full-time engineer and a small army of volunteers. We grew that team to 4 full-time engineers plus the volunteers. They had four full-time people working on upgrading Rails at some point!
hnzix 8y ago
So. What is your suggested alternative stack for rapid MVP prototyping? Personally I'm fascinated with Clojure but it doesn't yet have the ecosystem (for me as a Clojure noob) to easily punch out product prototypes. Likewise I've messed with JS frameworks and they're fun but they don't offer me proven established patterns; too many competing and fast-moving choices. I'd rather find my market fit first then worry about scaling / paying off tech debt. Again, what's your suggested model? To me Rails offers a semi-boring yet productive middleground between high and low ceremony. TAANSTAFL.
- pka 8y ago
  If you're talking about CRUD boilerplate apps, literally any modern web framework in a static language. Again, even if "rapid prototyping" was a thing in Rails (i.e. rapid as opposed to what?) you start paying back the price tenfold once your project becomes moderately complex, test coverage or not. So if your question is specifically "What's a good stack for a blog I'll never touch again or maintain with X and Y integration, tomorrow", then ok, cool, Rails.