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

Rust 1.24

blog.rust-lang.org

Post reply on HN
Print view View original

171–180 of 215 posts

Re: Rust 1.24

#171

Post by kod »

akmittal wrote: post #119
kzrdude wrote: post #34

Earlier quoted context omitted.

When I use Python I miss Rust's enums, the pattern matching of those enums, and the static types that help refactoring (the compiler spots where one change has knock-on effects in the rest of the project..). Especially how Rust enums and structs make it easy to define new types to guide your programs are a highlight for me. I don't think Rust is better than Python for every task. Python is a lot simpler if you can ge…

Go is good middle ground between simplicity and being fast/dynamic.

Walk middle, sooner or later get the squish just like grape.

Re: Rust 1.24

#172

Post by themihai »

steveklabnik wrote: post #168
themihai wrote: post #143

Earlier quoted context omitted.

Yeah, I guess that's the Rust way. The more options/configurations the better! Simplicity is not on the top list for sure.

We have a strong culture of convention over configuration; these two things are not inherently at odds. To get the default formatting with rustfmt, you just run it. You can configure it via some file but I've never needed to. I don't even know what the options are.

Ok so what happens if I contribute to a open source project with my default fmt configuration if that project doesn't use the default configuration? Will people yell at me to "fix" the formatting?

Re: Rust 1.24

#173

Post by geofft »

civility wrote: post #112
nine_k wrote: post #105

Earlier quoted context omitted.

Java without generics used to compile pretty fast. When you add generics, lifetimes, and type inference, the amount of work the compiler does grows significantly. It allows to check much more interesting invariants, leading to the "if it compiles, it runs correctly" effect.

Below, steveklabnik claims these things are miniscule. Are you really sure you know what is actually slow?

If you're referring to the comment starting with "It's not a big-O thing," I think that comment says the opposite. "Generics, lifetimes, and type inference" aren't "static checks and optimization passes" (within rustc)—he says the bulk of the work is LLVM dealing with the quantity of IR rustc generates, which is exactly what you'd expect from having heavy source-level abstractions like generics and type-heavy patterns like libstd's approach to iterators that all need to be compiled out.

Re: Rust 1.24

#174

Post by Q6T46nT668w6i3m »

pcwalton wrote: post #75
civility wrote: post #72

Earlier quoted context omitted.

> Incremental compilation! Is there some algorithm in Rust which has a necessary big-O? There were compilers in the 90s which ran a million lines per second (on much slower computers). Incremental compilation feels like working around the problem rather than solving it, and I have to imagine the complexity and maintenance is much worse. I'm sure some of the LLVM optimization passes are expensive, but those are used i…

> There were compilers in the 90s which ran a million lines per second (on much slower computers). Those compilers performed nowhere near the level of optimization that modern compilers do. > I'm sure some of the LLVM optimization passes are expensive, but those are used in clang++ too, and it's not terribly slow. clang++ is sure slow if it has to rebuild an entire codebase from scratch. The main reason that C++ comp…

clang++ is slow, but it certainly feels faster compared to rustc (and I typically use the write everything in one include C++ style). I’m curious, has there been any outreach to the clang community about rustc performance issues?

Re: Rust 1.24

#175

Post by dthul »

dingo_bat wrote: post #165
talson wrote: post #15

Can someone sell me on using rust over python? I am just gernerally curious as to the advantage beyond rust being compiled.

Instead of learning weird new stuff like rust or go, I find that c/c++ and python cover the entire range of problems you will ever need to solve. It takes a lot of time to start being productive in rust/go, and the benefits are vague. Instead I'd rather learn to use C++ and python better.

Learning weird new stuff can have a positive impact even though you don't end up using it as your workhorse though.

After coding in Rust for several weeks I went back to C++ for my day-to-day work since I'm still more productive with it and the code I produce has no safety/security implications. The knowledge gained in those few weeks of Rust readily translated into C++ skill improvements, even though I already considered myself a solid C++ programmer before. Being forced to think about ownership, borrowing, move semantics, etc. constantly gets you into a mindset that is very helpful also outside of Rust.

Re: Rust 1.24

#176

Post by chrismorgan »

oconnor663 wrote: post #98
talson wrote: post #15

Can someone sell me on using rust over python? I am just gernerally curious as to the advantage beyond rust being compiled.

Just my favorite single reason: I love ownership. I love knowing what a function is going to do with the HashMap/dictionary I pass into it. I love knowing when I'm the only piece of code that can touch something. Sure, there are benefits in terms of not needing a GC too, but I just love how clear it makes everything.

Yeah, I vacillate between judging algebraic data types and ownership as the thing I like most about Rust over other languages (formerly Python, but I do much more JavaScript now), but I think ownership wins most of the time. Strong ownership protects from vast swathes of really annoying bugs that are unpleasantly easy to unknowingly inject and particularly hard to track down. Certainly I believe that Rust’s strong ownership model is the defining feature of the language—most of the language’s features come about as a consequence of it (though this dominance has slowly been diminishing since 1.0).

Re: Rust 1.24

#177

Post by dullgiulio »

pcwalton wrote: post #78
dsymonds wrote: post #70

Good to see rustfmt arrive. Sad that it is configurable, though. The biggest benefit of its predecessors such as gofmt is that they are not configurable, leading to a much more uniform formatting style and avoiding endless discussions about whitespace layout.

If rustfmt were not configurable, it would get a lot less use. Rust has been around for quite some time now, and there's a lot of code out there. We can't force anybody to run rustfmt, and if they don't like the results, they won't use it. It's not a choice between different code styles and a single code style; it's a choice between different code styles with a tool to keep things tidy and different code styles with…

gofmt choice of not breaking lines is due to the fact that new lines in Go mean an implicit semicolon unless there is a comma or another continuation.

To break lines, the formatter would have to refactor code, which is not desiderable.

Re: Rust 1.24

#178

Post by steveklabnik »

themihai wrote: post #172
steveklabnik wrote: post #168

Earlier quoted context omitted.

We have a strong culture of convention over configuration; these two things are not inherently at odds. To get the default formatting with rustfmt, you just run it. You can configure it via some file but I've never needed to. I don't even know what the options are.

Ok so what happens if I contribute to a open source project with my default fmt configuration if that project doesn't use the default configuration? Will people yell at me to "fix" the formatting?

That'd depend on the project, but even then, you'd just run `cargo fmt` and be done with it. That project would have a rustfmt.toml in the repo, so it would just make the changes for you.

Re: Rust 1.24

#179

Post by zbentley »

yazaddaruvala wrote: post #61
AceJohnny2 wrote: post #47

Earlier quoted context omitted.

What would be the benefit of this approach over using the filesystem?

Any time you put data onto the file system there is overhead (eg. Memcache, Redis, most databases). Simple things like parsing the bytes into the binary representation go away. You can have more granularity of the cache because you don't need to worry about creating too many files. Not only from a performance perspective but also from a code perspective. More nuanced things like cache locality can be improved with an…

The shortest path to something like that (assuming it's a good idea) would probably not be writing an in-memory incremental compile state server, but storing intermediate artifacts as very cheap-to-serialize files (flatpak or just mmap and a cast), and then storing the files on /dev/shm or some other memory filesystem. That would give you most of the benefits you discussed (unless you clear out the cache/restart the machine) without requiring a huge rewrite of how state is stored.

Most of the assumptions I'm making here are unverified, though, so take it with a large grain of salt.

Re: Rust 1.24

#180

Post by zbentley »

RX14 wrote: post #151
ComputerGuru wrote: post #142

Earlier quoted context omitted.

Ugh. Every time I see tokio or futures-rs mentioned, a part of me dies. The syntax and ergonomics of rust futures ATM is insanely painful and slows down development 100x in some cases (not exaggerating) due to the current lack of async/await combined with hard typing requirements coupled with some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has…

I've never quite understood the benefits of async/await over go-style csp. It seems to me that its far better to just write sequential code all the time then mark all the points where you add parallelism with spawn/go instead of layer abstractions to approximate the same result but with added (in my view unneccesary) keywords. Can anyone provide some insight?

There are technical benefits and drawbacks to both approaches.

I think the main reasons people perfer one over the other are philosophical: basically, some people prefer managing the executors of concurrent code (goroutines/threads/whatever); others prefer managing the points of dispatch to executors.

You can do both in either paradigm, but those are what I see as the default modes of thinking. Neither is inherently better; it just depends on how you personally think about concurrency, and what concurrent tasks you need to model.

Post reply on HN