Interesting heuristic to improve code structure. I definitely recommend. As every heuristic it's not a law though, don't overdo it either.
The right nuanced way to see the DRY principle. As usual don't overdo it that's where problems will arise.
Good list of advices for someone who just got started programming. Who knows, it might come in handy later.
Definitely a good advice. We're just better at understanding positive boolean expressions.
Play is definitely needed for growth. It's true for kids, it's still true for so called grown ups.
Definitely a good principle to follow when designing APIs. Otherwise you make them less obvious and more dangerous to use.
Yes, definitely this. Plenty of reasons why it's important.
It's one of the two hardest problems of programming after all. Needs to be thought through.
A few good things went unnoticed. The performances are still not there.
List of strategies to keep in mind when debugging.
Since we often still see in the wild code with deep nesting due to edge cases handling, it looks like this advice is still very relevant.
This is definitely a big release! Lots of changes and improvements in this language.
A bit of a rambling, there's something interesting in it though. Splitting small functions early will do more harm than good if they're not reused. Don't assume they automatically make things easier to read.
Good list of things to keep in mind when thinking about performances. Of course, always measure using a profiler when you want to be really sure.
The claim is huge. The story doesn't quite say how much is really about Elixir and how much from the revised architecture. That being said, going for something like Elixir has definitely an impact on the architecture... could it be that it pushes for better patterns?
Nice overview of the good uses and wrong uses for classes. We're far from the abuses of the early times now.
Another partial quote which led to misunderstanding. One should indeed think about performances early on.
This is clearly getting more mature. Even the list of issues presented here actually makes me want to try it more as to evaluate the exact impacts.
To take with a pinch of salt, it conflates a few things in my opinion. Still it's a good reminder that eliminating complexity shouldn't be a goal. Managing said complexity and avoiding the undue one, this is what matters.
Very good points. Picking a particular language is likely not the right approach. Trying to apply the main principles of functional programming on the other hand is more likely to bear fruits.