133 karma · joined January 5, 2013
Ruby is not my favorite language anymore, but I still use it and see evidence that there is a huge place it fills in the dev community and ecosystem. I have never used a more expressive language. I'm stating this as a fact from what I have experienced, and I'm giving points that back it up. There are dozens of actively maintained Ruby projects, some of which are the most popular repos on GitHub. I don't see any evidence that the Ruby ecosystem is on a downward trend of activity and is "dying", so I have no reason to think otherwise.
This kind of stuff reminds me why I take breaks from HackerNews every once in a while -_- Yuck.
I think the name "diet soda" needs to go, as it really is misleading, but (and I could be wrong about this) I don't think these companies have ever claimed their products make you shed pounds by simply drinking them.
But where is the evidence that a calorie-free beverage can have an impact on your metabolism? You're eliminating the idea of calories entirely with diet soda, so I don't see how your argument stands any ground.
Side note: Do any brands really advertise drinking their diet soda as a method of (actual) weight loss? I can't think of any that actually present it this way.
It goes on to say that substituting sugary soda for diet soda isn't enough for most people to stop gaining weight. This is probably because you're likely to substitue the calories and sugars for something else, since your body notices its getting less of something and will crave it.
Yet you have things like this:
"One large study found that people who drank artificially sweetened soda were more likely to experience weight gain than those who drank non-diet soda"
This again is a correlation with the typical behavior of a diet soda drinker. They're not drinking diet soda because they want to lose weight. Rather, they're drinking it because they don't want to gain weight. They could have a terrible diet overall and this alone does nothing but move the problem over into, say, consuming two scoops of ice scream after dinner everyday. All because the soda they had during lunch didn't satisfy their bodily craving of refined sugars.
So this is a case of correlation not being causation. These types of articles do nothing but encourage this error to propagate. Perhaps the term "diet soda" is misleading in itself, but perhaps telling people that drinking a calorie-free drink will make them gain weight is just as silly as telling people it will make them lose weight.
Gotta love the Internets.
Maintaining software is hard.
Blaming your own incompetence on a library or an entire language is easy.
I've been guilty of this at times, but when you get down to it, it's your job as a software developer to understand how your software works and how to maintain it well. This doesn't just include the code you write; it includes your tools, third party libraries, and the internals of the language (VM, compiler, etc.). Its not easy, but it's part of the job.
On a more positive note, versioning packages in Go is already possible and is starting to gain momentum. Check out http://www.gonuts.io/
You've got to be KIDDING ME. They don't seem to give two shits about their users or their money.
All the "my language is better than yours!" bashing is a result of being stubbornly opinionated and not willing to look at things from another perspective. There are always things that one VM will shine with where another will fall flat at, at vice versa.
Also, I don't think Ruby is nearly as bad as most people think. It's not as monolithically slow and vulnerable to exploitation as some people on HN claim. The VM is decent, and there are ways to tune the performance up that make it even "good". See, there's a tradeoff. The language is, IMO, fantastic, but you're going to take a performance hit for that that you need to deal with in some way or another. You're trading execution speed for "developer happiness", whatever that means anymore.
I feel the author's frustration with the spec. I think that the OAuth2 spec could do a better job of outlining best practices and security, but calling it a terrible spec over the potential of poor implementation isn't right IMO.
Also, stealing an access token is far from "Game Over', as the author states. They're short lived and meant to mitigate the damage done by having one or even several leaked. Getting your hands on a Refresh Token would be closer to "Game Over". Although even then, it'd be trivial to have the compromise reported and expire the Refresh Token of that client and subsequently all access tokens.