261–270 of 329 posts
Earlier quoted context omitted.
googling "GC language" predictably comes up with mostly links to garbage collection. Do you have a link to this language?
There's the Nim website[0] as well as the document describing the (soft) real-time GC that Nim comes with[1]. [0] https://nim-lang.org [1] https://nim-lang.org/docs/gc.html
Earlier quoted context omitted.
The anti-pattern I've seen in dysfunctional enterprise development shops (i.e. most of them) is that checked exceptions mean exceptions that "we'll never have" get buried lower in the stack; so code can fail silently and continue running just to avoid the monstrous checking code and propagation of exception type declarations up the call stack. I don't see how the Rust approach would avoid this fate but I doubt it wil…
> fail silently No. They are usually logged. The difference is that with exceptions, the logging will occur at a higher level and be done uniformly while in Rust you'll have to explicitly thread the error through the call stack manually to log it at a higher level.
What about non-fatal errors such as retries in a GUI library that loads an image from the web, how are they logged or otherwise propogated to the developer?
Hello Justin Turpin! Sorry to hear your struggles with rust. It's always going to be a bit more verbose using rust than Python due to type information, but I think there are some things we could do to simplify your code. Would you be comfortable posting the 20 line code for us to review? I didn't see a link in your post. Anyway, so some things that could make your script easier: * for simple scripts I tend to use the…
If I know that the unwrap is 100% safe I tend to write: `.expect("Invariant: $REASON_WHY_THIS_NEVER_FAILS")`
Earlier quoted context omitted.
I've used both Rust and Go daily for years (before they reached 1.0, respectively) and I'm generally happen with the experience that they give me. Not all languages need to have a type system as sophisticated as Rust's or Haskell's. > but as a result they ignored 30 years of programming langauge research and implemented a primitive type system that basically provides nothing over C As someone who also has a decent am…
>On the one hand, we have the "clearly superior" Rust approach to error handling that checks a lot more at compile time than Go does, but on the other hand, Go programmers don't ever need to "learn error handling" at all. They have a simple convention with a reasonably low bug rate (IME, anyway). I don't think you misjudges the differences in complexity here at all. But wouldn't that have more to do with the differen…
What makes you say that? Rust's approach guarantees more type invariants.
I don't buy for a second that type inference has much to do with this. Firstly, Rust has type inference, it just isn't global. Secondly, I've found that type inference everywhere makes the cognitive load much worse, not better.
And I wasn't actually drawing a correlation between cognitive load and expressiveness. Namely, expressiveness isn't the final word. Much of PL theory is devoted not just to improving expressiveness, but making that expressiveness more accessible to the masses. Compare Haskell with System F, for example.
Earlier quoted context omitted.
Er, it was a response to this line of yours: > Absolutely but using the same mechanism (unwrap/panic) for both types of errors - recoverable and recoverable Nobody is using panics with the intent to recover, in the classic sense of "recoverable error".
See above where one user is using .unwrap for parsing errors (input errors are recoverable).
Earlier quoted context omitted.
If I recall correctly we just couldn't come up with a great name for it. To me "expect" is a positive action, but the argument is about it failing to meet the expectation. Semantically I like `thing.unwrap_or(|| panic!("failure message"))`. It feels more like what I would want to say, but it just is so wordy. Ultimately I'm happy we just picked something and moved on, but still mildly annoys me whenever I write it. I…
.beware("could not open file");
.be_wary_of("but hole")Earlier quoted context omitted.
How is this problem solved for C++?
Sadly by what also helped it gain adoption but also hinders the language's safety, copy-paste compatibility with C (to a certain extent). Meaning that many C++ applications, even nowadays, are actually C compiled with C++ compiler (not even classes are used). So the transition between skill levels is quite gradual. For me it is hard to tell, because I know the language since the C++ARM days, which means it had a feat…
> Only if the programmer chooses to not handle exceptions, which is bad practice. So basically you're telling me that the example Python script is actually considered bad practice. I didn't saw that coming, I thought it was just grrrreat without any checking. Keep the wisdom coming! > In Python you can catch an exception and continue the operation in a different manner. But he doesn't do that. > Well, you seem to not…
You know, if you want to be an asshole, I'm not going to try and have a discussion with you. The example the author gave is not the actual script he was using to monitor Jenkins. It's a small portion of it. Seriously, if someone hasn't used Python before, I can't just assume that they know how Python's exception handling works.
It seems pretty obvious to me that production level Python with actual error-handling doesn't look as simple as his three-liner.
You can't compare that to a language that actually forces you to deal with it. If you follow up on the compiler hints and follow safe patterns while working in Rust (like no forced unwraps) you'll end up with very robust code, something that's up to the discipline of the Python programmer.
Earlier quoted context omitted.
Sorry, I'm trying very hard to learn Rust, and I'm willing to accept a lot of its restrictions, but this didn't clear anything up. Why does every library implement its own Error type? It feels like reinventing the wheel, and it takes a lot of boilerplate code. If you need to distinguish different kinds of errors, why not, for example, have a lot of useful pre-defined error types like Python does?
You can use pre defined error types. Have you seen https://doc.rust-lang.org/std/io/enum.ErrorKind.html ?
The author might consider Nim - https://nim-lang.org/ . It is a statically-typed compiled language that about equals Rust in performance, but has a much cleaner higher-level Python-flavored syntax, and a very Pythonic parsecfg module in stdlib. PS. To my earlier downvoters can I have my hard won karma back, please??? This is the response I have been advised to proffer after consulting on the Nim forum, after my earli…