I’m Dutch too, and I used to work 8h/day 4 days a week. And my productivity became even better than when I worked 5 days a week. I could kill it those 4 days, and be rested enough the next week so I could kill it again. It worked wonders.
I like the rhetoric, because it means that my employer got something out of it too. But I don’t think it implies that was the only reason it should be given. I obviously enjoyed the time off for my own reasons.
I can take this one: Because he doesn’t actually care about creating anything of value. If he truly believed in it, you’re right, Twitter or even Tesla’s software engineers would be on the chopping block and he’d replace them with AI as soon as he can. But he doesn’t.
He knows this is a longshot. Most likely to fail, but very profitable on the near-impossible chance that it works. But he doesn’t care even if the odds are truly impossible. Because this is an investment opportunity, so people will throw money his way, no matter what the odds.
People assume he’s an idiot, and he is. But he’s not stupid, at least not in every way. He certainly has a skill for separating others from their money, which he happily takes advantage of.
That’s fair, although technically you could catch SIGSEGV and release resources that way too.
Also, given that resources will be reclaimed by the OS regardless of which kind of crash we’re talking about, the effective difference is usually (but not always) negligible.
Either way, no user would consider a panic!() to be not a crash because destructors ran. And most developers don’t either.
“An abrupt exit”, more commonly known as a “crash”.
If you’re going to argue that an exit through panic!() is not a crash, I will argue that your definition of a crash is just an abrupt exit initiated by the OS. In other words, there’s no meaningful distinction as the result is the same.
I don’t understand why you’re getting downvoted. While I don’t share your conviction, I do admit it’s certainly a possibility.
The advantage of doing things that way is that code becomes much more portable. We may finally reach the goal of “write once, run anywhere”, because the AI may write all the platform specific code.
It does make a big assumption that the AI output is reliable enough though. At times people will want to tweak the output, so how are they gonna go about that? Maybe if the language is based on Markdown, you can inject snippets of code where necessary. But if you have to do that too often, such a language will lose its appeal.
There’s a lot of unknowns, but I see why it’s a tempting idea.
tsc is (very) slow and there are also no convenient ways to interact with it from Rust.
So it saves a lot development and CI time to roll our own. The downside is that our inference still isn’t as good as tsc of course, but we’re hopeful the community can help us get very close at least.
I see this argument repeated here every now and then, but it’s not true: https://aoav.org.uk/2020/the-effects-of-strategic-bombing-in-wwii-on-german-morale/
To summarise: Bombing had a profound effect on depressing morale through inducing defeatism, fear and apathy. Bombing did not harden popular resolve against the US. The hate and anger it aroused was directed against the Nazi regime, not the Allies.
It’s that the compiler doesn’t help you with preventing race conditions. This makes some problems so hard to solve in C that C programmers simply stay away from attempting it, because they fear the complexity involved.
It’s a variation of the same theme: Maybe a C programmer could do it too, given infinite time and skill. But in practice it’s often not feasible.
Which one should I pick then, that is both as fast as the std solutions in the other languages and as reusable for arbitrary use cases?
Because it sounds like your initial pick made you loose the machine efficiency argument and you can’t have it both ways.
I’m not saying you can’t, but it’s a lot more work to use such solutions, to say nothing about their quality compared to std solutions in other languages.
And it’s also just one example. If we bring multi-threading into it, we’re opening another can of worms where C doesn’t particularly shine.
Well, let’s be real: many C programs don’t want to rely on Glib, and licensing (as the other reply mentioned) is only one reason. Glib is not exactly known for high performance, and is significantly slower than the alternatives supported by the other languages I mentioned.
I would argue that because C is so hard to program in, even the claim to machine efficiency is arguable. Yes, if you have infinite time for implementation, then C is among the most efficient, but then the same applies to C++, Rust and Zig too, because with infinite time any artificial hurdle can be cleared by the programmer.
In practice however, programmers have limited time. That means they need to use the tools of the language to save themselves time. Languages with higher levels of abstraction make it easier, not harder, to reach high performance, assuming the abstractions don’t provide too much overhead. C++, Rust and Zig all apply in this domain.
An example is the situation where you need a hash map or B-Tree map to implement efficient lookups. The languages with higher abstraction give you reusable, high performance options. The C programmer will need to either roll his own, which may not be an option if time Is limited, or choose a lower-performance alternative.
I’m making a case for custom codes, not for using a 200 status code with it. My reply said the 200 didn’t make sense.
Of course once you use custom codes, the actual HTTP status codes do become less important, because there’s some redundancy there. That’s not an argument to do it wrong, but it is an argument that accurate HTTP status codes are less of a priority. So understandably some people will take shortcuts.
Apparently you find this very frustrating, but in the end it’s just an implementation detail. But it also sounds like you’re more frustrated with the service API as a whole than the fact it uses custom error codes specifically, so I’m just going to leave it at that.
I’m not arguing against that. Merely providing some counterweight to the idea that the author was “flinging shit in the trenches” 😅
I found the title of that section slightly triggering too, but the argument they lay down actually makes sense. Consistency helps you to achieve correctness in large codebases, because it means you don’t have to reinvent what is correct over and over in separate pockets of the codebase. Such pockets also make incremental improvements to the codebase harder and harder, so they do come back to bite you.
Your example of vendors doesn’t relate to that, because you don’t control your vendor’s code. But you do control your organisation’s.
Well, looking at your example, I think a good case can even be made for it.
“s23” doesn’t look like an HTTP status code, so including it can make total sense. After all, there’s plenty of reasons why you could want custom error codes that don’t really align with HTTP codes, and customised error messages are also a sensible use case for that.
Of course duplicating the actual HTTP status code in your body is just silly. And if you use custom error codes, it often still makes sense to use the closest matching HTTP status code in addition to it (so yeah, I agree the 200 in your example doesn’t make a lot of sense). But neither of those preclude good reasons for custom codes.
Oh, and then I pair it with a very boring Dell mouse for extra style.
Ha, I better not tell you about the Apple Keyboard I use with my Linux laptop then. Don’t like macOS much, but I love their flat keyboards.
There is a serious attempt for that actually: https://www.assemblyscript.org/
It doesn’t offer full compatibility with the regular TypeScript though, despite being very similar.
That’s not just pedantry, that’s unnecessarily narrow-minded. Ever heard of the corrupted heart? According to your definition, that’s an impossibility, unless the heart belongs to someone in authority, or something, I guess.
The point is, there is more than a single interpretation of things, and there is not a singular definition of corruption. Anyone can be corrupted, and giving examples that show that lawlessness permeates every level of society is a great way of showing that corruption is likely endemic in the culture.