> A juvenile, said Boersma, who researches Magellanic penguins in Argentina. This flightless seabird was probably born around November, which is breeding season, she said.
I keep an eye on https://github.com/let-def/texpresso which is a live rendering and error reporting for LaTeX; just watch the videos that are in README and you will get amazed!
I have hard time understanding why they didn't go with
func printSum(a, b string) error {
x := strconv.Atoi(a) or {
return error
}
y := strconv.Atoi(b) or {
return error
}
fmt.Println("result:", x + y)
return nil
}
> Unfortunately, as with the other error handling ideas, this new proposal was also quickly overrun with comments and many suggestions for minor tweaks, often based on individual preferences. Ian closed the proposal and moved the content into a discussion to facilitate the conversation and to collect further feedback. A slightly modified version was received a bit more positively but broad support remained elusive.
> After so many years of trying, with three full-fledged proposals by the Go team and literally hundreds (!) of community proposals, most of them variations on a theme, all of which failed to attract sufficient (let alone overwhelming) support, the question we now face is: how to proceed? Should we proceed at all?
You need to assign the error to a variable, probably. So it would have to be more something like:
n := strconv.Atoi(s) or |err| {
return fmt.Errorf("foo: %w", err)
}
n := strconv.Atoi(s) or |err| {
if !errors.Is(err, pkg.ErrFoo)
return fmt.Errorf("foo: %w", err)
}
}
Just "error" (which shadows the built-in type) won't really work.
I'm just making up syntax here to illustrate the point; doesn't look too brilliant to me. A func might be a bit more "Go-like":
n := strconv.Atoi(s) or func(n int, err error) {
return fmt.Errorf("foo: %w", err)
}
All of this is kind of a moot point at Robert's blog post says that these proposals won't be considered for the foreseeable future, but IMHO any error handling proposal should continue to treat errors as values, which means you should be able to use fmt.Errorf(), errors.Is(), mylogger.Error(), etc.
If you do this, returning the error last is now part of the language rather than a convention. You’d be making a pretty large language change.. and for what? One line of code that’s already folded away by any modern editor?
Nice job! I don't know whether you know https://github.com/java-decompiler/jd-gui or not, but in case you haven't seen it before, maybe you could use it as a reference, since it's written in Java, for extra fun with your adventure?
Things may have changed, but my impression as of several years ago was that JD-GUI was far, far behind the state of the art (Fernflower, aka the built-in IntelliJ decompiler) in terms of correctness, re-sugaring, support for modern Java features, and so on. Fernflower is open source as part of IntelliJ: https://github.com/fesh0r/fernflower
Not that I know of. The features I'd want in order to consider a decompiler GUI "good" (e.g. a good text editing control, go-to-definition, find usages, manual renaming of obfuscated symbol names) quickly approach the scope of an entire IDE, though.
How about the opposite? You're not a paying customer, don't use trials... but let us put your logo in our website as a valued user... with some praise from the CTO, please.
If you are well connected, with various friends and acquaintances, have a discussion with them about what they do either for a living or for a hobby and you might end up getting a job in a profession you never imagined before, that you might actually enjoy it more than your current tech position.
Honestly, when I want to compile a Rust project and see all these dependencies getting pulled in to get compiled along with the project, it gives me goosebumps, because I don't know whether these crates are safe and secured or not...
You're definitely not alone.
This situation is not new, and it isn't acceptable either.
The concept of `features` when using a crate is kinda cool as "you only download / compile what you use" *but* most of the crates are very badly designed, and also developers do not tend to reinvent a very tiny wheel when they can, but heavily depend of possibly dangerous crates to just serialize or deserialize a very simple data structure...
It's very annoying, as this increases the compilation time and introduces possible unsafe behavior in larger crates.
Some people _do_ care about this (e.g. the proponents of this new RFC: https://github.com/rust-lang/rfcs/pull/3810). However, for some reason (culture, I guess?) there isn't much momentum yet to change the status quo.
Yeah, I think in some sense it definitely looks worse than it is since a single crate like Tokio is spread among 20-30 crates. However even accounting for that there's still just alot of raw code...
