Maybe just don't utilize "utilize" or "utilise" at all. There are very few cases where utilizing "utilize" or "utilise" is better than using "use".
Readit Newsmayoff commented on Canada's Carney called out for 'utilizing' British spelling bbc.com/news/articles/cj6... · Posted by u/haunter
mayoff commented on Why doesn't Apple make a standalone Touch ID? jeffgeerling.com/blog/202... · Posted by u/thomasjb
I don’t know if Cory Doctorow has read the “fantastic 1981 novel”, but I have (decades ago) and as I recall the plot of the book and the plot of the movie are very different from each other. The author of the book didn’t write the screenplay and I doubt he had much (if anything) to do the character designs in the movie. So even if he has the rights to his novel back, it’s not at all clear to me that he could just make (or sell a license to make) a straight, recognizable sequel to Disney’s movie without getting back into bed with Disney, and clearly Disney isn’t interested or they’d have done something by now.
I’m wealthy but I wasnt always. When I was 22 through 30 I didn’t take a single vacation that wasn’t driving to a long weekend. My wife and I both pulled 60 to 70 hour weeks for our entire 20s (I still do).
No one “deserves” free time. If you don’t want to work 70 hours a week and want to watch Netflix instead, go for it, but don’t bitch to me
Some people suffer and think "I had to go through this and I hope no one else does."
Some people suffer and think "I had to go through this so everyone else should too."
Honestly, I thought the diatribe would focus on needless complexity.
The starting example is how I'd do it in C:
```
void f(const char* p) // unsafe, naive use
{
FILE \*f = fopen(p, "r"); // acquire
// use f
fclose(f); // release
```
Wouldn't the simpler solution be ensuring your function doesn't exit before release? All that c++ destroyer stuff appears somewhat unnecessary and as the author points out, creates even more problems.
The problem is that it's easy to do it wrong and the C compiler doesn't help you. RAII prevents you from leaking the resource, but the complaint in the post is that it can be cumbersome to use RAII in C++ if acquisition can fail and you want to handle that failure.
From what I can read Swift gives you a stack trace which is good. At the moment I’m using Go where that stack is only generated where the panic is triggered, which could be much higher up. Makes it a lot more unwieldy to figure out where an error happens because everyone uses:
> if err != nil return err
Swift doesn't capture a stack trace in the `Error` object, but Xcode can break when an error is thrown if you set a “Swift Error Breakpoint”, and the debugger will show you the stack trace. Under the hood it just sets breakpoints on the runtime functions `swift_willThrow` and `swift_willThrowTypedImpl`.
Swift user here: I have to say one of the best features of Swift is the exception handling. Which is to say, exceptions in Swift are not C++/Java/Obj-C style exceptions, but instead are a way to return an error result from a function. And Swift enforces that the error is handled.
That is, a `throw` statement in Swift simply returns an `Error` value to the caller via a special return path instead of the normal result.
More explicitly, a Swift function declared as:
func f() throws -> T {
}
func f() -> (T|any Error) {
}
Another really nice thing about Swift is that you have to put the `try` keyword in front of any expression that can throw. This means there's no hidden control flow: if some function call can throw, you're informed at the call site and don't have to look at the function declaration.
I saw that in Swift, a method can declare it throws an exception, but it doesn't (can't) declare the exception _type_. I'm not a regular user of Swift (I usually use Java - I'm not sure what other languages you are familiar with), but just thinking about it: isn't it strange that you don't know the exception type? Isn't this kind of like an untyped language, where you have to read the documentation on what a method can return? Isn't this a source of errors itself, in practise?
Swift gained limited support for “typed throws” in Swift 6.0 (2024).
https://github.com/swiftlang/swift-evolution/blob/main/propo...
I say limited because the compiler doesn't (yet, as of 6.2) perform typed throw inference for closures (a closure that throws is inferred to throw `any Error`). I have personally found this sufficiently limiting that I've given up using typed throws in the few places I want to, for now.
mayoff commented on Revisiting Interface Segregation in Go rednafi.com/go/interface-... · Posted by u/ingve
See also https://news.ycombinator.com/item?id=36908369 (“The bigger the interface, the weaker the abstraction")
mayoff commented on Precompiled headers and why Squid won't be using them (2023) squidproxy.wordpress.com/... · Posted by u/mooreds
I hate cmake but this is something cmake does well in my experience. I had to write a Godot 4 plugin and Godot has many many header files. I made a project header that #included all the Godot headers, and a single target_precompile_headers directive in CMakeLists was enough to get it working on Mac and Linux (and I think on Windows but I didn’t need to run it on Windows).