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

Rust's language ergonomics initiative

blog.rust-lang.org

Post reply on HN
Print view View original

131–140 of 295 posts

Re: Rust's language ergonomics initiative

#131

Post by tatterdemalion »

CalChris wrote: post #48
steveklabnik wrote: post #33

Earlier quoted context omitted.

I don't understand what this means. You'd use const in Rust for this, not a macro.

That was just a trivial example. Yes, you could use a const which would be difficult to share across files. Moreover, if you wanted to do something equally textual #define PASS_VERBOSE if (flag_verbose && first_pass) printf you just might be able to but only with a completely different tool. A macro processor is not of the language; it is above the language.

You want textual macros. Rust doesn't have this feature, it has a syntactic macro feature inspired by the Lisp family. Sorry.

Re: Rust's language ergonomics initiative

#132

Post by Manishearth »

saosebastiao wrote: post #129
Manishearth wrote: post #116

Earlier quoted context omitted.

Traits are closer to interfaces than abstract classes, iirc abstract classes can have fields.

I've noticed this and while I don't use it much it has caught me off guard once or twice. And while it wasn't the end of the world, I wasn't too fond of the solutions I came up with. Is there a reason why they can't have fields? Why wouldn't they just be an "extension" to a struct/enum, modifying their memory representation?

Rust doesn't do single inheritance, basically.

If they had fields, what would you do when you implemented two of them on a struct? It also muddles up the ability to tack on traits in later crates.

Traits aren't supposed to be used the way you do single inheritance. Rust prefers composition over inheritance, so you combine structs and enums to get what you want there.

Re: Rust's language ergonomics initiative

#133

Post by tatterdemalion »

lobster_johnson wrote: post #109
robohamburger wrote: post #5

"Idea: implied bounds" sounds like a very interesting idea. It is a pain copying the bounds as author mentions. I also have worked with library code that does not consistently use trait bounds and it can lead to very confusing errors. The thing that keeps getting me now is there are so many types moving around with generics and traits. It would be nice if it were easier for something to be object safe and/or Any was…

I was surprised that Rust actually did it the way it is now (i.e. no implicit bounds). Article says accessing the map arg's methods will fail, but isn't the entire argument itself invalid by definition? You can't instantiate the hash map without validating that K and V do implement those traits.

In the standard library today, there's no bounds on `K` on the definition of HashMap, only on the impl block containing its methods. This sort of makes HashMap a bad example for this code block; you're right that if the bounds were on the definition instead of the impl, the argument itself would be invalid.

Re: Rust's language ergonomics initiative

#134

Post by stagger87 »

pklausler wrote: post #124
stagger87 wrote: post #122

Earlier quoted context omitted.

The code below works for me #define PI1 3.141592653589793115997963468544185161590576171875 double pi1 = PI1; #define PI2 3.14159265358979323846264338327950288 double pi2 = PI2; assert(pi1 == pi2); (edit: or even 3.14159265358979323846)

Your PI2 rounds to PI1 under the rounding mode used at compilation time. Print it out with "%50.48f" (or FORMAT(F50.48)) and you'll see PI1. But PI1 is independent of rounding mode.

Sure. I thought you were implying more than that. When you called it a bug I thought you were implying that the use of one over another would alter the output of a program. My bad.

Re: Rust's language ergonomics initiative

#135

Post by dogamak »

Animats wrote: post #91
dogamak wrote: post #56

Earlier quoted context omitted.

Macros and the importing and scoping of them is a mess in rust right now and major rewrite of the macro system is underway. Currently crates have no way to re-export macros from other crates and #[use_macros] brings all macros in the imported crate to the local crate's namespace as-is (no way to prevent possible naming conflicts)

major rewrite of the ... is underway. That's a common response to criticisms of Rust. At this late date, that's a problem.

I agree, the macro scoping is just a small part of the rewrite but it is a problem (especially ergonomically) that rust should have got right the first time around.

Right now macros don't quite feel like they are part of the core language, but instead a hack or plugin slapped haphazardly on top of the compiler.

Re: Rust's language ergonomics initiative

#136

Post by falcor84 »

AsyncAwait wrote: post #128
modeless wrote: post #15

Are there plans to do user studies? 10 minutes watching new users code in Rust will give you better ideas than 10 weeks thinking about the problem in your head. I feel like there's a real lack of user testing in software development tools land. If you're developing software for unsophisticated users it's obvious that you should be doing user testing, but it's an often ignored fact that developers are users too! APIs,…

> 10 minutes watching new users code in Rust will give you better ideas than 10 weeks thinking about the problem in your head. I am not sure whether 10 minutes of Rust would give you actionable info, I mean it certainly takes longer to get familiar with the basics in almost any language, even if the 10 minutes just stands for a short amount of time .

I assumed "new users" implied relatively new users (before they grew to love the language enough to accept the downsides), not absolute beginners

Re: Rust's language ergonomics initiative

#137

Post by StephenAshmore »

I've been writing Rust quite frequently recently, and have enjoyed it. However, the biggest problem I've faced so far is exactly what they are trying to address. Modules can be annoying, and I wouldn't mind better optional parameters or a better way to box up trait objects.

Re: Rust's language ergonomics initiative

#138

Post by dogamak »

yarper wrote: post #125

After writing Rust in production for a while, the biggest bugbear I have is the naming/file structure. I end up a lot with this; src/main.rs src/combobulator/mod.rs src/combobulator/tests.rs src/tests.rs src/somethingelse/tests.rs src/somethingelse/mod.rs Because I find tests in the same file a bit confusing. It's really easy with maven-style layouts to know that "only things in main/java or main/scala get compiled a…

Additionally tests in "tests/" are compiled to independent binaries on which the test suite is run on separately, which results into verbose and redundant output when ran.

Also if you keep your tests under "src/", you can't just stick them wherever you want; you need to have #[cfg(tests)] on every module declaration leading to the test function, otherwise the test is ignored silently. From time to time I find old tests that have not ran once because of a missing attribute somewhere upwards the module hierarchy.

Re: Rust's language ergonomics initiative

#139

Post by MaulingMonkey »

steveklabnik wrote: post #93
deegles wrote: post #83

Earlier quoted context omitted.

How about opt-out on nightly builds and opt-in on production?

I don't personally think opt-out is ever acceptable for this kind of thing.

Yeah, I'd really prefer not to have to remember to opt out of accidentally violating my NDA when working on closed source projects.

Re: Rust's language ergonomics initiative

#140

Post by robohamburger »

steveklabnik wrote: post #6
robohamburger wrote: post #5

"Idea: implied bounds" sounds like a very interesting idea. It is a pain copying the bounds as author mentions. I also have worked with library code that does not consistently use trait bounds and it can lead to very confusing errors. The thing that keeps getting me now is there are so many types moving around with generics and traits. It would be nice if it were easier for something to be object safe and/or Any was…

> Any was more powerful https://github.com/rust-lang/rfcs/pull/1849 is relevant to your interests; however, as the comments say there, associated type constructors would be needed before it could possibly be used with Any.

Yeah it seems like you would need some kind of guard to make sure you don't violate any of the lifetimes that could be tucked away. Still good work!

I guess compiler plugins and libraries will eventually fill in the gaps, until then I guess I just have to be creative :)

Post reply on HN