3 ms·
An advantage over Erlang and Elixir is that this looks like any language from the C/Java family including all the clutter as in import std.fs.file.ReadOnlyFi
by pmontra 3y ago
An advantage over Erlang and Elixir is that this looks like any language from the C/Java family including all the clutter as in
import std.fs.file.ReadOnlyFile
import std.stdio.STDOUT
class async Main {
fn async main {
We basically have a zero signal to noise ratio here but it's a declarative pattern common to many successful languages so it will make many people feel at home. I think it's a good design decision.
On the other side I feel like the naming decisions in the error handling section are weird. The expect method breaks my expectations:
let file = ReadOnlyFile
.new('README.md')
.expect("the file doesn't exist")
file
.read_all(bytes)
.expect('failed to read the file')
Well, no: I expect the file to exist and to be able to read from it.
An expect method is common in test libraries and it behaves like an assertion. When I see an expect method I expect it to have a condition and stop the program if it evaluates to false, or propagate the error in any way appropriate to the language. So I expected
let file = ReadOnlyFile
.new('README.md')
.fail("no_ro", "the file exists but it is not read only")
.expect("created")
.expect("open")
I intentionally changed the probable behavior of the class, that seems not to create a read only file but only to open it. I made it create the file to show a softer version of expect() than an assertion. At least one of them must be true. The implementation of how to chain those methods without failing at the first failed expect() is a detail.
And about .unwrap_or(0), what that even means? The linked post [1] hints about a
"wrapper type,” like Maybe<T>
so it's an established naming convention in some language but if it works as I think, what about this?
.default(0)
That because unwrap_or seems to ignore errors and return a default. If it doesn't, it confirms that it's a bad name.
[1] https://joeduffyblog.com/2016/02/07/the-error-model/ https://joeduffyblog.com/2016/02/07/the-error-model/
- filmor 3y ago`unwrap_or` and `expect` work exactly like they do in Rust. The naming of `expect` works nicely if the argument is the precondition that failed (see https://doc.rust-lang.org/std/error/index.html#common-message-styles https://doc.rust-lang.org/std/error/index.html#common-messag...), e.g. .expect("should have opened file")
- pmontra 3y agoWith all the respect for a language that succeeded and the evidence that its choices are at least good enough, I think that they got it backwards. expect("the file is open") is a positive statement. expect("should have opened file") is a kind of negative and less easy to understand. They should have hinted the developers to use the correct style with a different method should("have opened file") That said, it did not hinder Rust, maybe it even contributed to its success so it's OK even if it feels strange to me. But unwrap is really an awkward word to pick.
- YorickPeterse 3y agoYou're right that "expect" combined with the error message here could be better. Specifically, I've been wanting a better name for the method, but haven't really done anything about it yet. The name itself is taken from Rust. "unwrap_or" could perhaps be called "unwrap_or_use_default", but that's a tad too much to type. What it basically does is this: match the_value { case Some(val) -> val case _ -> 0 } i.e if you have a Some, you "unwrap" its value and return it, otherwise you return a default value.
- andrenth 3y agoI’ve always been partial to borrowing a bit from Perl and renaming .expect() to .or_die()
- pmontra 3y ago> The name itself is taken from Rust. That's great if you want to grow your user base with Rust developers. It's what Elixir did with Ruby. About me, I unwrap presents IRL and never unwrapped anything in a programming language, not using that very name. That's why it was totally opaque to me.
- irq-1 3y agook_or()
- karmakaze 3y agoOT pet peeve/PSA: don't put `.new`/function on a separate line after the type/variable name--at least until our editors/tools (e.g. Github) can all do multi-line/parser aware searches.