161–170 of 183 posts
let foo = "..."; let foo = parse(foo); let foo = escaped(foo); Is it really shadowing or mutation of foo? I would consider this shadowing (something you can do in OcaML): let foo = "..." in let foo = parse(foo) in let foo = escaped(foo) in dosomething(foo);;
let foo = "..."; let foo = parse(foo); let foo = escaped(foo); ... doSomethingWith(foo); I don't see how this is helpful for avoiding the bug described. The most common bug with this type of code is mistaking which form "foo" represents at a given line of code, or that form changing as the code evolves. For example, if one programmer writes let foo = "..."; let foo = parse(foo); ... doBarWithFoo(foo); and another pro…
I believe the way this is solved is by having the type of escaped(foo) different than that of parse(foo) and only accepting a EscapedString in doBaz and an ParsedString in doBar. Your type structure at no extra runtime cost is String : ParsedString : EscapedString. This ensures you don't escape strings before parsing them too. Nice!
type A = B
f :: A -> _
newtype EscapedString = EscapedString String
f' :: EscapedString -> _
I'm a network engineer, and I've done C++ for over a decade now. One of the nice things about Rust is that they decided to go with async over fibers, which is in line with how most high performance C++ is written. The Rust team also isn't rushing Future out the door, so it's coming along much nicer than the C++ Future, which is usually replaced because it's not monadic. Rust is great, and I highly recommend learning…
I am a big fan of rust but I don’t think the Async using the ”await” keyword or using Future/promis is the way to go. I wrote a large web app in scala using Futur only and it turned into a monster because of it. Even if you don’t use callback you still need to manualy unwrap them and they pollute your méthode signature. Then more recently I wrote a pub/sub server in c# using the “await” keyword. While much better it…
Chrome manages to do async stack traces for their implementation of the similar JavaScript feature. I wonder if this would be possible for C# and Rust.
Wow the Rust hype is really an echo chamber right now. Seems very academic and nobody really seems to be using it in production..
I've used it in production, and subjectively it was much easier to work with than C++.
One thing I don't like about Rust is how taking a slice of a string can cause a runtime panic if the start or end of the slice ends up intersecting a multi-byte UTF-8 char. I would prefer it if this feature didn't exist at all rather than cause runtime panics. https://play.rust-lang.org/?gist=e02ce5e9aacfee3a2b4917d5624...
It's not a problem in practice, because you'd use something like `.char_indices()` iterator, or result from a substring search, etc. to get correct offsets in the first place. It's not useful to blindly read at random offsets in UTF-8 strings. If it didn't panic, you'd get garbage. If offsets were automatically moved to skip over garbage, you wouldn't know what you're getting, and your overall algorithm would likely…
And in the rare cases, when it's not a bug, then one can just use `as_bytes` which would be good to do in any case, to indicate to other humans that this is not a bug.
B.t.w. I love the error message `[..3]` generates: "thread 'main' panicked at 'byte index 3 is not a char boundary; it is inside '早' (bytes 2..5) of `ab早`'" — I've never seen such easy to understand error messages in any language (except for in a few cases in Scala).
Earlier quoted context omitted.
You can use ? on an Option if your type returns an Option. If it returns a Result, you can use ok_or()?, and at some point in the nearish future, you can just use ?.
I see, not very familiar with both those idioms `?` and `ok_or()?` My current understanding is that those would return an Error only? I was more describing cases where you do want to return, but not necessarily return an `Error`. For instance in a simplified example function that returns a boolean, you could decide to return `false`. is it possible there? // Function that returns a boolean value fn is_equal_to_ten(n:…
fn is_equal_to_ten(n: Option) -> bool {
n.map(|n|n == 10).unwrap_or_default()
}Earlier quoted context omitted.
It's not a problem in practice, because you'd use something like `.char_indices()` iterator, or result from a substring search, etc. to get correct offsets in the first place. It's not useful to blindly read at random offsets in UTF-8 strings. If it didn't panic, you'd get garbage. If offsets were automatically moved to skip over garbage, you wouldn't know what you're getting, and your overall algorithm would likely…
Couldn't syntax like `a_string[..3]` be made to result in compilation errors in Rust? Since that'd almost always be a bug? (right?) And in the rare cases, when it's not a bug, then one can just use `as_bytes` which would be good to do in any case, to indicate to other humans that this is not a bug. B.t.w. I love the error message `[..3]` generates: "thread 'main' panicked at 'byte index 3 is not a char boundary; it i…
Earlier quoted context omitted.
There's a few things that come into play here: First of all, panics are perfectly safe. None of this has to do with safety guarantees. Second, the [] syntax is controlled by the Index trait, which returns an &T, not an Option . It does this due to Rust's error handling philosophy. There's two kinds of errors: recoverable and unrecoverable errors. When something shouldn't fail, unless there's a bug, you shouldn't be u…
Scala programmers would recognize this as the difference between () and .get(). I hope rust copied scalas syntax- its much cleaner, rather than trying to be nice to the established system languages (c/c++) This would also free up the [] to be used for generics and avoid syntactical warts like :: parsin
It doesn't remove those warts, it moves them.
Wow the Rust hype is really an echo chamber right now. Seems very academic and nobody really seems to be using it in production..
Quite a few people are using it in production: dropbox, npm, and I believe amazon and microsoft. I've used it in production, and subjectively it was much easier to work with than C++.
Earlier quoted context omitted.
Panics are not unsafe. Panic exists in Rust because they are safe. If you don't want a panic on index, just don't index. Indexing into a UTF-8 string doesn't serve any reasonable consistent purpose anyway, because it is an abstraction of text that doesn't provide support to the notion that a "character" is more fundamental than a word or paragraph, etc. Rust's string slicing exists solely to make ASCII text easy to h…
Indexing into a UTF-8 string doesn't serve any reasonable consistent purpose anyway If that's true, isn't it the job of a type system to help avoid such nonsensical operations? If "slice" only makes sense for byte arrays and ASCII strings, it could be provided on those types without being defined on UTF-8 strings. Panics are not unsafe. Panic exists in Rust because they are safe. That's "safe" by a very limited defin…
It's not strictly true, because there are situations where you want to slice UTF-8. For instance, if you already know where the code point boundaries are for newlines. But if you know that, then you've run something like a regex with >O(1) behavior and you certainly wouldn't want string slicing to do redundant work.
>hat's "safe" by a very limited definition of safety
That's the definition of safe that is used. Safety in the context of Rust means memory safety. (Division can panic, btw.) If you don't see why undefined behavior is so much worse than a panic, then do some research on it. If you want programs that never fail, you need a comprehensive plan that takes into account things like hardware failure. A programming language can't do that.