Rust takes a much more sensible approach. Its question mark operator is semantically very similar to the rejected Go proposal except it’s a postfix operator. It forces you to be explicit about...
Rust takes a much more sensible approach. Its question mark operator is semantically very similar to the rejected Go proposal except it’s a postfix operator. It forces you to be explicit about propagating errors but does so with minimal boilerplate. I think the Go team have fundamentally misunderstood something if they think being verbose is the same as being explicit, and that the advantages of the latter can only be achieved via the former.
The author of this post seems to not understand how exceptions work, since the proposal was not to add exceptions to go, simply some syntax sugar for the existing idiom with no change in semantics. Exceptions unwind the stack an arbitrary number of levels until a handler is found, this is just an early return which is exactly how it already worked, just with less typing.
It also seems deeply twisted to suggest that an elaborate false flag operation in order to manipulate the community is necessary. This is not how software projects are usually managed, and for good reason. It’s really dysfunctional to think that instead of saying what you mean and doing what you say, you should manage a software project like an election campaign, strategizing about PR by pretending to do something you don’t intend just to send a message. I doubt this was what really happened and I sincerely hope not.
Even Linus has recently acknowledged that his acerbic tone can be counterproductive, but this is the sort of bullshit that you need someone like him to cut through and dunk in acid. To its credit and its detriment, software development is full of the kind of personality that doesn’t take kindly to manipulative bullshit, and if this were really how the Go team managed their project (which, again, I doubt it is), then that is the sort of thing that could cause anyone outside Google to abandon the project.
As for C#, it has exceptions just like Java, does it not?
I honestly can't tell sometimes, sarcasm on the internet is often indistinguishable from sincere stupidity. I see now that it has a "jk lol" at the end but I missed that on mobile. The reason I...
The author of the post was joking about this being a false flag operation.
I honestly can't tell sometimes, sarcasm on the internet is often indistinguishable from sincere stupidity. I see now that it has a "jk lol" at the end but I missed that on mobile.
I never said that C# did not have exceptions just like Java
The reason I thought you were saying something like that is that exceptions were the one example of Java's flaws you used, and later you said that C# learned from Java's mistakes. I guess you didn't intend to connect those statements, but you can see how it can be read that way, no?
A semi-pedantic afterthought—actually, the fact that C# does not include checked exceptions is one wonderful example of where it intentionally deviates from Java for the best.
I think that's full on pedantry, but I'll allow it. You can insert a comma there if you like: "has exceptions, just like Java [does]", not "implements exceptions exactly the same as in Java." Anyways, checked exceptions could be a good thing, forcing you to think about the behavior of a function and its various failure modes. Functional languages and functional-inspired imperative languages usually encode this in the type. The problem comes when you have both checked and unchecked exceptions, then you're combining extra hassle with a false sense of security.
Rust takes a much more sensible approach. Its question mark operator is semantically very similar to the rejected Go proposal except it’s a postfix operator. It forces you to be explicit about propagating errors but does so with minimal boilerplate. I think the Go team have fundamentally misunderstood something if they think being verbose is the same as being explicit, and that the advantages of the latter can only be achieved via the former.
The author of this post seems to not understand how exceptions work, since the proposal was not to add exceptions to go, simply some syntax sugar for the existing idiom with no change in semantics. Exceptions unwind the stack an arbitrary number of levels until a handler is found, this is just an early return which is exactly how it already worked, just with less typing.
It also seems deeply twisted to suggest that an elaborate false flag operation in order to manipulate the community is necessary. This is not how software projects are usually managed, and for good reason. It’s really dysfunctional to think that instead of saying what you mean and doing what you say, you should manage a software project like an election campaign, strategizing about PR by pretending to do something you don’t intend just to send a message. I doubt this was what really happened and I sincerely hope not.
Even Linus has recently acknowledged that his acerbic tone can be counterproductive, but this is the sort of bullshit that you need someone like him to cut through and dunk in acid. To its credit and its detriment, software development is full of the kind of personality that doesn’t take kindly to manipulative bullshit, and if this were really how the Go team managed their project (which, again, I doubt it is), then that is the sort of thing that could cause anyone outside Google to abandon the project.
As for C#, it has exceptions just like Java, does it not?
I honestly can't tell sometimes, sarcasm on the internet is often indistinguishable from sincere stupidity. I see now that it has a "jk lol" at the end but I missed that on mobile.
The reason I thought you were saying something like that is that exceptions were the one example of Java's flaws you used, and later you said that C# learned from Java's mistakes. I guess you didn't intend to connect those statements, but you can see how it can be read that way, no?
I think that's full on pedantry, but I'll allow it. You can insert a comma there if you like: "has exceptions, just like Java [does]", not "implements exceptions exactly the same as in Java." Anyways, checked exceptions could be a good thing, forcing you to think about the behavior of a function and its various failure modes. Functional languages and functional-inspired imperative languages usually encode this in the type. The problem comes when you have both checked and unchecked exceptions, then you're combining extra hassle with a false sense of security.