Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things Rust shipped without

graydon2.dreamwidth.org

Post reply on HN
Print view View original

71–80 of 330 posts

Re: Things Rust shipped without

#71

Post by dragonwriter »

andresmanz wrote: post #53
88e282102ae2e5b wrote: post #38

Earlier quoted context omitted.

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.

That's what I mean. Why should I even care about stuff like this being "considered poor style" by the creators of Rust? "Poor style" is what doesn't work well for my team and me.

> Why should I even care about stuff like this being "considered poor style" by the creators of Rust?

Maybe you are writing code for the Rust standard library, where following the core projects style recommendations would be important for consistency.

Maybe you don't want to start from scratch coming up with your own style, and want a decent starting point from which you can vary as your team figures out what does/doesn't work for them.

Lots of reasons to have a language project also provide default style recommendations.

Re: Things Rust shipped without

#72

Post by steveklabnik »

riquito wrote: post #66
andrepd wrote: post #12

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

Tail call optimization https://mail.mozilla.org/pipermail/rust-dev/2013-April/00355... https://github.com/rust-lang/rust/issues/217 > I'm sorry to be saying all this, and it is with a heavy heart, but we tried and did not find a way to make the tradeoffs associated with them sum up to an argument for inclusion in rust. > -Graydon

Note that a lot has changed since April of 2013. Rust does have TCO, we just can't guarantee it. And, LLVM has come a long way, so we probably can support guaranteed TCO now, and have 'become' as a reserved keyword for this purpose.

https://github.com/rust-lang/rfcs/issues/271 is a better link today.

Re: Things Rust shipped without

#75

Post by asveikau »

Skalman wrote: post #59
yurish wrote: post #58

What is wrong with UTF-16 support?

It's an encoding that isn't good at anything: it's neither ASCII-compatible (like UTF-8), nor fixed-length (like UTF-32), but because most characters require only 2 bytes, developers frequently assume that none require more, leading to bugs when a character eventually is represented by 4 bytes.

> 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.

Re: Things Rust shipped without

#76

Post by frivoal »

api wrote: post #70
frivoal wrote: post #68

Earlier quoted context omitted.

A bitecode interpreter is another place where it's nice to have gotos. Here's the base code without gotos: typedef enum { ADD, MUL, ..., END } opcode; void run() { opcode ins; while (1) { ins = fetch_next_inst(); switch (ins) { case ADD: perform_addition(); break; case MUL: perform_multiplication(); break; ... case END: wrap_up(); return; } } } You have 3 jumps on each loop. From the break to the end of the loop, the…

That's pretty nifty, but it seems like something a really good compiler could achieve automatically. Of course I'm not sure if any compilers actually are that good.

This is a fairly mechanical conversion, so suppose a sufficiently smart compiler could do that.

But assuming a sufficiently smart compiler when you depend on your code being fast tends to cause issues. Especially if you expect it to run on a bunch of platforms with compilers of varying qualities. Last time I saw code last this, we certainly couldn't rely on compilers being particularly smart, and we did care about speed.

Re: Things Rust shipped without

#77

Post by steveklabnik »

yurish wrote: post #64
Skalman wrote: post #59

Earlier quoted context omitted.

It's an encoding that isn't good at anything: it's neither ASCII-compatible (like UTF-8), nor fixed-length (like UTF-32), but because most characters require only 2 bytes, developers frequently assume that none require more, leading to bugs when a character eventually is represented by 4 bytes.

I don't know much about Rust and Rust library, so I have a question: what if I what to develop Windows only software in Rust, will I need to convert back and forth between UTF-16 and UTF-8 (or whatever Rust uses in other parts of the library)?

We have an http://doc.rust-lang.org/stable/std/ffi/struct.OsString.html to abstract over a native string in whatever encoding your platform has. Generally, things that interact with the OS use these, and they can convert to a UTF-8 String.

Re: Things Rust shipped without

#78

Post by acdha »

yurish wrote: post #64
Skalman wrote: post #59

Earlier quoted context omitted.

It's an encoding that isn't good at anything: it's neither ASCII-compatible (like UTF-8), nor fixed-length (like UTF-32), but because most characters require only 2 bytes, developers frequently assume that none require more, leading to bugs when a character eventually is represented by 4 bytes.

I don't know much about Rust and Rust library, so I have a question: what if I what to develop Windows only software in Rust, will I need to convert back and forth between UTF-16 and UTF-8 (or whatever Rust uses in other parts of the library)?

Since the full bullet point was “UTF-16 or UCS-2 support anywhere outside windows API compatibility routines” I'm assuming you'd get UTF-8 out of any high-level interface.

Re: Things Rust shipped without

#79

Post by comex »

steveklabnik wrote: post #29
MrBuddyCasino wrote: post #24

I don't get why those are bad? - random-access strings - auto-increment operators

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…

Just as additional context, since this seems to come up a lot - that does not mean that UTF-8 is bad. The main alternative is UTF-32, which provides random access to codepoints rather than bytes, but since Unicode graphemes consist of multiple codepoints, UTF-32 is effectively a variable width encoding as well for most purposes, just one that uses much more memory than UTF-8 most of the time and never uses less.

Re: Things Rust shipped without

#80

Post by steveklabnik »

comex wrote: post #79
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…

Just as additional context, since this seems to come up a lot - that does not mean that UTF-8 is bad. The main alternative is UTF-32, which provides random access to codepoints rather than bytes, but since Unicode graphemes consist of multiple codepoints, UTF-32 is effectively a variable width encoding as well for most purposes, just one that uses much more memory than UTF-8 most of the time and never uses less.

Oh yeah, I don't think any of this makes UTF-8 bad, in fact, I think it's the best choice.

It just reveals the inherent complexity in handling string data.

Post reply on HN