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

2017 Rust Roadmap

github.com

Post reply on HN
Print view View original

161–170 of 201 posts

Re: 2017 Rust Roadmap

#161

Post by burntsushi »

pcwalton wrote: post #160
burntsushi wrote: post #158

Earlier quoted context omitted.

It definitely does: https://github.com/golang/go/blob/b851ded09a300033849b60ab47... I should look into those benchmarks if you think there might be string problems. To be frank, I've never looked too closely at anything except for regex-dna.

Oh, interesting. I was inferring that from the Go code out there that uses machine code directly: https://github.com/minio/blake2b-simd/blob/master/compressAv... I guess it must be a recent addition.

I think it was recent, yeah. I also recall there being problems with their assembler not being able to parse various SIMD instructions in the past. I also recall seeing code like in your link too.

Hmm, Go 1.7 introduced support[1] for various AVX instructions (plus at least one SSE 4.2 instruction), some of which are used in blake2b-simd.

I can't wait to get SIMD on Rust stable. It's going to be exciting.

[1] - https://golang.org/doc/go1.7#tools

Re: 2017 Rust Roadmap

#162

Post by igouy »

steveklabnik wrote: post #153
igouy wrote: post #151

Earlier quoted context omitted.

Do those Go programs use explicit SIMD ? http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

I assume that they're better about generating it implicitly. That is, it's about why Rust is slow, not about why Go is fast.

> about why Rust is slow

If the Go programs don't use explicit SIMD, then "explicit SIMD is still unstable in Rust" does not explain the difference.

Re: 2017 Rust Roadmap

#163

Post by pjmlp »

steveklabnik wrote: post #114
pjmlp wrote: post #109

Earlier quoted context omitted.

Maybe this could be some kind of cargo command: cargo template-gen name something

https://github.com/rust-lang/cargo/issues/396

Thanks for point it out, it just isn't clear what the current state is.

It looks kind of dropped with the github repository only having a basic example.

Re: 2017 Rust Roadmap

#164

Post by pcwalton »

burntsushi wrote: post #158
pcwalton wrote: post #154

Earlier quoted context omitted.

I don't think Go emits SIMD at all. Their assembler doesn't even support parsing it. I think these are probably just bugs that we need to look at. The benchmarks where we do worse are the string benchmarks; perhaps it's our Unicode correctness that is hurting us, or something like that.

It definitely does: https://github.com/golang/go/blob/b851ded09a300033849b60ab47... I should look into those benchmarks if you think there might be string problems. To be frank, I've never looked too closely at anything except for regex-dna.

Oh, by the way, if you want to investigate the string benchmarks, that would be really awesome--I'm curious to know what's going on there :)

Re: 2017 Rust Roadmap

#165

Post by gravypod »

unfamiliar wrote: post #146
gravypod wrote: post #4

> 1 in 19: lack of IDEs (1 in 4 non-users) I expected that to be higher actually, but that's still the only reason I don't use the language. I've come to rely heavily on IDEs. Whether right or not it's a huge factor in my decision to wait for the language.

What kind of IDE support do you typically use that isn't handled by a modern text editor (such as go to definition, variable renaming, find and replace, etc)? I'm starting to use CLion for my C++ work now, because "go to definition" is much more reliable than most editors can manage with C++ code, but I find that most of the fancy refactoring features like extracting functions or subclasses are not used often enough…

The features I need are:

   - Refactoring Support (rename variable, class, function)
   - Code Folding
   - Automatic type checking
   - Automatic error detection (tells me when syntactical or other errors are made)
   - Built-in documentation loading/display on hover of cursor. 
   - Same thing as above except with any documentation I add myself on a function. 
   - Debugger with comment overlay of values (like PyCharm)
   - Dependency management/Building/Deploying all a *button* (not 10 commands) away 
   - VCS integration
   - Automatic code formatting 
   - Automatic code "cleaner" (change for (int i = 0; i
Outside of all of those, there is a much much much more important feature: Auto Complete. A smart auto complete. An autocomplete that understands the type system and the function's return types.

For instance if I am typing:

   String sub = someString.
It shouldn't recommend "length()" as well as in the case of:

   String lengthStr = Integer.toString(someString.
It should recommend things that return an integer. This needs to be fast and needs to be non-case-sensitive. Also, if I am typing

   Lis
It should recommend List, ArrayList, etc in that order with the closest thing up front. It should also in the recommendation screen show documentation, a link to official documentation, and possibly an example of how to initialize/use the code. If something isn't imported and so it's not currently usable, if the user clicks enter or whatever on the auto-complete screen you should import it. If it has that, and has that working quickly, and has that working completely it's a "real" IDE in my book. That list is just "wants", this one thing is a "need"

If I had that for rust, I'd switch over to rust as my main language. Anything that doesn't have something like that will never compete with Eclipse in ease-of-adoption in my book.

Re: 2017 Rust Roadmap

#166

Post by progman »

cgag wrote: post #37
dikaiosune wrote: post #35

Earlier quoted context omitted.

I would offer a counterpoint -- Rust's guarantees and strong typing offer a different kind of productivity to an intermediate or experienced user. One where a compiled program is much more likely to be "correct" than in any other mainstream-esque language I've used. The properties which combine to create this effect make refactoring much less scary, allow easier navigation in large codebases (IMO), and allow for othe…

This is why I think there's room for another bigtime language that hits the rust sweet spot of functional-flavored imperative programming with a GC.

If you want a modern language with (optional) GC, with seemless FFI to C, and with almost C performance then you should take a closer look at Nim. Rust can learn a lot from Nim regarding productivity.

http://nim-lang.org

Re: 2017 Rust Roadmap

#167

Post by tatterdemalion »

erlend_sh wrote: post #122
tatterdemalion wrote: post #88

Earlier quoted context omitted.

> Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! I'll say it. At work, the backend is Rails, and I am a Rust contributor in my freetime. I am in the early stages of working on a framework for web apps in Rust & I believe it will be comparatively productive to Rails. Only your code will be faster and many bugs will be caught at compil…

Have you heard about Helix? - http://blog.skylight.io/introducing-helix/ I think this is a great way to introduce large existing Ruby codebases to Rust in increments, much like Sentry demonstrated recently, but for Python: https://blog.sentry.io/2016/10/19/fixing-python-performance-...

Yep. :) Different usecase from what I'm working on; helix is for embedding Rust inside of a Ruby program, my library is for writing an HTTP service in Rust; so it will sit on top of tokio + hyper.

Re: 2017 Rust Roadmap

#168

Post by tatterdemalion »

collinmanderson wrote: post #156
dikaiosune wrote: post #2

It's important to note that this is an RFC which has been proposed, and there's likely to be a good deal of discussion and revision before it's merged/adopted as the official 2017 roadmap. The conversation can be followed/joined/whatever here: https://github.com/rust-lang/rfcs/pull/1774

"accordance with RFC 1728" - could they have chosen a naming scheme so their documents are not confused with the _real_ RFC's? Even RRFC 1728 would helpful. Or maybe just #1728?

Lexical scope. You should assume an RFC cited in a Rust RFC is a Rust RFC, you're in the Rust RFC scope. If an IETF RFC is cited in a Rust RFC, it won't be ambiguous.

Re: 2017 Rust Roadmap

#169

Post by berntb »

pjmlp wrote: post #110
berntb wrote: post #75

Earlier quoted context omitted.

Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! Or are you saying that it is a pleasure to use, so you'll use it for smaller backends where development speed isn't that critical? (Asking, not flaming. :-) )

It is possible to have both capabilities in a programming la language.

I note the long list of obvious examples...? :-)

But sure, the world would be a better place if Rust, Go and/or Swift could fulfill that niche. I really don't know enough. (Go seems a bit boring. Rust is too new. Swift is a bit limited re Linux etc support.)

(I've seen the claim that some C++ gurus could develop features as quick as seasoned scripters, but... how many years did it take to get to that state? :-( )

(Sorry for coming back late.)

Re: 2017 Rust Roadmap

#170

Post by ezy »

cheepin wrote: post #15

I read through the Rust book, and the problem I was having with it and the other docs is that it was hard to map the Rust concepts with what actually runs when it is compiled. For a language that touts "uncompromising performance", it was difficult for me to find performance characteristics of the underlying abstractions and std library (for example, are algebraic data structures just tagged unions or does the compil…

> it was hard to map the Rust concepts with what actually runs when it is compiled.

This. The primary reason to choose rust is performance -- that is, you want more advanced abstraction/safety capabilities than C++, and you want that with the same or better performance. And performance implies CPU cost and memory usage/layout control. There really isn't any point otherwise.

Therefore, going into at least a little bit of detail on the idioms and performance impact of those idioms is important. Rust is a supposed to be a systems programming language to replace C, do not pretend it's as abstract as ML in the documentation.

What throws me for a loop when learning Rust isn't high level details like the borrow checker or sum types, it's what is happening with cpu & memory[1]. When things are copied, when they aren't, how much do the std derives cost, matching cost, sum type storage cost, etc. Because while the semantics are similar to C++, they are not the same. And you don't have to go nuts specifying it (compilers will differ), but at least give a general understanding/hint of what to do and what to avoid.

To be fair, the doc does have this scattered about, but it doesn't feel a priority (There are many things I've had to search the web for or ask on #rust, or just look at disassembly for).

[1] To take an extremely simple example, RVA is something Rust supposedly does much more consistently than C++, thus returning a new struct by value to be placed wherever is idiomatic. However this isn't called out very clearly (the last time I checked) in the doc, and to a C programmer, it feels very wrong. Stuff like this is extremely important, otherwise we'd just ignore performance and use a JVM based language with the same (or better) abstraction features and a faster compiler. :-)

Post reply on HN