Rust 0.6 Released(mail.mozilla.org)
mail.mozilla.org
Rust 0.6 Released
https://mail.mozilla.org/pipermail/rust-dev/2013-April/003427.html
117 comments
It is interesting how many of these newer languages clearly try to improve upon a specific older, established language (at least imho) (take with a grain of salt).
C++ -> Rust
C -> Go
Java -> Scala
Lisp -> Closure
Erlang -> (Go or Scala)
Javascript -> (Too Many; Dart, et al)
(Edit: Formatting)
C++ -> Rust
C -> Go
Java -> Scala
Lisp -> Closure
Erlang -> (Go or Scala)
Javascript -> (Too Many; Dart, et al)
(Edit: Formatting)
As someone already mentioned, -1 on Erlang-> (Go or Scala)
They didn't try to improve they removed features such as error handling, distribution, all which are very important for building fault tolerant system.
Paradoxically perhaps, I see it inverted:
(Go + Scala) -> Erlang
Temporal sequencing doesn't necessarily imply strict improvement.
They didn't try to improve they removed features such as error handling, distribution, all which are very important for building fault tolerant system.
Paradoxically perhaps, I see it inverted:
(Go + Scala) -> Erlang
Temporal sequencing doesn't necessarily imply strict improvement.
I was referring to how Scala copied the actor model (though it is was not invented for Erlang either) and several other Erlang-ideas while adding new features and running on the JVM. In some direction similar with Go; You're right though, it wasn't the best of comparisons.
> Lisp -> Closure
There is no single "Lisp", but many dialects including Common Lisp, Scheme (and its bazillion variants), Clojure, Emacs Lisp, Arc...
> Java -> Scala
Except for the fact that Scala is based on the JVM and partly reuses the Java standard library (for interoperability reasons), the language is the product of many influences, including ML, Haskell, Java, Scheme, Eiffel... The syntax and the "feel" of the language is actually quite far from Java thanks to its functional side.
There is no single "Lisp", but many dialects including Common Lisp, Scheme (and its bazillion variants), Clojure, Emacs Lisp, Arc...
> Java -> Scala
Except for the fact that Scala is based on the JVM and partly reuses the Java standard library (for interoperability reasons), the language is the product of many influences, including ML, Haskell, Java, Scheme, Eiffel... The syntax and the "feel" of the language is actually quite far from Java thanks to its functional side.
That's definitely not a new trend.
http://www.paulgraham.com/fix.html
http://www.paulgraham.com/fix.html
It's Clojure, not Closure. Google Closure is an optimizing JavaScript to JavaScript compiler.
I'm not sure Go try to replace C. Most (all?) embedded systems need to control memory allocations.
I'm not sure Go try to replace C. Most (all?) embedded systems need to control memory allocations.
Could we see a brand-new Chrome browser written in Go, though? Or would it better for Google to use Rust, too, for that?
The Mozilla/Rust/Servo developers talked about why they continue developing Rust and not considering Go for the job. It has absolutely nothing to do with a turf war because Mozilla is actually using Go for some server side things. But one major reason for not using it to implement Servo (the next-gen browser engine) is the mandatory GC. For a lowlevel performance and memory critical application such as a browser engine you don't want a GC.
> I'm not sure Go try to replace C. Most (all?) embedded systems need to control memory allocations.
Are you aware that there are embedded systems coded in GC enabled languages?
It is all a matter of the available resources.
Are you aware that there are embedded systems coded in GC enabled languages?
It is all a matter of the available resources.
It is all a matter of the available resources.
I'd say, it's all a matter of the guarantees. Guarantees are everything in embedded systems.
I'd say, it's all a matter of the guarantees. Guarantees are everything in embedded systems.
What about ballistic missile tracking?
http://www.militaryaerospace.com/articles/2009/03/thales-cho...
This is just one example from many I can pick up, this one is Java, but there are systems done in other GC languages as well.
But I do agree it is a matter of hardware resources and if hard or soft real time guarantees are to be expected, just that not all embedded systems require real time processing.
http://www.militaryaerospace.com/articles/2009/03/thales-cho...
This is just one example from many I can pick up, this one is Java, but there are systems done in other GC languages as well.
But I do agree it is a matter of hardware resources and if hard or soft real time guarantees are to be expected, just that not all embedded systems require real time processing.
IIRC, in the "real time java" world though, they don't use Java as is though. They mostly fight with the language, statically allocating all things in advance etc.
In that sense, one could also use Go. But that is a bleak argument.
In that sense, one could also use Go. But that is a bleak argument.
What? I never disagreed that Java is used for realtime embedded systems.
I'm aware of the existence of "real time Java". There can be such a thing because of specifications like " areas of memory that are not subject to garbage collection, along with threads that are not preemptable by the garbage collector" [1]. Like I said... guarantees....
[1] http://en.wikipedia.org/wiki/Real_time_Java
I'm aware of the existence of "real time Java". There can be such a thing because of specifications like " areas of memory that are not subject to garbage collection, along with threads that are not preemptable by the garbage collector" [1]. Like I said... guarantees....
[1] http://en.wikipedia.org/wiki/Real_time_Java
As I mentioned, Java was just the first example that came to my mind.
There are embedded systems being coded in Basic, Oberon, Lisp, Scheme and .NET.
Although those systems are usually 32 bit based. 8 and 16 bit systems are too small for those languages.
There are embedded systems being coded in Basic, Oberon, Lisp, Scheme and .NET.
Although those systems are usually 32 bit based. 8 and 16 bit systems are too small for those languages.
Also Ada, my favourite language.
Yes, Ada needs more love here. I think that Rust's main goals are already implemented with Ada (low-level, reliable, strong typing etc.). Plus that Ada is a proven work horse with existing tools and best practices. It just hasn't the C feeling they want in Rust.
My heart has a sweet spot for the Pascal family of languages and their strong typing, in regard to C and C++.
Ada suffered from lack of available cheap compilers back in the 80's, and like Turbo Pascal and Modula-2 it was a victim of UNIX's success, which had the sad side effect of promoting C for systems programming, with all security issues we have nowadays.
Now with the work of GNAT Core, and more security conscious developers, Ada seems to be getting new users, at least here in Europe as more universities adopt it. It is already a constant presence at FOSDEM in the last few years.
http://e.ubmelectronics.com/audience/eetnewsletters/02-19-20...
Ada suffered from lack of available cheap compilers back in the 80's, and like Turbo Pascal and Modula-2 it was a victim of UNIX's success, which had the sad side effect of promoting C for systems programming, with all security issues we have nowadays.
Now with the work of GNAT Core, and more security conscious developers, Ada seems to be getting new users, at least here in Europe as more universities adopt it. It is already a constant presence at FOSDEM in the last few years.
http://e.ubmelectronics.com/audience/eetnewsletters/02-19-20...
Yes, I wish that GNAT gets more adoption. Where appropriate I recommend Ada. It would be helpful to have some impressive and successful applications outside the high-integrity/reliability niche.
That's a good time to advertise for http://www.ada-europe2013.org/ in June. :)
That's a good time to advertise for http://www.ada-europe2013.org/ in June. :)
[deleted]
Sorry, typo regarding Clojure. Can't edit it anymore though :(
Go or Scala attempt to improve on Erlang? Elixir attempts to improve on Erlang---that I can see.
As much as I like Golang, it is not a replacement for C. The major reason C is so popular because it's the only portable medium for performant code which can be shared across many languages because it doesn't impose any runtime on you.
Go comes with a VM. It lives in its own world, it cannot live in the worlds of other VMs like C can. It's more like high-performance Python (or simpler+slower C++) optimized for concurrent network services.
I'd say that Rust and probably D are good candidates for replacing C.
Go comes with a VM. It lives in its own world, it cannot live in the worlds of other VMs like C can. It's more like high-performance Python (or simpler+slower C++) optimized for concurrent network services.
I'd say that Rust and probably D are good candidates for replacing C.
The greatest trick libc ever pulled was convincing the world it didn't exist.
Isn't libc just a set of libraries and therefore not considered a runtime environment? C does have a small runtime environment, but I'd say it's the existence of the function call stack, as well as the on_exit system that's built into the core language.
As well as things like floating point and large integer emulation, startup code, etc. __divdi3, for example, divides 64 bit integers on i386.
See /usr/lib/x86_64-linux-gnu/{crt1.o,crti.o,crtn.o,gcrt1.o,Mcrt1.o,Srct1.o}.
See /usr/lib/x86_64-linux-gnu/{crt1.o,crti.o,crtn.o,gcrt1.o,Mcrt1.o,Srct1.o}.
On Windows it's even called "Microsoft Visual C Run-Time" (MSVCRT): http://en.wikipedia.org/wiki/Windows_library_files#Msvcrt.dl...
I think your parent comment means runtimes in the sense of a garbage collector or other services that run concurrently with user code or are scheduled periodically, which will put you in a world of hurt if you touch one of their objects without asking its permissions and/or playing by its rules.
Well, it's so small compared to "real" runtimes, it might as well not exist.
You can compile C code without a libc.
Currently, Rust cannot go without its runtime either. The plan is that it eventually will be able to.
(EDIT: VM -> runtime)
(EDIT: VM -> runtime)
Neither Go nor Rust have a VM.
Yes, I meant 'runtime.' That's what I get for commenting without coffee... the parent's usage of 'VM' infected my comment.
The plan is that it eventually will be able to.
To expand upon that point, Rust is designed to allow the programmer to avoid garbage collection altogether, if the programmer chooses. I believe that makes feasible the idea of using a runtime-less subset of Rust in any application where C would have been traditionally used.
To expand upon that point, Rust is designed to allow the programmer to avoid garbage collection altogether, if the programmer chooses. I believe that makes feasible the idea of using a runtime-less subset of Rust in any application where C would have been traditionally used.
Yes, you can use a freestanding Rust in many domains. Freestanding is still a WIP, but we have examples like embedding Rust in Ruby that work today:
http://brson.github.com/2013/03/10/embedding-rust-in-ruby/
http://brson.github.com/2013/03/10/embedding-rust-in-ruby/
The only language that does not have a runtime is called Assembly.
And even in the case of CISC processors there might be microcode playing the role of a runtime.
Why don't people learn about compiler design nowadays?!
And even in the case of CISC processors there might be microcode playing the role of a runtime.
Why don't people learn about compiler design nowadays?!
In one sense, Assembly does have a runtime, provided by the kernel's system call interface, not to mention all the magic that the loader has to do to make libraries work.
Even the kernel has a runtime, in a less strict sense, provided by the BIOS and whatever CPU interrupts support it.
The only thing that a program can do without any "runtime" at all is warm up your desk.
Even the kernel has a runtime, in a less strict sense, provided by the BIOS and whatever CPU interrupts support it.
The only thing that a program can do without any "runtime" at all is warm up your desk.
> The only thing that a program can do without any "runtime" at all is warm up your desk.
+1 Funny
+1 Funny
>The only language that does not have a runtime is called Assembly. And even in the case of CISC processors there might be microcode playing the role of a runtime. Why don't people learn about compiler design nowadays?!
Because the C kind of runtime isn't what people regularly mean with the word "runtime" -- much less cpu microcode.
That said, does Forth have a runtime?
Because the C kind of runtime isn't what people regularly mean with the word "runtime" -- much less cpu microcode.
That said, does Forth have a runtime?
> That said, does Forth have a runtime?
It depends if you mean one of those Forth CPUs there were common in the 80's or the more standard Forth environment, both of which have nontheless runtimes.
Because in the end, you will be using a set of words besides the basic stack manipulation ones, those words are the runtime.
It depends if you mean one of those Forth CPUs there were common in the 80's or the more standard Forth environment, both of which have nontheless runtimes.
Because in the end, you will be using a set of words besides the basic stack manipulation ones, those words are the runtime.
Vala?
I wish the Vala folks would get going. 18 months ago, Vala, Go, and Rust were all possible native language successors to C++. (D was the fourth prospect.) But Vala has advanced so little, it's becoming an afterthought.
The web site is an afterhought that sits like an interloper on the GNOME site. The Windows distros are years old, etc. It's too bad. They had a good idea; they just failed to execute.
The web site is an afterhought that sits like an interloper on the GNOME site. The Windows distros are years old, etc. It's too bad. They had a good idea; they just failed to execute.
I agree. People mistake the fact "Some C people really like Go, for some of the same reasons they like C" for the falsehood "Go is a good candidate to replace C in the domains C it typically best for".
To be fair, with Rust it's more like
C++ -----
\
OCaml ------> Rust
/
Erlang --What does the language family tree look like with Go at the root?
C ---------------
\ \
(CSP) --> Limbo ----> Go
/
Modula ----------I'm not as familiar with Go, so I can't comment on that, specifically.
> C -> Go
Most of C's use cases, Go can't even remotely be used for. It's basically limited to the "network server" use case. It's not portable, it's not a linga franca (via FFI for non-C languages), it's not low-overhead, it's not runtime-less, ...
> Erlang -> (Go or Scala)
Yeah... no, especially not Go. In Erlang's inception, concurrency was first and foremost a tool for reliability (from its telecom roots where 1 = 0, so 1 server means the same as not having a server). Just about none of Erlang's reliability mechanisms are present in Go.
Most of C's use cases, Go can't even remotely be used for. It's basically limited to the "network server" use case. It's not portable, it's not a linga franca (via FFI for non-C languages), it's not low-overhead, it's not runtime-less, ...
> Erlang -> (Go or Scala)
Yeah... no, especially not Go. In Erlang's inception, concurrency was first and foremost a tool for reliability (from its telecom roots where 1 = 0, so 1 server means the same as not having a server). Just about none of Erlang's reliability mechanisms are present in Go.
> It's basically limited to the "network server" use case.
I've been using it to perform research. I also used it to build an X window manager. Neither are remotely close to a "network server" use case. In years past, I would have used C for both projects.
> Just about none of Erlang's reliability mechanisms are present in Go.
I certainly agree that Go shouldn't be viewed as a "better" Erlang, but Go does have green threads with M:N scheduling, which is a significant feature of Erlang. (As argued by Joe Armstrong himself.)
I've been using it to perform research. I also used it to build an X window manager. Neither are remotely close to a "network server" use case. In years past, I would have used C for both projects.
> Just about none of Erlang's reliability mechanisms are present in Go.
I certainly agree that Go shouldn't be viewed as a "better" Erlang, but Go does have green threads with M:N scheduling, which is a significant feature of Erlang. (As argued by Joe Armstrong himself.)
> Go does have green threads with M:N scheduling, which is a significant feature of Erlang.
And Go also has integers, a significant feature of C...
Goroutine's semantics and implementation are nothing like Erlang's processes: the latter are shared-nothing, preempted, monitorable and messageable whereas goroutines are shared-memory cooperative black holes.
Basically, the one and only commonality is that they're mapped M:N on OS threads, which is on par with comparing a wheelie bin and a CAT 797F on grounds that they both have 4 wheels.
And Go also has integers, a significant feature of C...
Goroutine's semantics and implementation are nothing like Erlang's processes: the latter are shared-nothing, preempted, monitorable and messageable whereas goroutines are shared-memory cooperative black holes.
Basically, the one and only commonality is that they're mapped M:N on OS threads, which is on par with comparing a wheelie bin and a CAT 797F on grounds that they both have 4 wheels.
> And Go also has integers, a significant feature of C...
So does every other language. Perhaps I need to be more explicit for you: Go does have green threads with M:N scheduling, which is a powerful feature of Erlang that most other languages do not have.
> Basically, the one and only commonality is that they're mapped M:N on OS threads, which is on par with comparing a wheelie bin and a CAT 797F on grounds that they both have 4 wheels.
I'm more convinced by Armstrong's argument [1] (and my own experience). Green threads enable a concurrent style of programming that is not viable in most other programming languages. (See also: Concurrent ML and Concurrent Haskell, although the former is not parallel.)
> Goroutine's semantics and implementation are nothing like Erlang's processes: the latter are shared-nothing, preempted, monitorable and messageable whereas goroutines are shared-memory cooperative black holes.
I have drawn on an important similarity between goroutines and Erlang processes. I did not dispute their differences, although I think your comparison is overly simplistic.
Also, you ignored my rebuttal to your claim that Go's "basically only use case is network servers." Any particular reason why?
[1] - http://www.guug.de/veranstaltungen/ffg2003/papers/ffg2003-ar...
So does every other language. Perhaps I need to be more explicit for you: Go does have green threads with M:N scheduling, which is a powerful feature of Erlang that most other languages do not have.
> Basically, the one and only commonality is that they're mapped M:N on OS threads, which is on par with comparing a wheelie bin and a CAT 797F on grounds that they both have 4 wheels.
I'm more convinced by Armstrong's argument [1] (and my own experience). Green threads enable a concurrent style of programming that is not viable in most other programming languages. (See also: Concurrent ML and Concurrent Haskell, although the former is not parallel.)
> Goroutine's semantics and implementation are nothing like Erlang's processes: the latter are shared-nothing, preempted, monitorable and messageable whereas goroutines are shared-memory cooperative black holes.
I have drawn on an important similarity between goroutines and Erlang processes. I did not dispute their differences, although I think your comparison is overly simplistic.
Also, you ignored my rebuttal to your claim that Go's "basically only use case is network servers." Any particular reason why?
[1] - http://www.guug.de/veranstaltungen/ffg2003/papers/ffg2003-ar...
> So does every other language
I dunno. Some obscure languages are float-only. There's one called ECMAscript which I hear gets used in a few places.
I dunno. Some obscure languages are float-only. There's one called ECMAscript which I hear gets used in a few places.
I know you're being sarcastic, but Lua [1] is a good couter-example to my generalization as well.
[1] - http://lua-users.org/wiki/NumbersTutorial
[1] - http://lua-users.org/wiki/NumbersTutorial
I thought about Lua, but figured that javascript would be a more compelling disproof by counterexample (the common wisdom being that "nobody" uses Lua).
edit: yes, I just edited this comment quickly in succession.
edit: yes, I just edited this comment quickly in succession.
Ironically, I use both quite heavily and still made the generalization :P
It's a funny old world.
The JavaScript one has stuck with me because it's another good example of the various camouflaged toe-stubbing obstacles left scattered about the design.
The JavaScript one has stuck with me because it's another good example of the various camouflaged toe-stubbing obstacles left scattered about the design.
ECMAscript and Go/C's use cases are almost disjoint.
> every other language
Generalisations are excellent sarcasm-bait.
Generalisations are excellent sarcasm-bait.
Not always. Sometimes generalisations can be useful.
Slightly Off Topic: Wasn't Rust suppose to be the codename or working name of the languages. Or Has Mozilla decide to simply use Rust as its official name?
I'm pretty sure Graydon always intended Rust to be the final name.
Never heard something about it being just a codename. Why would it be? Rust is quite nice itself and has already 1-2 years of being established.
It even makes sense as an faux-etymology.
Rust: because it's close to the metal and brings some breathing oxygen to the stale system's language arena...
It even makes sense as an faux-etymology.
Rust: because it's close to the metal and brings some breathing oxygen to the stale system's language arena...
I don't know the answer to that, but the problem may be that Rust is decent enough name to overcome any proposed name changes. I've always thought you should use implausible codenames for just this reason. It forces you to change it instead of just letting the codename establish itself by momentum. I've always assumed that's why Microsoft uses terrible codenames like "Longhorn".
When developing Java, Sun figured out a way around this.... which is how we ended up with the name Swing: https://blogs.oracle.com/thejavatutorials/entry/why_is_swing...
That must have backfired for the Fedora folks.
Great!
Time to upgrade.
Just as a side note, I am looking forward to the day I won't need to recompile LLVM as well.
Time to upgrade.
Just as a side note, I am looking forward to the day I won't need to recompile LLVM as well.
Call me a noob, but I have never been properly introduced to Rust. Does anyone know of a good article or walk through with pros, cons, and examples?
This isn't a tutorial, but I found pcwalton's explanation of memory management in rust[0] to be an excellent primer for the different allocation techniques in rust.
Learning the different types of pointers was a real pain point for me; so I'm very thankful for this post. Maybe it will help you out while you're learning!
[0]: http://pcwalton.github.com/blog/2013/03/18/an-overview-of-me...
Learning the different types of pointers was a real pain point for me; so I'm very thankful for this post. Maybe it will help you out while you're learning!
[0]: http://pcwalton.github.com/blog/2013/03/18/an-overview-of-me...
Anyone who found that post illuminating may also enjoy this general "Rust for C++ programmers" reference: https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmer...
The language is still changing so fast that nearly every resource that you'll find will be outdated. Your best bet is likely the official tutorial,[1] which probably doesn't contain too many references to deprecated features.
[1] http://static.rust-lang.org/doc/tutorial.html
[1] http://static.rust-lang.org/doc/tutorial.html
What parts of the language have been changing? And maybe to reduce the scope of that question a bit: are there any specific features that need to be solidified first before someone should bother learning Rust?
I am no language expert by any means, but I haven't had much trouble picking up Rust. In fact it's been a lot of fun. I've mostly used the official documentation [1](tutorial, manual, core/std reference). Sometimes I will have to look at some unit tests on the rust github source to see how something is used.
[1] http://www.rust-lang.org/
[1] http://www.rust-lang.org/
Recently the biggest breaking changes have been a large amount of syntax removed from the language: https://github.com/mozilla/rust/issues/4707
But, as far as I understand, the goal is to not change the syntax much from now, and actually get it 'frozen' by 0.7.
But, as far as I understand, the goal is to not change the syntax much from now, and actually get it 'frozen' by 0.7.
I started playing with it when 0.5 came out, and the changes that I've seen when I went with a pre-0.6 build are not what I would consider major. There are many of them, but most are either relatively minor syntactic issues or in darker corners of the language that I haven't needed to touch yet.
I wrote a 'book' (it's about 50 pages) you can read online called "Rust for Rubyists".
Two things: It's for 0.5 (I'll be updating it to 0.6 later today/tomorrow) and 'for Rubyists' means I assume you don't know anything about systems programming, there's very little that's Ruby-specific.
http://www.rustforrubyists.com/
Two things: It's for 0.5 (I'll be updating it to 0.6 later today/tomorrow) and 'for Rubyists' means I assume you don't know anything about systems programming, there's very little that's Ruby-specific.
http://www.rustforrubyists.com/
'for Rubyists' means I assume you don't know anything about systems programming, there's very little that's Ruby-specific.
Then put out the same book with a new title, "Rust for Pythonistas". Two books for the price of one!
Then put out the same book with a new title, "Rust for Pythonistas". Two books for the price of one!
I've thought about it. ;)
Primarily, this was an experiment in 'selling your byproducts'.[1] I'm already self-publishing a book on Hypermedia APIs[2], and the older system it was in couldn't handle my new requirements. I also wanted to learn Rust, and so I decided to just write it all down as I went. It also enabled me to get familiar enough with my new tooling that when it came time to port over DHAs, it wasn't bad at all.
So yes, doing the same thing 'for other languages' would be fun, and if Rust continues to take off, I might give it a shot. I'm already planning on writing more content for the book as I go; I've been working on a Rust buildpack for Heroku...
1: http://37signals.com/svn/posts/1620-sell-your-by-products 2: http://www.designinghypermediaapis.com/
Primarily, this was an experiment in 'selling your byproducts'.[1] I'm already self-publishing a book on Hypermedia APIs[2], and the older system it was in couldn't handle my new requirements. I also wanted to learn Rust, and so I decided to just write it all down as I went. It also enabled me to get familiar enough with my new tooling that when it came time to port over DHAs, it wasn't bad at all.
So yes, doing the same thing 'for other languages' would be fun, and if Rust continues to take off, I might give it a shot. I'm already planning on writing more content for the book as I go; I've been working on a Rust buildpack for Heroku...
1: http://37signals.com/svn/posts/1620-sell-your-by-products 2: http://www.designinghypermediaapis.com/
This is the best talk I've seen on Rust so far.
http://www.infoq.com/presentations/Rust
The tutorial is also pretty good (as are the supplemental tutorials), but they don't yet give you the full picture. For that you'll have to play and experiment and read some code.
You might start here for some code to read:
https://github.com/pcwalton/sprocketnes
http://www.infoq.com/presentations/Rust
The tutorial is also pretty good (as are the supplemental tutorials), but they don't yet give you the full picture. For that you'll have to play and experiment and read some code.
You might start here for some code to read:
https://github.com/pcwalton/sprocketnes
Previous discussion just 3 days back: https://news.ycombinator.com/item?id=5468896
[This was for RC though]
[This was for RC though]
`Static methods no longer require the `static` keyword and instead are distinguished by the lack of a `self` parameter`
Man, am I the only one who really doesn't like implicit things like this?
Man, am I the only one who really doesn't like implicit things like this?
This change improves consistency between implementations and modules. `impl MyType { … }` is now just like `mod my_module { … }`, except that you can define methods inside `impl` declarations by including a self parameter.
For example:
For example:
struct MyType { … }
impl MyType { pub fn foo() { … } }
mod my_module { pub fn foo() { … } }
fn main() {
MyType::foo(); // works
my_module::foo(); // works too
}Well, it does kind of make sense. If you never access anything from self then for all intent and purposes there is no reason the function shouldn't be static. That's just my initial perspective reading your comment, not knowing much about the language, so I might be missing some possible scenario this would actually result in a runtime error.
[deleted]
Actually I think its much more explicit that self is ALWAYS passed as a parameter, or it doesn't exist.
Your comment is funny since the other part of the change you cited is the introduction of explicit self.
Just glanced at the discussion on LtU http://lambda-the-ultimate.org/node/4009, I wonder if the C++ hackers have swallowed, and if they are hearding them onto Haskell?
That discussion is very old.
Quite, but I generally use as a way to gauge "language innovation" relevance. It looks like the lag time on getting into innovative programming principles into production languages is ~5 years. The discussion is quite interesting in laying out some of the practical issues with introducing PL research concepts into code that must support large products and large developer bases.
Yeah, seems good. I was just excited for a new discussion, then saw that it was from a while back, and given how much Rust has changed in the meantime, wanted to make sure others didn't think it was new.
If you see mention of "typestate" in Rust, the discussion is probably so far out of date as to be useless in learning Rust as it is now.
Awesome! I'm going to compile `release-0.6` right now, because I've been having some issues w/ trunk these past few days.
Simple things like declaring fixed vectors won't compile for me: `let numbers: ~[int, ..3] = [1,2,3];` fails to compile saying it expected `~[int * 3] and got ~[<VI2>]`. That's an example straight from the tutorial.
I'm getting segfaults when iterating over a non-fixed vector of owned elements casted to a trait. (This works fine if I access the elements directly; or use managed pointers. With owned pointers my `len()` method returns the wrong number of elements, which I suspect is breaking the iterators.)
Simple things like declaring fixed vectors won't compile for me: `let numbers: ~[int, ..3] = [1,2,3];` fails to compile saying it expected `~[int * 3] and got ~[<VI2>]`. That's an example straight from the tutorial.
I'm getting segfaults when iterating over a non-fixed vector of owned elements casted to a trait. (This works fine if I access the elements directly; or use managed pointers. With owned pointers my `len()` method returns the wrong number of elements, which I suspect is breaking the iterators.)
The tutorial examples are run as part of the test suite. The tutorial example in question is `let numbers: [int, ..3] = [1, 2, 3];`, which should work.
There are several known compiler bugs with any trait types other than `@Trait`. Please do continue to file any bugs you find, though—all crash bugs are bugs that need to be fixed :)
There are several known compiler bugs with any trait types other than `@Trait`. Please do continue to file any bugs you find, though—all crash bugs are bugs that need to be fixed :)
Whoops, I did botch up the syntax on my listed example.
I compiled release-0.6; and sure enough `let numbers: [int, ..3] = [1,2,3];` compiles.
`let numbers: ~[int, ..3] = ~[1,2,3];` does not compile on my system though. Ditto for the @ sigil.
(Expected `~[int * 3] but found ~[<VI2>]`)
My understanding is that the first example [from the docs] allocates the vector on the stack.
My uncompilable examples should be equivalent except that they use the heap for storage.
Is there a reason this shouldn't compile?
Thanks so much for the reply!
I compiled release-0.6; and sure enough `let numbers: [int, ..3] = [1,2,3];` compiles.
`let numbers: ~[int, ..3] = ~[1,2,3];` does not compile on my system though. Ditto for the @ sigil.
(Expected `~[int * 3] but found ~[<VI2>]`)
My understanding is that the first example [from the docs] allocates the vector on the stack.
My uncompilable examples should be equivalent except that they use the heap for storage.
Is there a reason this shouldn't compile?
Thanks so much for the reply!
In fact you just want:
let numbers: ~[int] = ~[1,2,3];
I was thinking you might have a function that operates on some fixed length vector.
For e.g: `fn foo(bar: ~[int, ..3]) { ... }`, and the compiler would enforce that you only pass vectors of length 3 to that function.
But since I can't get `~[int, ..3] = ~[1,2,3]` (etc.) to compile that seems to be impossible w/ vectors on the heap?
For e.g: `fn foo(bar: ~[int, ..3]) { ... }`, and the compiler would enforce that you only pass vectors of length 3 to that function.
But since I can't get `~[int, ..3] = ~[1,2,3]` (etc.) to compile that seems to be impossible w/ vectors on the heap?
I believe you can't do that. You can, however, make a function that only operates on 3-tuples:
fn foo(bar: (int, int, int)) { ... }
fn foo(bar: (int, int, int)) { ... }
From the release notes[1]:
1: https://github.com/mozilla/rust/wiki/Doc-detailed-release-no...
> While we cannot promise that this is the last time there will be incompatible
> changes, the great majority of anticipated language-level changes are
> complete in this version
1: https://github.com/mozilla/rust/wiki/Doc-detailed-release-no...
The most exciting thing about Rust is that we keep seeing something that's already pretty good continually getting better and better.
This is much different than what we're seeing with the evolution of, say, JavaScript or PHP. There, the languages are pretty horrific to begin with. Any "improvements" tend to be yet another hack layered upon one or more earlier hacks. Even in the best cases, these "improvements" are merely bringing JavaScript and PHP to where many other languages were 10 or 20 years ago (if not going back much earlier).
I think the fact that Rust is already so coherent makes these improvements and refinements much more impressive. It's much harder, and requires more real innovation, to improve something that's already great to begin with. Yet that's exactly what we're seeing with Rust.
This is much different than what we're seeing with the evolution of, say, JavaScript or PHP. There, the languages are pretty horrific to begin with. Any "improvements" tend to be yet another hack layered upon one or more earlier hacks. Even in the best cases, these "improvements" are merely bringing JavaScript and PHP to where many other languages were 10 or 20 years ago (if not going back much earlier).
I think the fact that Rust is already so coherent makes these improvements and refinements much more impressive. It's much harder, and requires more real innovation, to improve something that's already great to begin with. Yet that's exactly what we're seeing with Rust.
Much more exciting thing about Rust is that it is actively moving to reduce the language features. At the version 0.1 I was literally shocked about the typestate system ("It is a good idea but I don't know how this feature will end up!") but it is now replaced by other features (owned pointers in this case) more fundamental and more easier to reason. As an wannabe language designer I understand this is very hard to undertake, and I'm appreciate all these works by Rust team and contributors. :)
I can't help myself. You were literally shocked?
Uhm, no, I exaggerated the fact a bit. But I certainly spewed a drink.
Maybe if you sprayed onto a badly-insulated keyboard, you could create a short circuit through your fingers, and be both metaphorically and literally shocked, as well as having literally spewed.
I was theoretically shocked.
Since "shocked" is a synonym of "surprised" / "startled", I think literally is fair in this case. I'd believe that he was literally surprised by the news!
Also, one common usage of "literally" is to describe a figurative or hyperbolic phrase. This usage is well over a century old, and I doubt you can find an English dictionary which does not contain it.
Perhaps you are one of those semi-informed people that don't know the definition of "literally" and go around bothering folks with ill-conceived pedantry?
From dictionary.com:
1. in the literal or strict sense: What does the word mean literally? 2. in a literal manner; word for word: to translate literally. 3. actually; without exaggeration or inaccuracy: The city was literally destroyed. 4. in effect; in substance; very nearly; virtually.
Notice definition #4.
From dictionary.com:
1. in the literal or strict sense: What does the word mean literally? 2. in a literal manner; word for word: to translate literally. 3. actually; without exaggeration or inaccuracy: The city was literally destroyed. 4. in effect; in substance; very nearly; virtually.
Notice definition #4.
What "improvements" are you seeing with Javascript? The language is essentially done; all improvements I've seen come in the form of new libraries (jquery et al), environments (v8/nodejs), or revisions (jsnext, asmjs) that IE won't ever adopt.
>What "improvements" are you seeing with Javascript?
Harmony (ES6). Isn't it obvious?
>or revisions (jsnext, asmjs) that IE won't ever adopt.
Seeing that MS caught up in the Javascript JIT game, offer Node.js for Azure, and added HTML5 features, SVG, CSS transformations and even WebGL in the latest IE head why would you say they'll never adopt JsNext?
Heck, even them adopting asm.js is not much of a stretch.
Harmony (ES6). Isn't it obvious?
>or revisions (jsnext, asmjs) that IE won't ever adopt.
Seeing that MS caught up in the Javascript JIT game, offer Node.js for Azure, and added HTML5 features, SVG, CSS transformations and even WebGL in the latest IE head why would you say they'll never adopt JsNext?
Heck, even them adopting asm.js is not much of a stretch.
Everyone I know is really excited for ES6.
This is how you do an announcement right: you include a short description of the product along with the announcement. This way people who don't know WTF Rust is are immediately brought up to speed.