311–320 of 329 posts
Earlier quoted context omitted.
We are actively working on rustfmt, which should add some consistency overall. Some people won't use it, of course, but many have said they will.
The kind of 'coding style' that is varying here is probably more in the domain of Clippy than rustfmt. But there are people working on that too!
Rust's aversion to exceptions is exactly like Go's aversion to generics - a strongly held position that doesn't actually make anyone's life easier.
We nearly had a hostile language fork over mandatory unwinding. It is not something that the language team decided and refuses to acknowledge. Rather, we had to respond to the demands of our embedded users.
Earlier quoted context omitted.
There are many ways to have both enforced error handling AND less boilerplate. Java's checked exceptions are much maligned but would work very well here. Another way would be having more syntactic sugar for Result-style monadic error handling, like the do notation in Haskell or for..yield in Scala. Another issue raised by the original post is the fact that Rust has no top-level concrete error type that is convertible…
Java's checked exceptions were a disaster. It essentially handcuffed you, limiting what you could do in an overridden method (because you can't add more exceptions to the throws list). So you end up wrapping in RuntimeExceptions and then later having the whole app fall over because the framework that's expecting your class was only designed to handle the checked exceptions. So yeah, want your implementation to consul…
Earlier quoted context omitted.
Good point. I am not very familiar with Rust (good to hear it seems to treat this well, however!) but a cursory examination of Go code shows that runtime errors can end up being entirely ignored and that seems crazy to me. > I tend to be more interested in how the features of a language help programmers to keep writing correct and maintainable code as the complexity of a project grows. So let me guess, you too have w…
> but a cursory examination of Go code shows that runtime errors can end up being entirely ignored and that seems crazy to me. I'm not sure whether this is a thing in Go, but I tend to think that having a ubiquitous null object in your language that's "falsey" is responsible for a lot of problems like what you describe and is basically a misfeature outside of C. > So let me guess, you too have worked on very large sp…
> having a ubiquitous null object in your language that's "falsey" is responsible for a lot of problems like what you describe
In practice I haven't really seen this causing problems, for languages like Ruby and Elixir where the only "falsey" values are nil and false. And it enables some very readable code.
Earlier quoted context omitted.
Good point. I am not very familiar with Rust (good to hear it seems to treat this well, however!) but a cursory examination of Go code shows that runtime errors can end up being entirely ignored and that seems crazy to me. > I tend to be more interested in how the features of a language help programmers to keep writing correct and maintainable code as the complexity of a project grows. So let me guess, you too have w…
>right now it's Elixir but I'm going to be evaluating Haskell, not a huge fan of the JVM langs tho FYI, Haskell is not a JVM language. It compiles to binaries, the compiler is called GHC. Elixir runs on the Erlang VM, also unrelated to JVM.
> 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…
Earlier quoted context omitted.
I have run into something very similar in somebody else's python program where they declared a string that was later used (based on some conditionals) to locate a file. The thing is that most of the conditionals were never hit under ideal conditions (like passing all args etc.). It took me a lot of time to track down the bug (also because of the lack of awesome debuggers for Python).
> The thing is that most of the conditionals were never hit under ideal conditions (like passing all args etc.). Your debugging work in this case might have also been alleviated by a good unit test covering this functionality.
Earlier quoted context omitted.
In the context of this article and discussion, panics via unwrap (or better, expect) is a fine answer, and I'm not sure why you think it is hypocritical to suggest it, especially to Rust newcomers who are looking to write script-like programs. Panics mostly match the verbosity, ergonomics, and functionality of the analogous python script. Now I agree that a caveat should follow advice like using unwrap and expect, pe…
> a caveat should follow advice like using unwrap and expect, perhaps a small blurb about how they should eschewed for better error handling when you want to catch the errors and make decisions because of them. That is literally the definition of hypocrisy; the behavior of people who do things that they tell other people not to do. "When you do this, do it like this, but properly with error handling." :P Anyhow, as I…
Except I'm not saying that at all.
I said it's fine to use unwrap() or expect() if you want script-like default behavior (a developer-centric error message and a quick exit with a bad return code) and if you want something more than that, then use something better than unwrap() or expect().
There's no hypocrisy here. I think anyone should follow that advice. Me, you, a newb to Rust, a Rust veteran, anyone. Same advice.
If the goal is [fast, compiled, statically typed], a language like Crystal [1] would probably be a better fit for the author: require "yaml" config = YAML.parse(File.open("test.yaml")) [1] http://crystal-lang.org
Does Crystal have YAML.load_file like Ruby does? Loading a YAML file only requires one method call in Ruby.
Earlier quoted context omitted.
If you don't mind me asking, what in particular were you searching for? I agree that Nim's documentation needs a lot of love but would like suggestions on what specifically you had trouble with so that I can at least improve that (for now) :)
Unfortunately I can't remember the details at this point. There was something I couldn't figure out with the `new` function and heap allocation in general, and I also got frustrated trying to understand some things about the type system. I do know one thing about `new` was that it took me forever to figure out how to allocate anything on the heap at all, only to find a couple lines about `new` in the API docs. At lea…
I'm sure your original question was more nuanced, but for anyone wondering about this basically any ref type is heap allocated, and you do this by calling new, so:
type MyType = ref object
var myHeapObject: MyType
new myHeapObject