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

41–50 of 330 posts

Re: Things Rust shipped without

#41

Post by pcwalton »

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.

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.

Re: Things Rust shipped without

#42

Post by SamReidHughes »

MrBuddyCasino wrote: post #24

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

Go has increment operators, but they have to be in their own statements, you can't intermingle them in an expression. The reason is, putting them in the same line as other stuff makes for a higher chance of bugs. For example, Tarsnap's CTR bug happened because of this. The removal of a nonce increment would have been very obvious if all increments had to be on a separate line, either by language fiat or properly risk-averse C coding practices.

Re: Things Rust shipped without

#43

Post by pcwalton »

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…

> Which is barely enough to say that Rust is hugely different than just #include-ing C files.

Well, sure, if you want to get fancy enough you can make a module system out of #include. (Your code snippet isn't enough because it doesn't replicate privacy or imports.) But replicating something approximating Rust's module system with "#include plus other stuff" doesn't show that Rust's module system is "just #include".

> That's objectively untrue. It's much faster to compile with something like headers.

I don't think that's true once you have the proper incremental build setup. With headers, you have to parse large source files over and over again. With a proper module system, the compiler can use a more efficient binary database format (with an index).

For example, consider math.h. If your program is using one function (say, sin) from math.h, you have to parse all the prototypes in math.h. (And if you have inlined functions or templates in the header files, you have to parse those too!) But with a module system, the compiler can serialize an index of all the signatures of functions inside libmath.so, so the compiler can do a direct, O(1) hash table lookup for "sin".

We aren't there today, of course, since we don't have incremental compilation, and C is certainly simpler, but I think doing it right from the start will pay dividends down the road.

> As far as inlining and DRY are concerned, back before Rust shipped I spoke with many Rust maintainers about solutions to all of these problems, but it was dismissed because "we're trying to ship". Maybe you shouldn't sail a boat when you need to replace the hull later?

I don't see anything backwards-incompatible about incremental compilation, and I believe where we're going will end up better than header files when all is said and done.

Re: Things Rust shipped without

#44

Post by nightpool »

andresmanz wrote: post #32
pcwalton wrote: post #22

Earlier quoted context omitted.

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.

That's absolutely OK and I do understand that people want that. I actually like snake case and only slightly prefer camel case. I'd write snake case in large open source projects, if it's actually preferred. But it's very awful to type snake case code on my keyboard and I'm not ready yet to switch to a US keyboard. The worst thing about that warning is that I get some kind of a bad conscience by disabling it.

have you thought about binding underscores to some other key combination at the operating system level?

Re: Things Rust shipped without

#45

Post by shawkinaw »

andresmanz wrote: post #32
pcwalton wrote: post #22

Earlier quoted context omitted.

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.

That's absolutely OK and I do understand that people want that. I actually like snake case and only slightly prefer camel case. I'd write snake case in large open source projects, if it's actually preferred. But it's very awful to type snake case code on my keyboard and I'm not ready yet to switch to a US keyboard. The worst thing about that warning is that I get some kind of a bad conscience by disabling it.

Even on a US keyboard snake case is annoying to type (for me at least.)

Re: Things Rust shipped without

#47

Post by madez »

pcwalton wrote: post #22
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.

It's so much better to let the computer worry about formatting such that the programmer can worry about the logic.

fmt-tools offer the amazing possibility that one programmer writes and reads the same code with different formatting than another programmer. I'd love to be able to set my formatting in my editor so that I see it how it's best for me but on saving or sharing code the formatting is reverted to the standard.

So, I think there should be a default style for rustfmt, but also support for other styles.

Re: Things Rust shipped without

#48

Post by tatterdemalion »

madez wrote: post #47
pcwalton wrote: post #22

Earlier quoted context omitted.

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.

It's so much better to let the computer worry about formatting such that the programmer can worry about the logic. fmt-tools offer the amazing possibility that one programmer writes and reads the same code with different formatting than another programmer. I'd love to be able to set my formatting in my editor so that I see it how it's best for me but on saving or sharing code the formatting is reverted to the standar…

rustfmt (currently in development) follows this principle.

Re: Things Rust shipped without

#49

Post by cwzwarich »

pcwalton wrote: post #8
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…

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…

Non-lexical lifetimes don't depend on reducibility. The RFC I wrote works fine for irreducible CFGs:

https://github.com/rust-lang/rfcs/pull/396

It does have the effect of picking a single dominating entry point for a loop with multiple entry points, but if you want a single-entry region that's necessarily true. Multiple-entry regions are probably possible, but they could be counterintuitive and produce even stranger error messages than the current region system.

The borrow checker is based on dataflow analyses that should work on arbitrary CFGs, assuming an appropriately generalized notion of region.

Re: Things Rust shipped without

#50

Post by jasode »

api wrote: post #33
sunfish wrote: post #26

Earlier quoted context omitted.

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.

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…

>In C++ labeled breaks would make 'goto' completely obsolete.

In 20 years of using C/C++, I've found one use for "goto" that's hard to substitute: simulating coroutines that yield to an outer context. (Similar to C# yield return).

A "break label" gets you out of a loop. I needed to use "goto" to jump back into the middle of a loop to resume where the "coroutine" previously left off. The keywords "break/setjmp/longjmp" wouldn't have been substitutes for this particular use case.

Post reply on HN