Things Rust shipped without • Hacker News Board

Re: Things Rust shipped without

#211

Post by barosl » Sat, Jul 04, 2015, 3:37 AM UTC

88e282102ae2e5b wrote: post #38

andresmanz wrote: post #18

I'd like Rust to be shipped without counterintuitive standard library function names and that book with all its style 'recommendations'. And I'd like the Rust compiler to be shipped without that non-snake case warning enabled by default. Language creators won't endear themselves to me by ranting. The problem I have with Rust is _not_ the language itself.

The idea that "[u]sing a return as the last line of a function works, but is considered poor style" irks me so much. A lot of what I find appealing about Rust is that it makes so much explicit through its type system, so I don't understand the philosophy behind preferring implicit returns, especially since you could have a scenario where someone hasn't finished writing a function but it still compiles without error.

The most compelling argument I've seen is that you don't explicitly `break` at the final run of a loop, either. An explicit `break` or `return` in the middle of a body can be thought as "abnormal" control flow. Otherwise, normal control flow will take place. As for a function, it would be returning the last expression.

Re: Things Rust shipped without

#212

Post by steveklabnik » Sat, Jul 04, 2015, 3:37 AM UTC

yazaddaruvala wrote: post #198

andrepd wrote: post #12

What about things that Rust shipped without that should have been included?

I really wish Rust/stdlib had been built around a good async io story. Right now it just feels neglected "because the crates ecosystem can deal with it". I might be wrong here but it always seemed to me that Rust was built to replace C/C++ in critical infrastructure like Firefox, Nginx, Redis, etc. Basically critical network dependent infrastructure. With respect (because I understand the difficulties that come with…

Well, and again, it doesn't implement the entire web platform, but Servo is already showing significant speed gains, even without AIO. It's really more useful for servers than clients.

It's important to remember that IO is truly a library concern in Rust. 1.0 means the language is stable, but there's still tons of libraries to build on top of that language. Holding back the language itself for a library that, while important, is only needed for certain applications wouldn't make a whole lot of sense.

Re: Things Rust shipped without

#213

Post by steveklabnik » Sat, Jul 04, 2015, 3:40 AM UTC

Jweb_Guru wrote: post #196

steveklabnik wrote: post #109

Earlier quoted context omitted.

https://github.com/pythonesque/fallthrough can emulate the fallthrough style if you really, really want to have it. It seems like it hasn't been updated in a while, though.

In the post-1.0 world, a repository not having been updated for a few months doesn't automatically mean it no longer works :P

That's true but January 11 is in that weird grey area...

Re: Things Rust shipped without

#214

Post by nbouscal » Sat, Jul 04, 2015, 3:42 AM UTC

carterehsmith wrote: post #173

pcwalton wrote: post #41

Earlier quoted context omitted.

Implicit returns encourage functional style; foo.map(|x| x + 1) is so much nicer than foo.map(|x| { return x + 1; }). Once you have implicit returns in closures, you might as well have them everywhere for consistency.

> foo.map(|x| x + 1) is so much nicer than foo.map(|x| { return x + 1; }) "Nicer" is a subjective thing. BTW in the trivial case above one may judge this or that to be nicer, but in a large method, 'return func(a,b,c)' is obvious, whereas looking at 'func(a,b,c)' it is super non-obvious that the value is being returned.

It's not at all non-obvious if you learn the language. It's also not non-obvious if you learn any of the myriad other languages with the same semantics (including popular web languages like Ruby and CoffeeScript).

Re: Things Rust shipped without

#215

Post by Jweb_Guru » Sat, Jul 04, 2015, 4:01 AM UTC

steveklabnik wrote: post #213

Jweb_Guru wrote: post #196

Earlier quoted context omitted.

In the post-1.0 world, a repository not having been updated for a few months doesn't automatically mean it no longer works :P

That's true but January 11 is in that weird grey area...

Let me be clearer: that repository works fine and doesn't rely on the standard library at all.

Re: Things Rust shipped without

#216

Post by geofft » Sat, Jul 04, 2015, 4:14 AM UTC

chjj wrote: post #143

IvyMike wrote: post #6

> goto (not even as a reserved word) I haven't done this for a while, but once upon a graduate program I wrote a compiler from a made-up-language (MUP) to C. MUP had some strange control structures, and if C did not have "goto", it would have been a lot more difficult to implement those structures. Since then, I have always thought languages should have a "goto" statement that human-written code is not allowed to use…

I've always defended goto and gotten a lot of flak for it. As soon as I say, "I wish I had X-language had gotos", I see jaws drop. Response: "Wow, haven't you heard the news?! GOTOs are considered harmful!" I think goto should be in almost every language. It's one of the most primitive instructions, why shouldn't it be available when needed? Yes, it can be misused, just like any other feature in the language , but it…

Rust is not a language that looks favorably on things that are easy to misuse and hard to use correctly. You can make the same argument about, say, untagged / C-style unions, which are much more common in C, but Rust doesn't have those either.

I don't plan to stop using ncurses in particular, but one of the reasons I am supportive of Rust is that I would like to stop using all C software sometime in my lifetime.

Re: Things Rust shipped without

#217

Post by asveikau » Sat, Jul 04, 2015, 4:24 AM UTC

gilgoomesh wrote: post #192

asveikau wrote: post #75

Earlier quoted context omitted.

> fixed-length (like UTF-32), Utf-32 is only fixed length if you don't care about diacritics, variation selectors, RTL languages, and others. Unicode is not one code point or one char/wchar/uint32 per glyph.

You've changed topic from code points to grapheme clusters. Rust's character/string support is strictly for code points (the documentation is fairly clear about the distinction). Few string libraries actually deal with grapheme clusters as the native underlying representation (Swift being a notable exception).

The broader point I'm making is that unicode is hard and attempts to simplify it by choosing a different encoding (i.e. switching to utf-32 to save yourself from all problems) are a bit misguided.

Re: Things Rust shipped without

#218

Post by geofft » Sat, Jul 04, 2015, 4:24 AM UTC

jlarocco wrote: post #194

I'm sorry, but I have a hard time being impressed by any of those. They're all just fixing things that were busted in C. I mean good for Rust, but C is a pretty low bar. Does any language created in the last 20 years make those same mistakes?

Rust is the first language that fixes all of these things, can be used as a replacement for all of C's use cases (including ABI-stable libraries, kernels, etc.), and has a sufficient community / mindshare that you can expect libraries to exist in the language for functionality that you generally expect to find in libraries.

Maybe we should be embarrassed as an industry that it took us 20 years to get there, yes.

Re: Things Rust shipped without

#219

Post by rspeer » Sat, Jul 04, 2015, 4:30 AM UTC

MrBuddyCasino wrote: post #83

steveklabnik wrote: post #29

Earlier quoted context omitted.

The first is bad because of UTF-8, basically. It's unclear what an index should even return: bytes, codepoints, grapheme clusters? Furthermore, because it's a variable-length encoding, it's not O(1) access, which is what [] implies, and since Rust tries to surface the cost of operations, it would be inappropriate for Rust. (Note that Rust _does_ have a ranged syntax here, which returns bytes, and is O(1)) Pre vs post…

Ok, thanks for the details, I suspected as much. My intuition says string indices should be accessible as grapheme clusters (and, additionally, codepoints), bytes are meaningless anyway. Whenever I want to cut and slice a string, I usually want it to be at the boundary of a letter. Yet most languages don't seem to do it this way, strangely enough.

Well, that's about efficiency.

If you want to be able to slice at grapheme boundary n, you have to iterate through the string counting up to n to find out where it is. Might as well just provide an iterator over graphemes in the first place.

You can optimize slicing on codepoint boundaries by storing strings internally in a fixed-width representation, like Python does. But now you have to convert encodings all the time just to use UTF-8 for your I/O. And that still only gets you codepoints.

It's not a great tradeoff to do it that way. It wastes memory and CPU time, and randomly accessing characters of strings is just not something you actually need to do often enough to optimize for it.

Re: Things Rust shipped without

#220

Post by gsg » Sat, Jul 04, 2015, 4:31 AM UTC

cwzwarich wrote: post #52

gsg wrote: post #39

Earlier quoted context omitted.

Yeah. Even basic things like building SSA can be done more simply on "structured" CFGs. The benefits are enough that data structure and algorithm designs in the JVM compiler world often take advantage of assuming reducible control flow even though Java bytecode can express irreducible CFGs. Instead, such programs are left to the interpreter.

Rust's CFGs are reducible with unbounded treewidth, not structured, because Rust has named exits from loops that nest arbitrarily. Most problems on reducible graphs are not easier than for general graphs, because you can always compute a loop forest (for generalized loops, not natural loops with a single entry point) and just consider a derived acyclic graph.

The structured SSA building algorithm I had in mind has a fairly simple extension that covers break, continue, and early return. It's more complicated, but still way simpler than iterated dominance frontiers.

> you can always compute a loop forest

It's easier to not have to.