Announcing Rust 1.0 Alpha
blog.rust-lang.org
blog.rust-lang.org
The TL;DR of the alpha is basically this:
1. The concept of a six-week release cycle begins today, with the first beta coming in March.
2. Breaking changes will basically cease, with the exception of a list of libraries that are still unstable and features that may be tweaked (https://github.com/rust-lang/rust/wiki/Anticipated-breaking-...).
3. Given the aforementioned degree of remaining instability, users should still probably stick to the nightly releases in order to help keep their code up to date and weed out bugs in the compiler.
As ever, it deserves to be reiterated that the 1.0 release does not represent the language being "finished" in any way, only that things will stop breaking. The language will continue evolving rapidly after 1.0, and even the 1.0 release will contain several known (and sometimes rather unfortunate) restrictions that will be backwards-compatibly lifted over time.
Post-1.0, I expect there to be a large community outreach to determine which work to prioritize (for example, I foresee a great clamor for making macros more usable). With developer help I intend to publish a blog post before then detailing exactly which deficiencies Rust 1.0 will contain, and the use cases that they currently either prevent or make awkward.
Getting to 1.0 means that the ecosystem has a chance to grow properly which means "lesser" coders such as myself have a chance to learn and get involved.
The evolution is important and I don't want to seem like I'm saying it shouldn't have been done the way it was, it was very well managed from what I saw from keeping an eye on the project. I am just happy that it will now be stable letting the ecosystem grow and feed off itself.
Yep, and for those who has to stay on master it was pretty nasty time - one day you patch a library, another day you're almost revert yesterday's patch.
It's worth noting that this is a significant point; probably 40-50% of the standard library is 'unstable'.
You should expect breaking changes often during the alpha. It's just ridiculous to pretend otherwise.
I'm not really a fan of these 'artificial deadlines'. There was no reason today had to be the alpha, other than it was previously said that it would be. There's been a lot of great work going into this release, but the standard library is not ready; it's going to under going some major changes over the next few weeks.
I don't really see the point in hitting the alpha 1.0 now, with the library in it's current state.
The alpha was always about language items, and an initial commitment to some degree of stability. Beta is the release where things are expected to be in their final form.
Anyone using the alpha now is being smashed with pointless unstable warnings until they add #![allow(unstable)]
...which basically negates the point of having the lint at all.
Surely a better approach would be; if 'we have no idea where it's at at the moment', don't tag the api as unstable. Tag things which wont make it into 1.0 as unstable, so people start getting meaningful warnings about using api features that won't make it into 1.0.
Seriously, what tangible benefit do 90 warnings about every single api have when you run a compile?
Even if that number slowly drops over the coming weeks, it's still going to be entirely meaningless as an indicator of what will or will not be broken once the beta hits; you're also going to be getting a lot of rubbish feedback from people asking for certain apis (which will be stable for 1.0) to be stable, because of warnings that they're unstable; for example std::fmt.
...while anyone using say, std::raw::TraitObject, or say, alloc::heap::allocate, needs to get a heads up now that they needs to say something and get involved if they want those apis to make it into 1.0
Practically speaking, it feels like you need to roll back to 'unstable' and 'experimental' tags, with the lint warning about experimental, and ignoring unstable.
ie.
'unstable' <--- Probably in 1.0, not final yet, don't lint these.
'experimental' <---- wont be in 1.0, lint on these
My Scala v1 was was very concise but took ~3 seconds to simulate a whole game. The naive Rust rewrite did it in 0.7 seconds and my current version churns them out at 0.015s each!!
http://github.com/iamdanfox/qwirkler if you're curious.. This language is really fun!
Introducing laziness by writing an iterator was actually one of the biggest single improvements (I couldn't figure out the syntax for a while, but lifetimes worked much better than I was expecting)!
[1]: https://github.com/iamdanfox/qwirkler/blob/master/src/piece....
That said, by default enum/struct layout is undefined, so it's possible the compiler could be taught to optimize your usecase correctly. For instance Option<&T> is the same size as &T because &T is strictly non-zero, and we can therefore use 0 for None.
>Hm, an enum like `enum Color { R, O, Y, G, B, I, V }` is represented by a u8 at runtime (see for yourself here[1]), which means that you're only saving a single byte in your `Piece` struct by doing that manual optimization. What was the magnitude of the speedup that you saw?
[1]: http://play.rust-lang.org/?code=%23%5Ballow(dead_code)%5D%0A...
The Rust version has had some algorithm improvements to reach 0.015s, but it was conceptually identical when it was solving in 0.7s.
That said, if your use case involves running once for a few seconds and then quitting, ahead of time compilers like rustc will always beat a profile guided JITC. So this may be an unfair point.
It'd be great for someone to write a more up-to-date version of this post!
Can Rust still do phantom types, and I just can't see them anywhere in the language reference?
struct Foo<T>; // `T` is a phantom type parameter.[0] https://blog.mozilla.org/research/2014/06/23/static-checking...
Which is...? Wikipedia says [1]
> "to be a good language for the creation of large client and server programs that run over the Internet"
and that looks too vague to me.
[1] http://en.wikipedia.org/wiki/Rust_%28programming_language%29...
I like that, its mine now.
2) Everyone and their mother is doing code reviews now, and a lot of code reviews get (very visibly) bogged down by style disputes.
3) indent and his modern friends (eg clang-format) generally only answer trivial whitespace questions, and not even things like method capitalization. gofmt is the obvious extension of indent.
The main issue for me is that your code reviwer isn't looking at the code from my company. So why should I give a damn what they think about how spaces around the parens of a function call should look like in the code I'm editing?
I'm not convinced that this should leave the bounds of a project. Within that, sure! Let's put a .rustformat right next to .gitignore, and whatever your source discombobulation utility is called just takes its hint from there. Certainly nothing wrong with a language having a good indenter, doc tool and linter in the core distribution. But one language, one style, one tab width!?!
This is especially annoying when you've got a pretty unified style across all other algol-/C-ish languages, yet can't keep this in your newest one. For the sole reason of pleasing some community that'll never see one line of your code.
The point isn't to have a "house" style, it's to have an "everything" style.
Making it optional or configurable defeats the purpose.
If you want to solve the problem that people are writing in different styles and there should be one true style for a language, why? You're bound to get something wrong in your style initially, and it will be annoying from then on, and hard to change. It actually seems the antithesis to how Rust was developed, which was to keep trying things to see what worked.
And gofmt is generally less bound to the style than, say, PEP8 since everyone could trivially mechanically update their source to the new standard.
All kept equal by hatchet, ax and saw…
It's rarely a good idea to reproduce the same patterns in two different languages (except for things that are common anyway, like indentation etc.).
And the main argument for a language-global code style is that you don't need to teach new commers (to your company/project) which code style you follow, you don't need to have long discussions about whether the article #36 is being respected in that last commit, if the code style version you had is up to date, etc.
One great example: Python and PEP8. It's the standard, everybody accepted it. That means that all libs use it AND (almost) all companies use it internally, which makes friction between different modules from different sources minimal.
Of all the C pretty-printers I tried (about a year ago), clang-format came closest but none were idempotent on the codebase I threw at it.
go fmt is idempotent, which means I use it in an editor save hook. I got used to the convenience, so now I miss an automatic formatter when writing other languages.
I find gofmt to be too opinionated about certain things and I will never use it for my go programs.
Or just clean up some nags so that version control behaves better. But if the only option is not running it at all or having all the code automatically fit to whatever the people On High have deemed to be visually pleasing? Yeah...
That seems good in theory.
The point of an automatic formatter isn't to make the code look pretty. It's to make the code non-ugly, with as little effort as possible. Obviously, there will be cases where the formatter screws up and writes out something pretty ugly. The point is to train yourself to ignore these, because honestly time spent looking at, angsting over, and fixing bad formatting is about the worst possible use of your development time. Instead you could be thinking about solving a problem that hasn't been solved before, or making the product easier for a user to use, or refactoring semantic issues in the code that trip up developers.
gofix: way more useful!
Right now almost every company and even separate teams develop their own coding conventions document and configure their tools and infrastructure for it. But if all programmers agree that "coding style does not matter as long as it's consistent" and every one is willing to accept a project's coding style when joining that project, why not pick one style for all and put it into programming languages themselves. I imagine a lot of paperwork and human time would be saved.
Can someone well informed about Rust give some impressions on the standard library? It is as comprehensive as in python or Go for example?
The standard library is _not_ "batteries included," on purpose. Given that we have Cargo, and it works well, tying package updates to the language version has quite a bit of downside, and very little upside.
That said, the Rust team itself maintains and provides a number of packages on Crates.io ourselves. Many of these were pulled _out_ of the standard library over the past few months.
At such a young stage of language development, I agree that it makes more sense to let the community develop libraries in order to foster competition and quality. But eventually (read: no less than a year or two from now) I think it will be up to the project maintainers to officially endorse certain third-party packages and commit to their maintenance. At a certain point, the advantages of a library that's well-known, well-maintained, and well-documented outweigh the disadvantages of de jure ossification.
Without it, it's difficult to be confident in the portability of components, and it quite frankly makes the language less attractive for use.
Like the other poster mentioned, I'm happy for the RUST folks to take a "wait-and-see" approach, but at some point, I believe "blessed" components are going to be expected and strongly desired.
The ease of installation has nothing to do with the desire for core components. Core components generally bring certain expectations/guarantees about security, reliability, and support.
(It's also not true that the standard library is generally pretty good IMHO, but that will start to veer us into subjectives [which I think the comment above my original post has already done anyhow]).
So, you're using three libraries that all depend on something like urllib - and they each use the library that fits their usecase best. Now you need to debug/review/depend on updates for 6 (7 if you also use the stdlib for something) foreign codebases rather than 3 + the standard library.
It's a trade-off between old/new good/best simple/complex (or complicated/complected). A standard lib that needs to maintain stability for 10+ years can never be "best" for all that time. But by being "good enough" it can often still be the best choice overall when the life cycle of a project is considered.
On the contrary, the benefits of having a standard set of batteries, especially those upon which other might be developed, is fundamental to a sane ecosystem development. For instance, a standard framework for async I/O programming is important, because then people can write thousands of protocols that can be fully interoperable; if 2-3 different framework arises, each one can then develop its own ecosystem of protocols and libraries (not interoperable), and it's hard to think that each one would be as rich as the one in the former scenario. The same can be said for a HTTP library, a threading library, a XML/JSON marshaling library, a threading/concurrency library, and so on.
Take urllib/urllib2 (use requests instead), unittest (use py.test or nose), os (too low-level, hence arcane usage) or time as examples (use pytz for anything serious), and of course Tkinter.
Take all of the modules that solve minor/niche tasks that could easily have been put in a seperate library (e.g. wave), that are usually a bad idea to use (e.g. pickle), that contain some copy/pasteable functions the authors deemed useful as comments (itertools), have documented bugs with copy/pasteable workarounds (csv).
Oh, and the way they do exceptions is a mess.
Oh, and don't try to read the Python standard libraries source code. It's ugly.
No, standard libraries should constrain themselves to providing a good foundation for library designers.
(I still like Python, and use it a lot.)
(Since you mentioned Go. One thing that I love about Go is that everything interaction with the underlying OS goes through the syscall package. Also, their designer went for more minimalism. And they didn't have to worry about design mistakes they made 25 years ago. Python is old. I'm not a fan of Gos compatibility promise: it means Go 1 will rot away too. But they're in a much better starting position.)
I should also clarify my expectations about a standard library; to me, a standard library should have all of the basics covered (interaction with the underlying system, I/O, networking, etc.) and anything that benefits from better integration with the runtime (think data types such as those found in python's collections module).
If anything, I'd argue that the main problem with Python's standard library is not the library itself, but the lack of more focused curation.
Note that I never said that I expect all functionality to be available in a language's standard library; for me personally, Go's standard library has roughly the right balance.
The worst case is exemplified by pre-STL C++, which didn't even have a string type in the stdlib. As a result, every project and library wrote their own, which meant that you basically had to choose a C++ ecosystem and develop for it rather than write libraries that are portable across multiple C++ projects.
That is not small thing either. It allows getting started easier, which in turns gets more people to use it.
Here is a list of modules I used and was happy there were in stdlib:
socket, shelve, cPickle, tarfile, urllib[2], Tkinter, time, ctypes, subprocess, asyncore, json, SimpleXMLRPCServer, wave (sorry, I did use it many time ;-) ), timeit, syslog and many others.
Most of the time I was happy to find them there.
(That said, those kinds of usecases aren't really in Rust's wheelhouse, so I still think in Rust's case having batteries not included is probably the right call.)
Every language ecosystem should work this way.
C#. The amount of time I've wasted in Java programming teams while arguing over things like which of three quirky XML parsing implmentations[1] was the One To Use while the .net team powered off and built useful functionality...
[1] This was a few years ago, obviously.
Quite an odd view from a software engineer.
I like having as much choice as possible.
Also, the sad state of Python packaging is the reason why stdlib bitrotted; technically, your package manager could take care of backward compatibility: if eg at some point in the future you want to switch from a json library to a (far) better one, more in line with how idiomatic language has evolved, you just need to repackage the old one as a third party package, and make sure the packager manager brings it down for the user automatically.
I prefer to get things done.
People who complain about the ossification are often talking about the aesthetics of the API (since API tastes change, long-term stdlibs tend to feel outdated), or the level of abstraction (you have to do a lot to use Net::HTTP, at least in the past), and not about the functionality. I'd rather people build nice abstractions on top of Net::HTTP than tell me to use something else because the API is prettier.
But would agree that the only thing Rust might need are officially supported crates, while keeping the language itself fully separate.
The language is then completely free of the hastles of maintaining a stdlib that probably isn't used by most people anyway. But at the same time officially supported packages give developers and newbs a place to start, and the community some confidence that libx will be maintained in the future. I really think this solution is the best for seperation of concerns and maximizing developer productivity and efforts.
In Go that's certainly the case and in my experience it's a great thing, only time will tell if it will end up suffering stagnation like maybe happened to python.
IMO a "softer", "recommended" packages approach is better longer term.
And also, those are generally relatively straightforward things whose design are hard to get wrong (but there are exception, e.g. Python's urllib). Being a standard library and not a standard framework helps.
For what it's worth, I use Java's standard library whenever possible. It's quite extensive and the fact that the documentation is top-notch makes it a joy to use. That being said, there are still a lot of supplemental things you might want to do, which is what things like Google Guava or Apache Commons are for. But they are to supplement, not replace the standard library.
By the way, some parts of Apache Commons would be a good example of how not to design a standard library, I don't want to piece 10 objects together to do a simple utility function call.
Almost all of them? Unless the stdlib is utterly utterly terrible the cost of the extra dependency is not worth the difference in quality between the stdlib and library which does the same thing.
Python, Go, C++'s STL, Java SDK, to name a few.
They might not be 100% perfect, but they are good and reliable, and always there for you. Hunting the latest "best" library that gets abandoned after a year (like in Javascript and Ruby often happens, and also Go too) gets old quickly.
Of course there could be a compromise approach, as you say.
A mininal standard lib for Rust PLUS a "blessed" set of Cargo packages that represent the batteries (Haskell "Platform" is like that, IIRC).
Hardly. See Joda Time (it only took 10 years for java.time to catch up) and Apache Commons (the situation is much better now, but who hasn't turned to Apache Commons due to shortcomings in Java's standard library?).
In any case, I definitely agree with the frustrations of trying to find libraries for Ruby.
I wrote that those batteries "might not be 100% perfect" -- and as a Java programmer back in the '00s, I know the specific problem points with Java time that Joda tried to solve (btw, it has inspired the time lib in the latest SDKs IIRC).
The thing is, the JDK APIs, with all their issues have been a genuine force in Java adoption, and something every Java programmer relies on. Of course there'll be some pain points, but it's nothing like having to hunt for a Collections or DB abstraction or String manipulation or XML etc lib each and every time you start a project.
Having an official batteries API doesn't preclude you from using external libs (like Joda) when they are better -- whereas not having one is a genuine loss.
If I have turned to Apache Commons that was overwhelmingly for things MISSING from the SDK, not for things the SDK already did.
And don't get me started on the Commons code quality, with BS reinventions of the wheel, lame FactoryFactoryProxyFactorySingletonFlyweightFacades and the like, and code that was blisfully ignorant of enconding issues...
urllib gets trumped by requests, ujson is much much better than the stdlib json module, hardly anyone still uses distutils over setuptools for example.
I think <stdio.h> is a good example. It gets the job done, its minimal and simple. That's what a standard library should be.
It also routinely takes null-terminated strings without pairing it with a size parameter.
IMHO, C++ in an example where the standard library (and its laboratory, boost) is often a very good solution for the few things it covers. It's standardized, well-documented, and not that bad from a performance point of view (of course, it's not perfect).
In addition, you expect your newly hired developers to know the standard library, but not every small libraries from github...
With a good package management system, a batteries-included standard library could just be a set of packages where you are guaranteed that a version of each backward-compatible to the one provided at language release (in SemVer terms, a package with the same major version number as the one packaged with the language release) would be available and maintained for the maintenance life of the language version. It wouldn't have to prevent either bug-fixes to packages out-of-band with language version upgrades, or even out-of-band new major versions of packages that support the existing language versions so long as the old major version was maintained in parallel as long as the language version was.
Which with a language like Rust capable of producing static binaries, feels like a better place to be in anyway since it's a lot easier to replace 1 executable then a whole net of shared dependencies.
This would still allow for pulling up to the bleeding edge, or simply not using, of some of those blessed packages if you choose to by specifying them in the cargo manifest, but would still provide guidance on basic useful packages.
I think it'd also be easier to boot stale packages in new releases (ie. the eternal security fail that is the yaml lib in ruby's stdlib).
In the past year I have needed libraries for HTTP, XML, JSON, CSV, arg parsing, image manipulation, PDF, RDBMS, a trie (and other data structures), async i/o, threads, files, ZIP, and others.
2. https://github.com/kud1ing/awesome-rust/ - manually curated list of good libraries
Arg parsing: https://github.com/docopt/docopt.rs
Over Christmas break, I played around with Rust and I'm really enjoying it. However, I can't figure out a nice way to inherit members from other structs. My current idea, like many others, is to keep a pointer to a "parent" object. So, Duck would have a GameObject, rather than be a GameObject.
Does anyone have any recommendations for better ways I can achieve what I would like to do? I will also accept the fact that inheritance is not needed in a language, but it does make a few situations easier.
(Oh, and Rust doesn't get everything Servo needs, what I mean to say is "Servo has demonstrated that there is real-world need for something like inheritance, and so we will add it.")
Anyway, if you're already doing a component based system, why do you need inheritance? Just do a normal ECS. You don't subclass GameObjects in most implementations of ECS (and this is a good thing).
Never do this. Just don't. What you should do instead, is write a game, and while writing that game, write its engine. At the same time (Or even, write a game, and then refactor the engine out as you go).
Then, after you're done, that engine can then be extracted and made to be more generic. This is basically how every engine used in the game industry was made (although in many cases the game the engine was written with never shipped).
Trying to make a generic engine from the start will be worse in basically every measurable way. It will take longer to write, take more code, use more memory, and be slower...
Again, sorry if I misjudged your comments. Anyway. On to what you said specifically:
Having an empty base object so you can have lists of GameObject (presumably lists of `GameObject*` in reality) is basically going to destroy performance and the cache. A reasonable rule of thumb is that a read from memory will take about 100 times longer than, say, a float multiplication, unless you know it will be in the cache. Then, to operate on these game objects, you'll probably use virtual methods. Another rule of thumb is that vtables are basically never in the cache (and they're also unpredictable branches).
Really what you want to have is several flat arrays of the data each part of the engine needs to operate on. This is also good from an encapsulation standpoint, because then each part of the engine only can see what it needs, and not necessarily the whole game object. Then, the way you'd implement a component system in this style is that you'd make that array the canonical place the data lives.
This can work well for some games but isn't worthwhile for every game. (Generally I actually think the biggest benefit is that it makes gameplay and tools for non-developers easier to write.)
Your impression is a little wrong, see below.
> Never do this. Just don't. What you should do instead, is write a game, and while writing that game, write its engine.
I'm not making a game. We have an OpenGL Game Engine class in my Game Programming program at college. I'm creating my game engine with the idea that someone could simply include it as a library and then use its features to develop a game. This Game Engine class is now over, however, I'm still developing my engine purely for personal learning purposes. Yes, I am creating demos to test features of my engine, but I'm not writing anything that would be considered a game.
Regarding the rest of your comment, I totally agree and understand what you are saying. This actually makes sense, however, it's just not the way that we've been taught so far in my program. Being a student, we are familiar with the practices that our teachers use. This makes us somewhat close minded, but it's really nice when people (like you) give a completely different way of doing something.
Thanks for the help! I'll look into these different methods of structuring my engine.
And that's fair. I didn't think this way until after working in industry for a while, and my code from when I was at school was very high level and OO.
If you're interested, Mike Acton (lead at insomniac, and one of the smartest people in the industry) had a good talk in CPPcon that you can find online about Data Driven design[0], which is basically what I'm talking about (he's a bit more extreme than I am). I'd also recommend looking at his 'Typical C++ Bullshit' slides[1] for a shorter and more amusing take on the issue.
[0]: http://youtu.be/rX0ItVEVjHc
[1]: http://macton.smugmug.com/gallery/8936708_T6zQX#/gallery/893...
This semester, I used an app to keep track of how much time I put into every class.
- game engine: 106 hrs
- AI: 10 hrs
- physics: 10 hrs
- ogre: 12 hrs
As you can tell, my game engine was the thing I worked nearly every day on, mostly late at night. If I took an assumption about my class average on hours put into their game engines, I'd say a safe guess is around 15 hours if we don't include my time and the 2 others who also put an insane amount of time into their engines (it was pretty much a competition between 3 friends to outdo each other).
Back to making my maze game... We had the entire semester to work on either a solar system or a maze game. I pumped out the maze game in 3 hours with my engine on the day it was due. The thing is, I was confident with my engine. I put so much work into it, and I understand how it worked under the hood, that I knew I could produce something very fast and easily with it.
The game itself was simple. Have a first-person camera walk around the maze, pick up a key, and then go to the maze exit and open the door. Even though I did it in 3 hours, I also included the ability to pick up a gun, attach it to the camera like an FPS; added a skybox; added a simple sin wave twirl for objects sitting on the ground; and a few other small details here and there.
Anyways, sorry I went on for a little bit there. I'm just really happy with how much my engine is progressing, but it still needs a lot of work and polish. I'm way more open minded now after this discussion. I feel confident about not needing inhetitance now, especially since I feel like in a couple months I might port everything to Rust.
I also realize that it was very risky leaving that project until the last minute. If I ran into an issue, it could have severely messed up my mark. Making a game at the same time as an engine does indeed help with the engine development, I see the benefits of doing so. When I get a chance to continue working on it, I will probably continue developing the maze game along side it.
Anyways, thanks for those links, I'll be checking them out tonight!
http://bitsquid.blogspot.com/2014/08/building-data-oriented-...
A couple of commercial games have been built on that engine and it was recently sold to Autodesk, so it's not just handwaving.
Duck should not be a class, it should be a factory function that creates a generic GameObject and configures it with the set of components that allows it to look, walk and quack like a duck.
It's also much easier to data-drive entity types; at some point you will even do away with factory functions for GameObject types and describe these types in data files loaded at runtime. This opens up options for designer-friendly editing tools and even 3rd party modding.
Am I wrong?
Will I ever be writing a web application in Rust?
Honestly, its not such a big change once you get into it. I'd encourage you to just give it a go, build something just for fun with it. Be it a command line tool, game, whatever. My experience has shown me that just because you've only been involved in web development, by no means limits you from systems/low level development!
Looking forward to watching Rust expand into almost every corner of the development world: web, applications, systems, embedded, safety-critical, games, hard real-time, on so on!
The language developed rapidly, without sacrificing reinventing things, changing opinions a lot. I am not sure how they did that, but it's really impressive. Usually languages lack documentation, stability, performance, etc., have lots of rough edges, no users or libraries, but none of that is true for Rust.
I am really curious about how this was achieved. Maybe someone involved could describe how that was possible. I am sure I'm not the only one interested in this.
A year ago there was an article about using Rust for an undergraduate class on operating system development. Rust was 0.7 back then and very different and way more mature.
(I'm pretty sure I remember hearing that rustc has more code at this point then servo does, but don't quote me on that)
Caveat: use of 'find' and 'wc' is almost invariably totally misleading :-)
Time to start exploring it again.
I just checked out the github repo on a quad core 3.4GHz i7 with 16GB ram, and make -j8 took 37 minutes -- the c/cpp stuff (like llvm) built in parallel, but all the rust stuff did not, such that 7 cores (HT) of 8 were idle for the bulk of the build.
curl -s https://static.rust-lang.org/rustup.sh | sudo sh
rustup: CFG_CURL := /usr/bin/curl (7.35.0)
rustup: CFG_TAR := /bin/tar (1.27.1)
rustup: CFG_FILE := /usr/bin/file (5.14)
rustup: CFG_SHA256SUM := /usr/bin/sha256sum (256sum)
rustup: CFG_SHASUM := /usr/bin/shasum (5.84)
rustup:
rustup: processing sh args
rustup:
rustup: CFG_PREFIX :=
rustup: CFG_DATE :=
rustup:
rustup: validating sh args
rustup:
rustup: error: unknown CPU type: armv7l
Feel free to come ask in #rust on irc.mozilla.org if you need some experts to consult!
I compiled an hello world on the VPS, the content of which is:
fn main () {
println!("hello world");
}
rustc main.rs
hello world
+ apt-get install -qq g++-arm-linux-gnueabihf
E: Unable to correct problems, you have held broken packages.
I am going to go back now to the example Rust code for PSP you linked and look more at it, it seems to be the most promising at this point (though it will be a bit inconvenient for me in the long run to do any development on the VPS instead of locally.)
Thank you for your comment and the link.
For others who are interested, there are instructions here for building Rust for Android and iOS, see "Platforms":
Considering that in February Apple will deny apps which do not support arm64 it is just in time :-)
So I'd say that iOS is almost first-class citizen - the only drawback here is that it is not in build bots and therefore `master` can be broken sometimes, in this case you can check https://github.com/vhbit/rust which may lag a bit but is always buildable for iOS.
Or, if not, but if it's still possible to build one from source, what are the required dependencies I have to install to be able to build the epub?
Why not 'let' and 'var' instead of 'let' and 'let mut'?
It's just so ... weird.
let (x, mut y) = ...
There are some discissions about this on the ML archives, RFC repo, or discuss, if you're interested.
Also, communication is in the ear of the beholder. Var: variable, that varies. 'Let' would be immutable by default.
Thanks for the response anyway.
let var x = ...
let x = 100 // constant
var y = 200 // variable
x = x + 1 // error
y = y + 1 // 201It's actually entirely reasonable to have an "immutable variable" -- Rust uses this phrase in its error messages and it's perfectly sensible. For example, consider this snippet:
pub fn is_even(x: int) -> bool {
let y = (x / 2) * 2 - x;
if (y == 0) {
return true;
} else {
return false;
}
}
The opposite of "variable" is "a constant," not immutable. 'mut' means "mutable" and "mutable vs. immutable" is the choice here. Rust got this right, I think.
// Old-style generics; monomorphized
// with S as an "input" type of MyTrait
fn foo<S, T: MyTrait<S>>(elem: T) { ... }
// Where-clause-style generics; monomorphized,
// with S as an "output" (associated) type of MyTrait
fn foo<S, T>(elem: T)
where T: MyTrait<Thing = S> { ... }
// Trait objects; dynamic dispatch
fn foo(elem: Box<MyTrait>) { ... } fn foo<S, T: MyTrait<S>>(elem: T) { ... }
fn foo<S, T>(elem: T) where T: MyTrait<S> { ... }
fn foo<S, T: MyTrait<Thing = S>>(elem: T) { ... }
fn foo<S, T>(elem: T) where T: MyTrait<Thing = S> { ... } enum Option<T> { Some{value: T}, None }But yes, their primary usage is to require that type parameters exhibit a certain set of properties.