Live data from Hacker News

Rust 1.24

blog.rust-lang.org

161–170 of 215 posts

Re: Rust 1.24

#161
post #151

Earlier quoted context omitted.

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?

go-style csp is just async/await hidden in the syntax.

It's not, because it's not built on promises at all. Go uses separate stacks for every goroutine.

Re: Rust 1.24

#162

Earlier quoted context omitted.

It means things don't usually get better until you admit they're not as good as they can be.

rustc could definitely be faster. I'm simply pushing back on the idea that there's some obvious low-hanging fruit that clang did that rustc didn't. Compiler performance has more or less much been the #1 goal for well over a year now. The Rust compiler team (which hasn't included me for years, by the way) is fantastic. We'd all like for there to be some magic bullet that makes the compiler faster, but at this point I…

[deleted]

Re: Rust 1.24

#163
post #159
post #151

Earlier quoted context omitted.

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?

With async/await you can tell from the type signature whether a given function might suspend, and then reading through the body you can see whether each function call is a non-suspending one or a possibly-suspending one. It makes it really obvious what's doing what. If suspension is your only effect then it probably doesn't matter (one unmanaged effect is ok), but when you have other effects that might interact, havi…

Thanks, yeah, that's a useful insight. I guess it's rather a moot point with Go anyway since you have multiple goroutines executing on multiple cores at once.

Re: Rust 1.24

#164
post #15

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

> Can someone sell me on using rust over python?

I can't. But I can try to sell you Nim [0] as a compiled/faster addition to your Python, from my own experience of using it in last few months and coming from Python.

It uses significant whitespace and the syntax will surely look familiar to any Pythonista, and the entry barrier is much lower (i.e. learning curve is much shallower) than Rust.

Speed improvements I experienced are in the range of 10-100x, while the code doesn't look that much different than Python. I have solved Advent of Code in both Nim and Python in parallel [1] so you can compare the solutions/syntax yourself.

[0] https://nim-lang.org/

[1] https://github.com/narimiran/AdventOfCode2017

Re: Rust 1.24

#165
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.

Re: Rust 1.24

#166
post #69

Earlier quoted context omitted.

Python does'nt give you the low level control needed for.. low level stuff. And even if it can be implemented does'nt mean it will be fast enough.

If that's your impression, then I'd suggest Python is used for more than you're currently aware of. Here are two examples of Python being used for "low level stuff": https://micropython.org/ http://www.myhdl.org/

Uh, your examples of low level python are full of C.

Re: Rust 1.24

#167
post #92

Earlier quoted context omitted.

It's not a big-O thing. The optimization passes aren't necessarily huge either; right now, 50% of the time is in LLVM compiling IR -> machine code. The static checks, optimization passes, and everything else are minuscule overall. You can see this with -Z time-passes. We have some hunches, but nothing super conclusive yet; basically, right now it's all about how much IR we generate. Don't forget the differences in co…

Is there a way to generate IR which is easier on LLVM? The Jai compiler compiles 60kloc with an llvm backend in seconds. Could performance like this be seen in rustc?

Possibly; we'll see. MIR optimization passes may help.

It's hard to say what exactly Jai does since it's not public yet.

Re: Rust 1.24

#168

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.

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.

Re: Rust 1.24

#169
post #15

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

Rust can give you speed and safety in one package. But you sacrifice ease of coding, especially as the IDE ecosystem is not there yet in terms of ease of use.

I've taken a few apps from Python to C#/F# and seen speed increases around 50x. With Rust I could increase the speed from C#/F# by around a factor of 10x for string heavy applications processing large files. So the speed difference might be 500x between a Python and Rust application (depends HEAVILY on the problem you're solving though, a lot of the problems that can be vectorized easily work pretty fast in Python).

I'd say I'm faster at writing F# than at Python, because the type system helps me build more easily maintainable code, and the functional style is better for the way I think (I grew up with structural, learned OO in uni and thought most of it is bananas and more obfuscation than helping, and I'm happy the world is now slowly getting to something sensible again). It takes me a bit longer to write Rust programs though.

Cargo is the best build system of the 3 languages though, you can easily add crates (imports) and the build system handles everything, even unit testing. I gotta say on the project setup front Rust with Cargo is much better than any other language I know.

And I think once we get good IDEs with robust code completion and error detection, I can become quite fast at Rust as well.

Re: Rust 1.24

#170
post #15

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

I pretty much can't stand to write python after learning and using Rust. The static type system in Rust is just so great, and easy to use once you get the hang of it. This especially shines through if you have to use code someone else wrote.

I'm happy there are others seeing the benefits of strong static type systems (strong is important, the C type system which is rather weak in many instances is not as helpful).
Post reply on HN