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

81–90 of 330 posts

Re: Things Rust shipped without

#81

Post by tatterdemalion »

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)?

Yes.

The Rust std library had to pick a string encoding, and it picked UTF-8 (which is really the best Unicode encoding). The String type is platform neutral and always UTF-8.

However, it does provide an OsString type, which on windows is UTF-16. Maybe there is a library - and if not, one could be written - targeting Windows only, and implementing stronger UTF-16 string processing on the OsString type.

EDIT: To be clear, Rust's trait system makes this very easy to do. You just define all the methods you want OsString to have in a trait WindowsString, and implement it for OsString, even though OsString is a std library type. One of the great things about Rust is that its trivial to use the std library as shared "pivot" which various third party libraries extend according to your use case.

Re: Things Rust shipped without

#82

Post by lmm »

88e282102ae2e5b wrote: post #62
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.

Why "might as well"? Things can be optimal in some places and suboptimal elsewhere.

Consistency is valuable. If some blocks have different rules to other blocks that's a real downside.

Re: Things Rust shipped without

#83

Post by MrBuddyCasino »

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…

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.

Re: Things Rust shipped without

#84

Post by steveklabnik »

merlincorey wrote: post #74

How does one accomplish loop-unrolling as in Duff's Device in rust, if case statements do not fall through?

Well, you generally don't, because Duff's Device isn't generally regarded as a good idea anymore, in my understanding:

  > It turns out that with branch predictions and the relative speed of CPU
  > vs. memory changing over the past decade, loop unrolling is pretty much
  > pointless.
http://lkml.iu.edu/hypermail/linux/kernel/0008.2/0171.html

Re: Things Rust shipped without

#85

Post by jcranmer »

merlincorey wrote: post #74

How does one accomplish loop-unrolling as in Duff's Device in rust, if case statements do not fall through?

Duff's Device is now considered an anti-pattern... X found their code speed actually improved when they dropped it. " rel="nofollow">http://lkml.iu.edu/hypermail/linux/kernel/0008.2/0171.html>.

Re: Things Rust shipped without

#86

Post by SomeCallMeTim »

pcwalton wrote: post #3
ajkjk wrote: post #2

What does "unions that allow access to the wrong field" mean?

union foo { int x; float y; }; union foo bad; bad.x = 100; printf("%f\n", bad.y); // undefined behavior (though usually works)

Which is actually a useful feature in some obscure optimizations, like this fast (approximate) square root:

		float half_r=r*0.5F;

		union
		{
			float y;
			int32_t i;
		};

		y=r;
		i=0x5f375a86-(i>>1);
		y=y*(1.5F-(half_r*y*y));
		return y;

Re: Things Rust shipped without

#87

Post by bluecalm »

Animats wrote: post #51
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 don't think I've written a goto since the 1970s, and I've written a lot of code since then. If you need to bail out of something in the middle, make it a function.

As mentioned above, in C goto is often useful for error handling (where you need to free some resources before exiting the function). It's way more convenient and readable to write freeing code once and jump to it instead of having multiple return exits and duplicate the code before every single one of them.

Re: Things Rust shipped without

#88

Post by andresmanz »

dragonwriter wrote: post #71
andresmanz wrote: post #53

Earlier quoted context omitted.

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/do…

Style recommendations are great and if I was writing code for the standard library, I would certainly follow them. But they don't simply recommend their style. "We recommend doing this like that" is very different from "Doing this that way is considered poor style". That sounds like their recommendations were objective facts and you shouldn't do anything else, even if that worked better for you and the majority of other programmers.

Re: Things Rust shipped without

#90

Post by zem »

frivoal wrote: post #68
api wrote: post #33

Earlier quoted context omitted.

I've never had to use 'goto' in C++ except to break from a nested loop. In C++ labeled breaks would make 'goto' completely obsolete. In C it would still have use in the implementation of orderly error handling -- the pattern where you hand-implement exception handling in C by putting an on_error: label at the end of the function that is goto'd on error. The addition of some orderly construct for this in C would elimi…

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…

~20 years of using various combinations of C and C++, and i never knew you could take the address of a label! reminds me of computed GOSUBs from my basic days :)
Post reply on HN