61–70 of 274 posts
That's a good list. Get the basics right. Rust has been putting much effort into "l33t features" in template land. I fear Rust may be going down the C++/Boost template metaprogramming rathole.
Earlier quoted context omitted.
> What about the warts part? I'm not sure enough time has passed to tell what Rust's warts truly are. I always joke String should have been called StrBuf... I do this, yes. This is one of the reasons I hang out in IRC so often; it's an effective way to collect these kinds of things. More data is always better, and collecting it across multiple venues. I don't think IRC is inherently going to be a representative sampl…
I see. I hope to see more better docs soon. Thank you for answering and for generally being open.
Earlier quoted context omitted.
The Rust's goals of high performance, safety and pay-what-your-use and you-couldn't-hand-code-better won't be sacrificed for sure. The point in ergonomics improvements is to identify "free lunches" that aren't yet taken advantage of. That being said, lifetimes and traits being both complex and unfamiliar features, there's always going to be quite of a learning curve. But one can always reduce the amount of papercuts.…
Can you say that traits are like Go interfaces?
It's old enough that it's before Rust 1.0, so some of the syntax is a _teeny_ bit wrong (int isn't a type any more, you'd use isize) but the macro picture is the same.
That's a good list. Get the basics right. Rust has been putting much effort into "l33t features" in template land. I fear Rust may be going down the C++/Boost template metaprogramming rathole.
From that C++ thread on HN right now:
https://news.ycombinator.com/item?id=13584167 https://news.ycombinator.com/item?id=13583935
Call me skeptical, but I do not believe ADDING stuff to C++ is going to make it more competitive against Python in ease of use. Especially as programmers will still always be free to use all features, and any large enough project is going to end up with all of them.
Earlier quoted context omitted.
What about the warts part? Also, as someone who've tried to get into Rust three times now, I've been thinking, have you or anyone from the rust documentation team ever had sessions where you just - take a random C++/Go/Python developer - ask them to solve a not-too-simple but not-too-hard task, something that'll generally take them less than an hour in their "native" language, in Rust - look and take notes on their s…
Given the number of Rust developers reading this, it's probably going to be very helpful for them if you can describe what you actually got hung up on.
Basically, I tried to create a very basic HTTP server the way I would in Go, but I kept getting all sorts of lifetime errors and kept adding stuff go get away from them. So the code has issues, lots of them. Arc> was recommended by a guy at the job, I don't even know why I need an Arc here, for example.
The compiler says
consider using an explicit lifetime parameter as shown: fn handle(&self, req: server::Request,
mut res: server::Response)
error: `user_index_handler` does not live long enough
Earlier quoted context omitted.
I would say random numbers are a fairly core programming construct for a standard library. They're important, difficult to get right, and have huge implications if you get them wrong.
This doesn't answer my question, though. Most of the "fairly core programming constructs" are not in the stdlib for Rust (like regexes) The Rust stdlib is mostly core abstractions and platform-dependent stuff. Given that, why should they be in the stdlib? The rand crate is officially blessed and the one everyone uses.
> Plans include a new book, You should consider publishing an official, printed book. I would totally pay $30-40 for something like this. And once it's already written, the actual publishing shouldn't be too time consuming (but idk lol). I think that there's a lot of people who'd buy it just to support the project. On one hand, I do have environmental concerns, but on the other hand, I feel like my retention rate wit…
Oreilly has an early release available: http://shop.oreilly.com/product/0636920040385.do I have purchased it and it's pretty good. Although it really seems to be geared more towards experienced systems programmers. The online book is much better for beginners, IMO.
> Plans include a new book, You should consider publishing an official, printed book. I would totally pay $30-40 for something like this. And once it's already written, the actual publishing shouldn't be too time consuming (but idk lol). I think that there's a lot of people who'd buy it just to support the project. On one hand, I do have environmental concerns, but on the other hand, I feel like my retention rate wit…
Oreilly has an early release available: http://shop.oreilly.com/product/0636920040385.do I have purchased it and it's pretty good. Although it really seems to be geared more towards experienced systems programmers. The online book is much better for beginners, IMO.
Earlier quoted context omitted.
Given the number of Rust developers reading this, it's probably going to be very helpful for them if you can describe what you actually got hung up on.
This was a few months ago, so I had to dig up some code: https://is.gd/kQJ7nv Basically, I tried to create a very basic HTTP server the way I would in Go, but I kept getting all sorts of lifetime errors and kept adding stuff go get away from them. So the code has issues, lots of them. Arc > was recommended by a guy at the job, I don't even know why I need an Arc here, for example. The compiler says consider using an…
I _think_ the issue here is that Request and Response both have lifetimes. The compiler suggestion you're seeing was recently removed for having too high of a false positive rate, which I believe is what happened here. By doing that, you say that the handler must live as long as the Request and Response, which is not true, since it's created inside the functions but they're passed as arguments.
I saw the long awaited Non-Lexical Lifetimes tentatively mentioned in there, and I can only hope this will help move things forward, since it's pretty frustrating spending time fighting the borrow checker and refactoring correct code that really ought to run as-is.
Cheers and happy 2017 to the Rust project!