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

21–30 of 330 posts

Re: Things Rust shipped without

#21

Post by kzrdude »

_wmd wrote: post #11
kerny wrote: post #9

Earlier quoted context omitted.

No undefined behavior. Perfectly legal since C99 standard.

Can we please get a quote on this one. If reinterpreting memory via a union is valid in C99, including data vs function pointers, then so would reinterpreting that memory via a cast, which would seem to violate one of the most elementary aspects of the standard (e.g. such a rule would be difficult or impossible to implement on a Harvard architecture machine, which the standard previously made plenty of allowance for)

Page 83, section §6.5.2.3 of the C11 standard, footnote 95) says

> If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called ‘‘type punning’’). This might be a trap representation

Re: Things Rust shipped without

#22

Post by pcwalton »

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.

This is the first I've heard complaints that Rust is too strict with formatting. If anything, the popularity of gofmt (which is far more opinionated than rustc's default warnings are!) is a testament to the fact that people want languages to be ruthlessly opinionated regarding style these days.

Re: Things Rust shipped without

#23

Post by [deleted] »

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.

[deleted]

Re: Things Rust shipped without

#25

Post by Sir_Cmpwn »

pcwalton wrote: post #19
Sir_Cmpwn wrote: post #17

Earlier quoted context omitted.

Incremental compilation and a non-braindead module system. Breaking changes will be required to fix both, which is why Rust was released too early if you ask me.

Why does incremental compilation require a breaking change? We just sketched a fully compatible design for it last week. I'd also question why the module system is "braindead", of course.

I haven't looked at Rust since I came to these conclusions a few months ago, so add a grain of salt.

I don't recall why incremental compilation requires a breaking change, maybe it doesn't. I shouldn't have looped it into that statement without being certain.

The module system _is_ braindead, though. Last time I brought this up, I made a proof of concept that compiled the exact same program two ways - one by using the module system, and one by running the code through the C preprocessor and literally #include-ing other rust files. The purpose of this PoC was to point out that Rust modules are functionally identical to #include-ing C files would be in C, which is a well known antipattern.

Rust is very close to C when you consider the guts of the toolchain. C has solved several problems with respect to linking and I feel like Rust could have taken several more hints from C. This is probably a consequence of the Rust devs inherently disliking C and wanting to distance themselves from it.

Re: Things Rust shipped without

#26

Post by sunfish »

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 wish C/C++ had a labeled break construct, like JavaScript, Java, Rust, and other languages have. It's surprisingly powerful, while still remaining structured. I personally have enjoyed learning about it, and about just how rarely an actual goto is really needed.

Re: Things Rust shipped without

#27

Post by pcwalton »

Sir_Cmpwn wrote: post #25
pcwalton wrote: post #19

Earlier quoted context omitted.

Why does incremental compilation require a breaking change? We just sketched a fully compatible design for it last week. I'd also question why the module system is "braindead", of course.

I haven't looked at Rust since I came to these conclusions a few months ago, so add a grain of salt. I don't recall why incremental compilation requires a breaking change, maybe it doesn't. I shouldn't have looped it into that statement without being certain. The module system _is_ braindead, though. Last time I brought this up, I made a proof of concept that compiled the exact same program two ways - one by using th…

> The purpose of this PoC was to point out that Rust modules are functionally identical to #include-ing C files would be in C, which is a well known antipattern.

But they trivially aren't.

    lib.rs:
        mod foo;
        mod bar;
    foo.rs:
        fn f() {}
    bar.rs:
        fn f() {}
No name conflict. foo::f and bar::f happily coexist.

In C:

    lib.c:
        #include "foo.c"
        #include "bar.c"
    foo.c:
        void f() {}
    bar.c:
        void f() {}
Name conflict; fails to compile.

> Rust is very close to C when you consider the guts of the toolchain. C has solved several problems with respect to linking and I feel like Rust could have taken several more hints from C. This is probably a consequence of the Rust devs inherently disliking C and wanting to distance themselves from it.

No, it's that header files are are a big problem in C (DRY violation, hostile to code inlining, slow compilation) and it was felt that a real module system would be an improvement.

Re: Things Rust shipped without

#28

Post by jpgvm »

moonchrome wrote: post #20
jpgvm wrote: post #14

Earlier quoted context omitted.

That concerns us less. Rust ships again every 6 weeks.

They do have a constraint of not being able to break backwards compatibility between releases.

This is true. I guess you could say it shipped and is still shipping with many unstable APIs because they so cautious about shipping things they can't take back.

I don't see that as a bad thing though, it's not great if you are trying to write Rust programs/libraries -right- now as sometimes you will have to jump through some hoops to only use stable Rust APIs but it will be worth it in the long term.

Re: Things Rust shipped without

#29

Post by steveklabnik »

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 increment just leads to a lot of confusion, and doesn't give you much over `x += 1`, in my opinion. Not sure what Graydon's reasoning is here.

Re: Things Rust shipped without

#30

Post by kzrdude »

sinistersnare wrote: post #13
kerny wrote: post #10

Earlier quoted context omitted.

> Except... it's undefined behavior. No longer true since C99.

Source please? Or do I need money to get a copy of the standard?

Get publicly available draft 1570 of the C11 standard from the committee: http://www.open-std.org/jtc1/sc22/wg14/www/standards.html
Post reply on HN