151–160 of 183 posts
Earlier quoted context omitted.
I think that's too extreme. There are many legitimate reasons to slice non-ASCII text - for example, to split it on newlines.
That's not trivial and different languages vary in how they handle new line characters even. https://stackoverflow.com/questions/44995851/how-do-i-check-...
Earlier quoted context omitted.
I still think that using the common [] operator for this is a mistake. Strings shouldn't offer [] at all, and instead should provide methods like codepoints(), bytes(), grapheme_clusters() etc for indexing, slicing, and iterating. The reason being that the behavior of [] for string varies widely in different languages, and so this is something that's best made explicit, both to force the author of the code to conside…
I'm quite thankful that Rust has succinct notation for slicing strings. Do note that `string[n]` is not supported, so you'll stumble over an inconsistency in your mental model quite quickly if you think slicing is by codepoint.
Earlier quoted context omitted.
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…
The answer to this question is quite involved. As you may already know, Rust at one time had a fiber model, but it was removed in favor of Futures. One big advantage of Futures is they are decoupled from their execution environment. For example, different types of executors can be used depending on the type of Future. For example, you may have an IOThreadPoolExecutor to handle accepting and responding to connections…
You can drop to raw fd's and do whatever you like... of course this negates a lot of the niceties that go affords you.
Earlier quoted context omitted.
That seems like taking it too far. It's like using pointer arithmetic to index a linked list on the assumption that the nodes happen to be allocated contiguously in memory. I mean, I guess the thinking is, indexing a Unicode string isn't cheap, but indexing strings used to be cheap once upon a time, when strings were encoded in fixed one-byte-per-character representations, so let's pretend that's still the case and p…
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…
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 definition of safety. It's one step up from undefined behavior, granted, but it's not a very high standard. In practice, in most programs, you'd want to ensure that such a panic would never happen, and personally I think the language's unhelpfulness in that regard is a wart.
Earlier quoted context omitted.
No, because x NaN are false for any value of x.
Yes, the literal < in the language induces a partial order by convention. What I'm getting at in my comment is that you can define a sensible total ordering.
This is more in line with the "bank lending model " it advocates.
> A lot of great, well loved, crates don’t have a lot of Github stars. This was a really important learning for me. When I'm looking for crates to solve a problem and there's only a handful of them, I almost always go through every single one of them, even if some have thousands and the others only tens of downloads. It's an incredible feeling to find those unknown diamonds..
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...
This seems specious to me. The only way to get an invalid index in a string in any language is that you either have an array index arithmetic error or you are blindly operating on a string you haven't validated . If you want all the data after a : character, you slice on the index of the :. The character after it is going to be the beginning of a UTF-8 character. You do not under any circumstances guess that the colo…
Granted, this is certainly incorrect but has little to do with safety, especially if the downstream code has to revalidate everything anyway.
Earlier quoted context omitted.
It is a common pattern in Rust to use [] for things that cannot fail and will panic otherwise and a method for things that can fail and return Option or Result. e.g. my_hashmap["foo"] will panic at runtime if the key "foo" is not present, or return the associated value if it is. But my_hashmap.get("foo") will return None if "foo" is not present and Some(value) if it is.
What's the point of the [] version then? It seems inherently more dangerous, and Rust emphasizes safety. I know it wants to be pragmatic as well as safe, but this seems like a strange default.
> Like Go, Rust can compile statically linked linux binaries. The GNU C library (needed not only by C programs for C things) doesn't support static linking, so the only way this is possible is to use another library entirely, or raw inlined syscalls (where applicable).
Of course, there's the usual issue with glibc symbol versioning, so you probably want to build your binaries on the oldest supported system (say, a centos 6 container).