251–260 of 329 posts
require "yaml"
config = YAML.parse(File.open("test.yaml"))
> 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…
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.
Earlier quoted context omitted.
That and the bizarre thinking that ".unwrap" is a perfectly ok thing to write in some cases (don't worry it will never make it to production!). No, ".unwrap" turns input errors into bugs, and there is no production code where this is more desirable than an exception.
I don't get it. .unwrap() turns an undesirable situation into printing an error message and exiting with a nonzero status. There are plenty of situations where that is exactly what you want, and not a bug at all. For example, in my production Rust code, i deal with all errors in reading and parsing config files with .unwrap() or .expect(). If a program cannot read its config file at startup, it cannot correctly do it…
Earlier quoted context omitted.
> panics aren't for recoverable errors, in any circumstances. And I understand that. Hence why unwrap everywhere is harmful.
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".
Earlier quoted context omitted.
GC, though, an a much, much smaller community.
googling "GC language" predictably comes up with mostly links to garbage collection. Do you have a link to this language?
[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…
I think that part of it is that the idea of a Result type being normal will help prevent much of the cruft and burying we see with exceptions. I also feel like handling Result types is more natural than exceptions. First, you _have_ to do it, even if that means a try! and passing the buck. The syntax for this isn't as monstrous as it is for checked exceptions as well. Second, it feels more like a natural code-flow, n…
That said, dict also has get(), which lets you specify the default value if key wasn't found (and the default default is None).
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…
I cant even opt out of using exceptions? Good thing I didn't waste my time with this lang.
Earlier quoted context omitted.
I think that part of it is that the idea of a Result type being normal will help prevent much of the cruft and burying we see with exceptions. I also feel like handling Result types is more natural than exceptions. First, you _have_ to do it, even if that means a try! and passing the buck. The syntax for this isn't as monstrous as it is for checked exceptions as well. Second, it feels more like a natural code-flow, n…
You don't have to convince me of the value of Result types, I prefer them too. I've only written a couple thousands of lines of Rust but tens of thousands of Haskell which rely on the same concepts (though its nicer with do notation). I don't have faith in the masses though and right now there is a strong selection bias in Rust that means only people concerned with quality and correctness are using it in the first pl…
This is not a problem in Rust.
Earlier quoted context omitted.
Sounds like an aversion to me. By the time Go was developed, there was no doubt in my mind that generics (or some kind of polymorphism along those lines) were an essential feature for any new statically typed programming language. The fact that Go's developers "don't feel an urgency for them" to me makes it sound like they are living in the 1980s.
But Go does have polymorphism. It is achieved through the "interface" concept, which allows dynamic binding of any statically typed objects that match a given set of function signatures. In my experience, with the way it's been done it actually gets you pretty far in terms of problems you typically solve with generics in other languages. That said, personally I'd love to have generics on top of that. Consequently, I…
The fact is that Go is the only statically typed language, with any claim to being mainstream, that doesn't have generics. And it's not like generics are some kind of a new and radical concept. Java had them for 13 years now; C# had them for 12. There's literally millions of lines of code written in popular languages that utilize generics, which can be used as a guide to proper design, and understand its consequences.
The idea that there needs to be more "baking time" for generics simply doesn't hold water at this point. It amounts to insisting that structured programming (loops etc) should not be adopted "without fully understanding the consequences at all levels", and meanwhile we'll just use if+goto - in 1980.
Earlier quoted context omitted.
Well, at the time I would have thought it was required for the language to become widely used. But since that's clearly not true I suppose I have to downgrade that statement to say it's required for me to write code in the langauge and not feel like I'm constantly banging my head against a wall. Frankly, yeah, I think Go programmers are kind of stuck in the 1980s in some respects. This isn't something I'm completely…
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…
I don't think you misjudges the differences in complexity here at all. But wouldn't that have more to do with the different approaches to memory management?
>aforementioned cognitive load without giving up those sweet sweet compile time checks
I would argue the cognitive load comes mostly from nominal typing and lack of type inference. A counter example would be the Crystal language which has a very strong type system, but is exposing barely any of it as 'added cognitive load'.
This correlation between 'cognitive load' and 'expressiveness of a typesystem' seems unfair. Having to keep track of all the patterns that are valid but not supported by the type system is also a type of added (hidden) complexity.
Even the poster-feature of Rust has a (IMO) much easier cousin with the same (and more) advantages called 'the Clean programming language' in the shape of 'uniqueness types'. And most of the complexity in Rust is the result of the type system not being expressive enough for how they are attempting to use it, rather than the opposite.