231–240 of 274 posts
However, what I still miss is bootstrapping from source. It would make porting to other platforms much easier. It confuses me that Rust is proclaimed as a safe language while anyone is forced to install a binary with wget | sh.
I'm surprised cross-compilation is not on the roadmap. I've heard that it is ready and that it's not quite ready. Can I create a Windows executable for Windows on Linux?
I'm surprised cross-compilation is not on the roadmap. I've heard that it is ready and that it's not quite ready. Can I create a Windows executable for Windows on Linux?
> Can I create a Windows executable for Windows on Linux?
Yes, but it's a little gross at the moment: https://github.com/rust-lang-nursery/rust-forge/blob/master/...
We do plan for all of this to be much, much easier in the future. Working on it.
> I've heard that it is ready and that it's not quite ready.
The foundations are strong, but the details are tough. So like, doing the cross-compilation is there, and is the simple bit, it's all of the stuff around it: linkers, other platform stuff, things like that. But the foundation to make all of this easy is in place. It just needs time and effort.
Earlier quoted context omitted.
RFCs are frozen in time; regex has since moved under rust-lang, and has a pre-release for a 1.0. That person isn't random; they're on the libs team and the primary author of regex. (there are a few crates by other people as well, but most of those crates were extracted from regex as they can be useful on their own.)
My point is researching all this puts a huge burden on (serious) users that would not be there for a big standard library. Currently the Rust approach seems quite problematic, but I think this can be solved. For example by an explicit guarantee pledged by the Rust team (or a related umbrella / organization / consortium / ...) for a certain set of libraries (platform / ecosystem / 2nd tier standard library extension /…
Earlier quoted context omitted.
The idea is that these can evolve separately from the language; they are not tied to language versions. Contrast that with Python where you have the urllib urllib2 urllib3 issue; with people going and using requests anyway. There's no inherent reason to put them in the stdlib aside from "other languages do it". And yeah, folks don't want to commit to sticking them in the stdlib forever. If a better library turns up p…
The Python urllib/urllib2 issue is a feature . It means any code that uses the old (inferior) urllib continues to work, without having to update it as urllib2 starts being used within the same function so that it can be migrated. That's what promising stability means. This applies to your last paragraph as well -- I do want to be using code that folks are trusting to be the way to do things forever (well, at least fo…
> It means any code that uses the old (inferior) urllib continues to work,
Rust lets you have multiple versions of a transitive dependency in your project, so they would continue to work.
Earlier quoted context omitted.
So I'm only a Rust amateur (I mean I don't get paid to use it), but I'm on my third round trying to build something with it, and I feel like I'm finally starting to get it. A couple warts I've encountered: - No support for default struct fields: https://github.com/rust-lang/rfcs/issues/1594 - Terrible signatures for functions that return iterators: https://www.reddit.com/r/rust/comments/2h26cj/functions_retu... If th…
A feature designed as a fix for the second problem is already in nightly: https://github.com/rust-lang/rust/issues/34511 Who knows when it'll be stabilized, though.
Earlier quoted context omitted.
One piece of software that handles a lot of traffic on phone networks has an interesting issue. A bunch of headers are added to a list on every transaction. Most of these header names are constants ("TransactionID", "SourceId", "CallingNumber", etc.). However, they can be dynamic ("x-dynamic-header-foobar"). The easiest way in C to deal with this is just to strdup all the header names, so the final consumer can safel…
How would rust help in this situation? What alternate design is rust enabling that would be different?
Earlier quoted context omitted.
Rust is hardly the only language to have a type system that supports generics.
I didn't say it was! I said it was an "excellent choice". Right?
Earlier quoted context omitted.
I am about to go into two hours of meetings so this will have to be quick. The issue is, because this is a trait, you must conform to its signature. Which is here: https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht... and specifically https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht... So yeah, my idea won't work, because those types conflict. > Removing the trait impl was another thing recommen…
Okay, thank you again for your time!
Handlers aren't meant to be nested like this. That is, it's always going to break this way, because the handler needs to live as long as the request and response, so creating a sub-handler is not ever going to live long enough.
So yes, the solution is to not implement Handler for your UserIndexHandler; then you can just call it.
I bet there's something larger you could do as well, but I don't have enough experience with this interface to give good advice. Hyper's undergoing a huge docs drive for 0.11; I'm sure that'll help.
Earlier quoted context omitted.
> But the problem with that is that the market that really really can't use GC is vanishingly tiny. If you write a library in C#, you can use it from .NET languages. If you write a library in Java, you can use it from JVM-based languages. If you write a library in Python, you can use it from Python. If you write a library in Rust, you can use it from any language that can bind to C, which is virtually every language…
> If you write a library in Python, you can use it from Python. Or from C. Or from any language that can bind to C. Like Rust. I'm fairly sure the other languages you listed also allow calling from C and hence from Rust, as well as among each other. > not every object requires its own heap allocation Sure. That doesn't change if you add a GC to Rust: Objects won't magically become non-stack-allocable if they were sta…
But then you have to include a foreign language runtime! Together with all the headaches and interoperability complications that entails. How many .NET applications do you know which include a JVM runtime, or how man Java libraries include on the Python runtime? Now compare that to the number of applications or libraries (in any language) that directly or indirectly depend on a library written in C or C++. Rust will have the same advantage.
> That doesn't change if you add a GC to Rust: Objects won't magically become non-stack-allocable if they were stack-allocable before.
My point is that a GC probably won't have a positive effect on most programs written in idiomatic Rust, therefore there's no need for it (contrary to what you claim).