I would not recommend Grails at all. First, if for no other reason, it's a bit player, so good luck finding developers, tools, help, and all of the other benefits you get with using a language/framework with a large, thriving community. That alone should be enough to steer you away from using it for enterprise anything.

Aside from that, boolean truths are quirky, to put it kindly.

Null evaluates to false, which is ridiculous and doesn't eliminate the need to check for null, just hides the problem if you forget to do it. This is because groovy uses "null objects." Null objects mean yay! no null pointer exceptions, but the consequence is... no null pointer exceptions! So have fun tracking down bugs when things fail silently.

Variables defined in closures (which is most of them) are opaque, so you can't easily inspect them without printing them out or logging them. So now you have no NPEs and no easy way to check for null values versus empty values while debugging without adding debugging code into production code. Ugh! Don't forget to annotate the debug code so you can remove it when you're done.

You don't get compile-time errors for things like using undefined classes/methods (typos!) or sending the wrong argument types. Instead, you have to compile, run, and look at massive stack traces throwing up all over your console/log: http://pastie.org/583115 Then rinse and repeat until it actually runs. And that's before you even start testing actual functionality.

Method entry and class loading breakpoints aren't supported. (This is simply an inconvenience most of the time, but it's worth noting IMO.)

Conversely, since groovy uses convention over configuration, IDEs may flag things as errors which are not. IntelliJ IDEA probably does the best at handling Groovy/Grails, but it still has some issues. My experience was that Intellisense/autocomplete didn't work reliably for Groovy in any IDE, so if that's important to you, you may miss that.

It's not clear where business logic should go. http://bartling.blogspot.com/2...

It's buggy. https://jira.grails.org/browse...

To be fair, I'm heavily biased against dependency injection, dynamic typing, and coding by convention, which are the very concepts Grails is built around. I could go into all of the reasons, but any flamewar worth its salt will list them all for you.

It's Italy. Which makes sense, since the Mediterranean and near-east are known for flatbread, even if some of the toppings we put on it today originated in the US (like pineapple).

Also the word "soccer" was coined in the UK, not the US. We just like to take credit for everything, apparently.

Here's the thing about gov't software conspiracies: they use the same software! There is no "special" government version of WIndows or OpenSSL. It's all COTS. If the NSA was exploiting vulnerabilities that left themselves and other agencies exposed, then that's extremely irresponsible, but just foolish as well. I'm not saying it's never happened, but it's not a sustainable policy.

We're sorry, the fingers you have used to dial... are too fat. To obtain a special dialing wand, please mash the keypad with your palm... now.

I think "closed" source is a misnomer in regards to the issue of code review. The source is always open to *someone*; it's just a question of who, and whether those people are competent. Effectively, it doesn't matter how many people look at it, as long as the people looking at it know what they're looking at/for. Certainly it can be argued that the set of "all people" includes more experts than the set of "some people," but in practice the subset of "all people" who actually do code reviews appears to be very, very small -- possibly smaller than the set of people who review closed source code. The advantages of OSS are many, but on this point, at best, I think it's a wash, and certainly not a clear and convincing argument for open-source software.

I once wrote Ruby in a Burger King bathroom.

Whatever source compatibility existed before Swift (and the degree to which that exists is surely debatable), it was not removed by Swift. Objective-C, C/C++, and Swift can coexist in the same project. I believe they can even coexist inline, which makes me shudder to think, but there it is. Still, you could ostensibly have a UI in Swift and your core business logic in C, if your architecture is solid. (Obviously YMMV, and there are bugs to be discovered, to be sure.)

It's on the internet, so it must be true!

Here's the rest of the story of "clear shipping bags." http://www.justice.gov/opa/pr/...

Unser was charged with a misdemeanor and fined $75, so... not a felony. Oh, the humanity!
https://en.wikipedia.org/wiki/...

"Honest Services" -- Oops, no example of "honest services" fraud. But it could happen! But it hasn't. (Note: I agree that we should be vigilant against potential abuses, but let's concern ourselves more with real abuses.)

Espionage Act -- Another "didn't happen."

Obstruction of Justice -- the lawyer admitted to a lapse in judgment by helping the church cover up the crime. http://www.nytimes.com/2007/12...

Computer Fraud and Abuse Act -- DID happen. My sympathies are with Bret McDanel. Notably, however, the Justice Department admitted error, his conviction was overturned, and a precedent has been set against future misapplication of the law.

Wire Fraud -- Misattribution. Lori Drew was prosecuted under the Computer Fraud and Abuse Act, though the conviction was overturned in this case as well. I think we all agree that the woman was knowingly malicious, however, and she did not "accidentally" commit a felony. It was important that the law not be used outside of the scope of its intended use though, which is why I'm glad the EFF filed an amicus brief in support of the defendant, even though what she did was horrible.

Providing Material Support for Terrorism -- Another "no example," of misapplication, but one to watch out for. Though I think we all understand how laws are created and tested at this point.

Making a False Statement to a Federal Official -- Terrible example. This guy was clearly trying to skirt the law and provide material support to militant jihadists. http://www.telegram.com/articl...

No. Charges are not authoritative. If they were, we wouldn't have trials.

That depends how you define "public interest."

The two variables in this case are "public safety" and "government transparency," and the one you value more largely determines how you view the issue.

I'm a proponent of self-driving cars, at least in theory, but I'll be damned if I'm going to voluntarily buy something that looks like a super-sized version of the car my three year-old plays with. Can we get someone from Tesla to work with Google on styling, please? Thanks.

Nice false dichotomy you've got there.

Safer I don't (much) care about. Driving is pretty safe already; certainly safer than daily life in virtually any other era in history. The win for me will be shorter commute times -- higher speed limits and less congestion as automated systems make consistent, logical, and coordinated decisions. No hypermilers who don't get up to speed before merging on a freeway, or overly timid drivers who brake on the entrance ramp and wait for traffic to slow down to accommodate them. No competition for access to a lane. No vehicles driving slower in the passing lane (and likely very little passing in any case). Eventually we'll all be shaking our collective fists not at "bad drivers," but at non-automated vehicles in general. Sorry, people who love to drive. (And I'm one of them.)

I suspect there's a good chance that personally owned vehicles will go the same way. If it becomes cheap enough, it will make more sense to hire an automated car as-needed rather than purchasing one. That cost savings is already a reality with taxis in many cities, so it's really just a matter of expanding that to suburbs and exurbs. And that becomes a very real possibility when taxi companies don't have to pay a driver.