141–150 of 166 posts
Earlier quoted context omitted.
All 3 of those lamentations could also apply to Clojure, but I don't think anyone who used Clojure would lament it.
Yes they would. The rumblings of clojure and the dynamic language trap are already out there.
Some disappointments about core.typed not being what some would have liked, but other than that...
Earlier quoted context omitted.
This comment is what I feel like replying with to every article about some "fast iterating" language. IMO the only reason to use rails if you don't actually understand how web development actually works. Why would you pick a slower language and platform like ruby/rails when java/spring is right there available to anyone?
And Grails is very similar to Rails, and you get the full power of the JVM/Spring technology stack. And Groovy is a fantastic language that gives you the flexibility everyone like to dream about.
If Groovy and Grails are technology "to dream about", one wonders then why VMware (the Spring backers) retrenched their 6 developers working on Grails and (what is now Apache) Groovy early last year, and why Sun Microsystems (the JVM backers before Oracle) wanted nothing to do with Groovy in its day (despite supporting the JRuby and Jython developers).
Earlier quoted context omitted.
And Grails is very similar to Rails, and you get the full power of the JVM/Spring technology stack. And Groovy is a fantastic language that gives you the flexibility everyone like to dream about.
Groovy is amazing. It's like javascript and Java had a beautiful baby that lets you compile either dynamically or statically.
Earlier quoted context omitted.
With Rails 5 just coming out now does it make sense to just start learning there. Is the material like the "Ruby on Rails Tutorial" book that uses 4.2 still worth reading or is it a large change, something like the python 2.7 to 3 where tutorials and reference material are largely dependent on the software version you use.
There will be some major changes, but not as drastic as the Python version upgrade. I'd think the 4.2 book will be totally fine, and when 5 is out, just look at the changelog and start adding what you need from it.
If I was learning, I'd build an app with the current stable version of 4, a toy crud app with 100% test coverage, then try to convert that to 5. Then compare that to building 5.0 using it's generators. You are likely to work with legacy code, so learning 4 is not bad. May well do that myself, so I'm catching gotchas like the integration test changes in my toy and not at work on a deadline.
But yeah, coding, at least for me, is all about trade offs, and as long as you understand the rails trade offs and mitigations, you are fine.
Earlier quoted context omitted.
Ruby gems in particular host a lot of abandonware and basically little turds that entice "I read pragprog, watch screencasts, and am now leet Rails dev!" Folks into using them with the promise of easy Lego style coding. It never ends well.
Do you have a scat fetish? What is it with you and turds? People get hyped about any language the same way. How many Erlang "experts" or Node.js "ninjas" are there out there? Give it a rest. If people want to get excited about something don't shit all over them.
Right about now is when you should go ahead and read his username, ideally out loud in your best Sean Connery voice.
Earlier quoted context omitted.
How about writing tests that enforce invariants? I have been doing clojure dev for a little bit, and here's what I do - - Run tests in the background continuously (lein expectations will give you that. or you can write your own shell script) - Do small checkins, frequently to git - Write tests that enforce invariants. Haven't gotten to test check yet - but I guess that would be even better. The trouble with types is…
I've honestly never felt like types have gotten in the way. I also write plenty of tests with plenty of mocking, it's just that the type system means we don't have to write tests for the things the type checker checks for. I'm having trouble thinking of a time when I felt something akin to what you describe with zombie constraints. If anything, having a good type system makes it easier to rip out code that isn't used…
But I'm still pro-types, and think they solve way more problems than they cause.
Earlier quoted context omitted.
Getting to market quickly is often more important than contemplating about handling Twitter like traffic. Also, I haven't heard of an application that never had to be rewritten partially/optimised after X years in production. Some problems just don't present themselves in the first couple of years.
Your statement is too cautious. At the start of a project, getting to market quickly is VIRTUALLY ALWAYS more important than handling Twitter-scale traffic. People are simultaneously confident their idea will be popular and afraid of failure, so we have a strong tendency to over-engineer for scale. If it does scale, don't be surprised if you have to toss out your v1 and rebuild. The difference between a good framewor…
So the important questions are:
1. Does Rails performance degrade gracefully under load?
2. Can you gradually shift away from a quick-and-dirty Rails-based implementation to something more scalable without the dreaded "rewrite-while-hair-on-fire" scenario?
In my experience, the answer to both of these is 'no'.
(But these challenges are hardly unique to Rails.)
From Stroustrup of C++ fame: There are only two kinds of languages [frameworks]: the ones people complain about and the ones nobody uses.
Earlier quoted context omitted.
Groovy is amazing. It's like javascript and Java had a beautiful baby that lets you compile either dynamically or statically.
The static compilation doesn't quite work properly. Groovy is good for scripting though, similar to the way Bash is used in Linux, so test your Java classes with it, or use it as a DSL in Gradle builds. For building systems on the JVM, use a language designed for that purpose from the ground up, e.g. Java, Scala, or Kotlin.