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

91–100 of 330 posts

Re: Things Rust shipped without

#91

Post by Maken »

haberman wrote: post #69
pcwalton wrote: post #8

Earlier quoted context omitted.

It often simplifies a lot of the compiler implementation if you only have reducible control flow. LLVM is fine with irreducible control flow, because it has to handle C, but rustc uses a CFG for the borrow checker, which is flow-sensitive. You can convert irreducible control flow to reducible control flow, but it can explode the size of the graph in pathological cases. (I don't recall whether the borrow checker actua…

At least reserve the word, in case you change your mind in the future? I guess it's too late now...

Burn the boats and never look back, I guess.

Re: Things Rust shipped without

#92

Post by frivoal »

zem wrote: post #90
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…

~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 :)

And they say C is a simple language... :)

To be fair, I've seen code like this exactly once.

Re: Things Rust shipped without

#93

Post by arcticbull »

merlincorey wrote: post #74

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

Generally doing anything crafty like this in real-world or production code is just going to cause the next guy who shows up to be very, very confused. Loop unrolling optimizations and the like should really be left to the compiler.

If you're truly sure you're better than the compiler, I'd imagine an assembly language implementation would be easier to understand than nested switch/while fall through madness.

That said. There's an implementation of Duff's device in the Wikipedia entry which (IMO is much easier to understand and maintain) that doesn't use fall-through that should be just fine to write in Rust.

https://en.wikipedia.org/wiki/Duff's_device

Re: Things Rust shipped without

#94

Post by ericsink »

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.

I like the warnings about style and naming conventions. I kinda wish there were more of them. These warnings can help teams avoid arguments about things that don't really matter very much.

Re: Things Rust shipped without

#95

Post by arielby »

Sir_Cmpwn wrote: post #40
pcwalton wrote: post #27

Earlier quoted context omitted.

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

The PoC did this: mod foo { #include "..." } Which is barely enough to say that Rust is hugely different than just #include-ing C files. I was talking more about linking objects incrementally and the consequences of that design, rather than singing the praises of headers (though I do rather like headers). I understand C from the compiler's perspective as well, having written my own linker and assembler from scratch m…

This is Rust's approach to splitting a crate between files - not for splitting to different isolated separately-compiled modules. I must say it works great for that purpose, being much better than dealing with build tools.

Re: Things Rust shipped without

#97

Post by berkut »

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.

Yeah, that's one thing that's really putting me off looking at Rust - the possibility of it enforcing style in the future.

Hanging braces style for C/C++ is rarely allowed in the coding standards I've had to use in the past for embedded and real-time stuff in the defence industry, because it can be a source of errors.

Aligned opening and closing braces are much more common (in line with ADA's style).

Re: Things Rust shipped without

#98

Post by banthar »

zem wrote: post #90
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…

~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 :)

You can't. This is a GCC extension:

https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Re: Things Rust shipped without

#99

Post by steveklabnik »

15155 wrote: post #96

How about stdlib-blessed async IO? Or even async/await keywords (simple CPS transformation) a la C#?

Well, it did, but these are things that are good _not_ to have, not things that would be nice to have.

If those are things you do want to have, well, we didn't have a design for AIO that we were happy yet, as even the most advanced Rust library, mio, is still a work in progress. https://github.com/rust-lang/rfcs/issues/1081

As for async/await, https://github.com/rust-lang/rfcs/issues/388

Re: Things Rust shipped without

#100

Post by nrc »

berkut wrote: post #97
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.

Yeah, that's one thing that's really putting me off looking at Rust - the possibility of it enforcing style in the future. Hanging braces style for C/C++ is rarely allowed in the coding standards I've had to use in the past for embedded and real-time stuff in the defence industry, because it can be a source of errors. Aligned opening and closing braces are much more common (in line with ADA's style).

The compiler will not enforce more style in the future, that will be done by Rustfmt, a separate and optional tool. In fact, it is likely that the compiler lints which enforce style will move out of the compiler and in to Rustfmt at some point in the future.
Post reply on HN