dorinlazar

The author here. The point there is not a critique of Rust. I'll offer a bit of context - I started my „from scratch” utility library with a std::string-like type that operates on reference counted buffers. In the end, any operations I try to do I have to put the sliced string in a zero-terminated string because that's how one interacts with the operating system and with other libraries as well. Which is a bit dumb, unfortunately.

A lot of C (and C++) memory-related issues are caused by this assumption that by just passing a `char *` one sends a string out into the world. A point that I made on other occasions in other contexts is that in the end POSIX makes us do this, and perhaps it's time to rewrite from the bottoms up.

That aside, the issue of safety of Rust doesn't change: just because one has the `unsafe` keyword doesn't mean that someone will not use it badly. Maybe the reader of this will not use unsafe unwisely, they will eventually call unsafe-by-design APIs. At their layer they will write safe code, but below them there's a rusty bucket, if one can pardon my pun.

SCRUM solves a problem the X poster is too young to know. I'm mildly amused, he has no idea what SCRUM is about and why the ceremony is a lot better than the sleepless nights and the crunch time spent rewriting the application in the last month before release.

Pepperidge Farm remembers!

Oh, I so much agree with this!

Like any TDD proponent (and most cultists, really), the author insists that „you're not doing it right”, despite reading the scriptures. You're always misunderstanding, YOU are the reason TDD doesn't work, no, TDD is itself flawless. There's always a slight misinterpretation of the magic words! But TDD works, you're the sinner for not using it right!

And then you have shocked people when they find out that 100% test coverage doesn't mean that you really have a bug-free codebase.

I agree; of course, both clang and gcc extend C++ with __restrict__ if I remember correctly; from what I know, there are more things that can be done in C++ to improve over C than the other way around.

C++ is just a stricter C - if you write proper C, it will be a correct C++ program, therefore it would run at the same speed. There's no way C can be other than marginally faster than C++ - if you write C and compile it with a C++ compiler.

Then you have various optimizations that come from things like templates, constexpr. Look at the qsort method - to have a modicum of genericity you need to pass a function that will be invoked. Instead, a C++ version would be able to be optimized to compare the elements directly, without calling a function, avoiding a big number of function calls.

There's no way to make C faster than well written C++. But C++ is complex and a lot of people write bad C++, that's why it has developed a bad reputation. It's really undeserved.

My thought about this is that patterns are something I recognize in the completed code, not something I bake into my code. A useful tool for refactoring at best. But re-factoring, not factoring. :)

It's not a judgment of GoF per se, although I have some critique on the book as well, but of the impact it had. Unfortunately, a lot of people (mis)took it to heart, and GoF became just another book to learn by rote when interviewing.

Somehow related, Google right now demands interviewees to prepare using the Cracking the Coding Interview book. Pretty much it's like someone sells you a door and hands you a set of lockpicking tools instead of you using the key to enter.

I learned many things from that experience, but later, when I actually got smarter about career and interviews; being introverted didn't help much either. But I'm glad I didn't make this mistake on my end, when I was at the other end of the table; I was able to hire and help grow people who would have been put down because they didn't read a recipes book.

I have a terrible problem with people recommending books that „changed their whatever”. And sometimes I think that it comes from an arrogant place where people being „influenced” by books is a bad place. But I do understand that sometimes books can change the way one thinks about things, and it makes sense to make a list of those.

For me, there are books that had a negative impact on my work. The GoF book is one such book, and its impact on my development is so distructive I can't even begin to explain. It's not only because it tries to codify coding as a sum of recipes, but people reading it end up with the scary idea that there is only one way of doing things, and that one way has a clear name, and a single possibility for implementation. The GoF buffs are those that keep stressing the most autoerotic interview question: „describe me one design pattern, other than Singleton”.

Now worse than people who read the GoF book are people who dove deeper into the issue and learned about more design patterns from other books. One such people screwed my career development for 7 years because at one internal interview he asked me out of nothing about the „half sync half async pattern”, that solves a problem that he wasn't able to describe to me. And since I failed, I was forever on their s*t list.

I think there are good books that can influence your life in a positive manner, but those are incremental changes, things that add a few things here and there. I would expect to see on lists that „changed careers” books on programming languages, like Kernighan & Ritchie on C, or Stroustrup's or Alexandrescu's books on C++. Or books on fundamentals, like Hennessy and Patterson, like Tannenbaum's Network or Operating systems, Knuth, or Cormen&al on Algorithms. But since I rarely do...

That's not for physicists to know, more for mechanical engineers :D

I took a very long break, about one year (but realistically, 6 months, the other 6 months I was busy renovating my apartment). I then eased into work; started with 4 hours a day, and didn't go to full time until I didn't feel ready. But also, I don't plan to work for long full-time. Even 40 hours a week is too much, to be perfectly honest.

Not for mainstream projects - plus those places tend to become political mudwaters, because freedom in tech has become political the past few years.

The Discord chat room is very little different from the (RIP) freenode channel. Sure, you need to create an account, but that's where communities are built nowadays - in closed groups that can be controlled, moderated properly, and automated, while still being a fun and friendly environment to chat in. It does that well.

Github is not open. All the things listed there are costly, in one way or another. There's nothing free about anything that makes up open source today. Open source became corporate some time in the late 00s. And while I don't agree with the author (including the fact that he calls the new product Ruby-powered, not Impaired by Ruby), I do agree with that strange assessment that open source communities work that way.

It's not about the ability to write programs, but the ability to write programs that influence your base system in a meaningful way. Yes, you can write programs, but can you write a different /bin/init for your system? I'm not sure you can (either because Apple will not let you, or your lack of ability to do things like setting up a system to be used). Maybe you can, we're wrong about this, and more power to you. But it's quite likely that you can't.