14 ms·

Rust Priorities after 1.0

hanlec 11y ago
After using Go for a couple of pet projects in the last couple of months, I came out bored. Many people seem to be quite excited about Rust. I'm setting up my (new) Emacs end for Rust. Any cool projects I can take a look at?
- malkia 11y ago
  Servo. Seriously that was the first one I took, and compiled, and kept on reading (not that I understand a lot of it)
- andrewchambers 11y ago
  The problem with rust is that it has been around for nearly as long as Go, yet is nowhere near stable or production ready in nearly every aspect. Go has been ready for years.
  - arthursilva 11y ago
    Well, once you compare both languages you can see why. Hint: inovation/complexity (not that either is a good or bad thing). Anyway, that's only one possible reason... I think Go is actually 2 years older.
    - andrewchambers 11y ago
      Go hasn't changed much from its initial versions, iirc rust is unrecognizable compared to early versions. Rust didn't know what it wanted to be from the start. I wanted to give rust a crack years ago, but I am glad I didn't because it would have required constant updates for anything serious.
      - dbaupp 11y ago
        Go hasn't changed much from its initial released version, or initial internal version? As I understand it, Go was released in a much more final state, whereas Rust was developed in the open from very very early. Rust has always known what it wanted to be, it has just taken a while to find the best way to actually fill that goal. That isn't really a fundamental problem with the language (in fact, I see the constant iteration and change as a good thing: the language was developed empirically, removing features that didn't work/pull their weight, adding ones that did), although it is definitely a good reason for people to have not used Rust historically. In any case, this discussion seems like a non-sequitur: whether Go is boring to hanlec or not is orthogonal to whether Go is more stable than Rust or not. The fact that a language has been stable for years rather than only just now approaching stability might be something you value highly, but clearly hanlec has a different utility function.
        andrewchambers 11y ago
        Go hasn't changed much, because it is the natural extension of plan9 C and other languages from the past. If you look at the project layout of the plan9 source tree, it matches the Go project layout now. I think plan9 C even used CSP channels in the form of a C library for most of the servers. They just took what they already knew worked, and tried to polish it and add garbage collection. Rust is trying many things at once then letting things die off as they prove useless.
        dbaupp 11y ago
        > Rust is trying many things at once then letting things die off as they prove useless. Yes, this is perfectly true. I cannot tell from your phrasing whether you think experimentation, learning from experience and removal of pointless code is good or bad. I personally think all of those are good, but you're perfectly entitled to differ. Go was designed with the lessons learned and experienced gained from plan9, Rust was designed with the lessons learned and experienced gained from iterating on Rust itself. Seems pretty similar. :)
        11y ago
  - oldmanjay 11y ago
    of course, if you're interested in rust's memory safety, performance, low-level control, and expressive type system, then in a very real way, go isn't ready at all. it does have some marquee names behind it, though. I suppose if you squint, that can make up the difference.
    - andrewchambers 11y ago
      Go performance is going to converge on C performance with new optimization's being written after go 1.5. Any gains from rusts expressive type system are lost by all the memory lifetime annotations imo. I still think rust is probably going to be the best language for embedded software like router firmware, as they need to be fast, low overhead and secure.
      - seanmcdirmid 11y ago
        As an upper performance bound for a GC language, I don't think Go will be able to surpass C# (which has stack allocation in the form of structs, ahead of time compilation, and many other goodies). Rust, on the other hand, has more potential as a non GC language, though at the end of the day it might be hard to tell given equivalent applications.
        andrewchambers 11y ago
        The upper performance for garbage collected languages (and rust) is potentially higher than C. The reasons are non aliased pointers allow more aggressive optimization, and batched garbage collection plus memory compaction can perform better than regular mallocs. Rust still has these advantages though, time will tell. Does rust have a way to avoid bounds checks on arrays? I suppose that requires unsafe annotations.
        kibwen 11y ago
        Rust essentially never wastes cycles on bounds checking thanks to the design of its iterators. The Servo team tells me that bounds checking has never shown up in any performance profiles.
  - kibwen 11y ago
    Rob Pike has been working on Go's design since Newsqueak in the 90s, and further explored the same space later with Limbo. For reference, Newsqueak is a C-inspired language that features CSP for concurrency (which should sound familiar to Go programmers). Here's some example syntax (which should look familiar to Go programmers): a := mk(array[10] of int) Given this lineage, it seems disingenuous to compare the ages of the two languages. Modern Rust is to early Rust as Go is to Newsqueak.
    - andrewchambers 11y ago
      This is true, but it does confirm my point about language flux potentially being a problem. It may work out nicely though.
      - kibwen 11y ago
        Indeed, it may ultimately turn out that modern Rust is to early Rust as Limbo (rather than Go) is to Newsqueak. I expect Rust will experience growing pains over the next few years as people begin employing it on an industrial scale and discover where the dark corners of the language lie. But nobody's saying that Rust will be the last systems programming language to ever be written. :)
  - tatterdemalion 11y ago
    This comment is very strange. Go was made public when it was stable (or maybe shortly before?), Rust was made public long before it was. Rust will be stable in 4 weeks, Go was stable several years ago. So what? If we judged languages by how early they were stable, we would all be writing Fortran 57, Algol 58, and COBOL 60.
    - andrewchambers 11y ago
      I'm not judging the language, I'm just warning people to be careful in choosing to build a product with it. The team still seems to be changing stuff like crazy even after the "stable beta" release.
      - dbaupp 11y ago
        I think you have the wrong impression about the recent changes, e.g. a recent "regression report"[1] found only two regressions between nightly and the original released beta. Furthermore, several changes have been rejected due to being breaking. The team is seriously committed to stability. [1]: http://internals.rust-lang.org/t/regression-report-beta-2015-04-03-vs-nightly-2015-04-10/1860 http://internals.rust-lang.org/t/regression-report-beta-2015...
        andrewchambers 11y ago
        You can be sure if more people used rust, there would be many more detected breakages. The undetected ones are more worrying. I get that the language is a beta, but be warned. One example I saw - http://internals.rust-lang.org/t/memcpy-is-backwards/1797 http://internals.rust-lang.org/t/memcpy-is-backwards/1797
        dbaupp 11y ago
        Breaks during beta that are not detected seem fine to me: people were not using the feature, and the improvement/bug fix could land without issue. That particular change caused heartache, yes, but it was purposely made before the beta release, exactly because it was breaking.
- deleted 11y ago
  [deleted]
- jmilloy 11y ago
  Is there a law for this yet? It seems like any time I see discussion about Rust, over half of the discussion is actually about Go.
  - kibwen 11y ago
    Likewise, in any discussion about Go on HN half of the discussion will be about Rust. A truly bewildering phenomenon. Would anyone like to compare Rust to ATS instead? Maybe Erlang? Anybody??
    - dorfsmay 11y ago
      Rust: ATS for the rest of us!
    - doublec 11y ago
      I can help with a Rust vs ATS. ATS is more like a safe version of C wrapped in ML syntax vs Rust as a safe version of C++. ATS is lower level. You can do memory safe pointer arithmetic whereas in Rust you'd use unsafe blocks. Some things are implicit in Rust but explicit (and more verbose) in ATS. For example, Rust has destructors for RAII whereas ATS requires manually calling functions to clean up resources. The type checker tells you when you need to do this (via linear types) but programmer still needs to do the call. Borrowing is automatic in Rust. In ATS it requires keeping track of borrows in proof variables and manually giving them back. Again the type checker tells you when you get it wrong but it's more verbosity. ATS has a restricted form of dependent types - Rust is not dependently typed. With current implementations, ATS compiles to C which can be compiled independantly of an ATS install. You can ship the C code to someone to build without them needing ATS. Rust uses LLVM. The two languages feel very differently when programming.
      - kibwen 11y ago
        This is awesome, I'm so happy to finally hear from somebody with experience in ATS. :) > For example, Rust has destructors for RAII whereas ATS > requires manually calling functions to clean up > resources. This especially intrigues me, as recent events have shaken my faith a little in RAII. Who knows, maybe Rust will one day regret not embracing linear types wholeheartedly...
- aikah 11y ago
  I wonder why each time there is a news on Rust, people somehow manage to talk about Go in a negative fashion? At that point it's just trolling. Go is mentioned 45 times in that thread about Rust...
  - oscargrouch 11y ago
    And Rust are almost-always mentioned in threads about Go :)
  - unfamiliar 11y ago
    They are the two new systems languages on the block, which take quite different approaches. It makes perfect sense that they would be compared often. There are plenty of people in this thread also complaining about aspects of Rust and its development.
    - xiaq 11y ago
      Except that go is hardly a "new" system language.
      - unfamiliar 11y ago
        It's 6 years old as opposed to 43 years old, I would call that new.
      - apta 11y ago
        Or even a "system" language :-)
  - thuffy 11y ago
    Because there is a battle going on. The lines are being drawn. People who where fighting this battle will see this happening before those who were unaware to start with; however, the lines are now being drawn thanks to Edward Snowden, and this battle is becoming visible to all. Meaning: GO was dead at birth from out of the sphincter of the NSA.
rck 11y ago
Does "ARM support" include bare-metal arm at all? I know there are several projects that move in that direction, but it's not obvious to me how mature they are relative to the rest of Rust (granting that everything in the ecosystem is in an early state)...
- kibwen 11y ago
  Rust exists to support Servo, and Servo's most important platform may very well be Android. I expect that Rust will see a lot of interest by hobbyists who hack the compiler to work with various fringe platforms, but in terms of official support I wouldn't expect Mozilla and Samsung to contribute anything beyond what's required for Android.
  - shmerl 11y ago
    I hope Servo will be important for non Android mobile Linux as well.
    - sinistersnare 11y ago
      Rust builds for straight up ARM, see https://zinc.rs/ https://zinc.rs/ Now we only need to dependencies for Servo to move along and it could work. I would imagine this would be a lot of work for the OpenGL implementation they use.
      - shmerl 11y ago
        I should try building Rust with Mer SDK. Would be useful for Nemo, Sailfish and Plasma Active. Weren't Samsung also working on Servo? Did they consider it for Tizen as well?
      - higherpurpose 11y ago
        They should keep in mind that the Vulkan API is also coming soon, and I imagine it will be integrated in Android 7.0 next year.
  - ZeroGravitas 11y ago
kibwen 11y ago
I think one thing that we need to emphasize is that Rust 1.0 does not indicate that we think the language is "complete". It is merely the result of recognition that getting to that "complete" state can, as of very soon, be done in a stable and backwards-compatible fashion. I expect the post-1.0 releases to see a flurry of activity as we flesh out deficiencies in existing features and add new features to address pain points, but over time the rate of feature growth will slow. Rust has no intention of becoming a ball-of-mud programming language.
- mook 11y ago
  Hi! I'm sure you get asked this a lot, but it wasn't found in a quick skim of the FAQs, so: How long do you (the Rust community) expect Rust to remain backwards-compatible? That is, once 1.0 ships, on what sort of approximate timescale would significant effort be made to ensure code that worked with the initial release (assuming no experimental features / libraries in use) would keep working? On the order of months, years, decades? I'm interested in writing some random things in Rust, but very much not interested in _re_writing Rust code in newer Rust. This probably means it's still too early for me, if the standard library is expected to expand soon after 1.0. But given e.g. the prevalence of Python 2 versus Python 3, it seems like there's quite a lot of people who think similarly. Background: I used to write Firefox extensions and things like that. Stopped being active around Firefox 4, when they declared that they are fine with breaking backwards API compatibility (and, IIRC around that time or soon after, put in arbitrary checks to force recompilation). This was just before the short releases started.
  - fjh 11y ago
    > I'm interested in writing some random things in Rust, but very much not interested in _re_writing Rust code in newer Rust. This probably means it's still too early for me, if the standard library is expected to expand soon after 1.0. Why would you have to rewrite code because of an expanding std lib?
  - Manishearth 11y ago
    > How long do you (the Rust community) expect Rust to remain backwards-compatible? The hope is for all of 1.*. I forget what the plan is for 2.0, but I think we want to keep things the same (mostly). In practice there will be minor breakages due to unavoidable bugfixes. Expanding the stdlib will never break your code. All changes now are being made with backcompat in mind; older code should never have to update.
LVB 11y ago
I really wish better Windows support was available now. Solid cross-platform support has allowed me to move some Python code to go. My attempts to do the same with Rust have been failures, on multiple occasions, but as recently as their 1.0 beta and nightlies (both 32/64 bit were tried). After giving it a few hours with the IRC channel riding shotgun and hello_world.rs still crashing on Windows, I've again hit snooze of Rust. A pity too... I am quite re-interested after seeing some Rust demos/discussion at PyCon.
- kibwen 11y ago
  One of the difficulties is that we really need a Windows platform expert, but they are remarkably elusive. Bit of a chicken/egg problem. Hey you reading this! Yeah, you! If you happen to be an expert in integrating native compilers with MSVC, we desperately need your help!
  - moomin 11y ago
    Not to be funny, but you've been saying this for years now. Might be time to either give up on windows or accept you're going to have to make your own experts.
    - kibwen 11y ago
      Worst-case scenario is that Mozilla lends us some of their Windows experts when it's time to integrate Rust components into Firefox (which uses MSVC) later this year. But that's not a satisfying answer to people who want to develop on Windows today!
- unethical_ban 11y ago
  "cargo new helloworld ; cargo run" doesn't work for you in Windows? I did some REALLY REALLY MINOR code in Windows before doing it on Ubuntu, and I had no issues dependent on OS.
  - kibwen 11y ago
    I'm guessing that the parent poster was trying to do a "hello world" equivalent of calling Rust from Python (as per the Pycon presentation), which would definitely cause grief on Windows if Python isn't compiled with the same toolchain that Rust is.
choward 11y ago
For a language that was written by Mozilla, I find it very annoying that they steal my browser's built-in ctrl+f functionality that I'm perfectly fine with using. Also, my vimium plugin doesn't work. This is the first time I've encountered something like this. This better not become a thing.
- tatterdemalion 11y ago
  This is a comment on http://www.discourse.org/ http://www.discourse.org/ , the software used to drive the internals.rust-lang.org forum, which is not written in Rust nor developed by Mozilla.
- kibwen 11y ago
  The forum software has nothing to do with either Rust or Mozilla. It's Discourse ( http://www.discourse.org/ http://www.discourse.org/ ), and personally I agree that it's kind of a pain. :)
  - mkesper 11y ago
    Please use something different. Something utterly broken like this (keyboard navigation?) casts a bad light on a project that's - at least mentally - connected to Mozilla.
Animats 11y ago
From the proposals: "Perhaps the biggest is the lack of "privacy" or "unsafety" hygiene (meaning that it's not possible to define macros that have privileged access over normal code). This prevents macros from being used to define abstraction barriers." That may be a misfeature. One would like to reduce the need for unsafe code, not make it easier to write unsafe code. Unless you're talking to hardware or another language, you should not need unsafe code. If you do, the language has a problem. I'd suggest identifying each use of unsafe code in a large system and then looking at why it was necessary. It's important to keep Rust from going off into template la-la land, as C++ did. C++ generics are starting out with roughly the complexity level it took C++ two decades to achieve. Try to keep the metaprogramming fanatics from driving the language design, please. That doesn't end well.
- tatterdemalion 11y ago
  I'm not sure what Niko Matsakis means by that comment, but I think it is not exactly about the `unsafe { }` block kind of unsafety. Nothing about the macro_rules! system right now stops you from writing an `unsafe { }` block inside a macro_rules! macro.
  - lomnakkus 11y ago
    The wording makes me think that's it's purely about allowing non-hygienic macros[1] in some sensible way. (At least a quick glance at the Rust book/manual suggests that macros are always hygienic in Rust.) Hygiene is a good default, but it does prevent certain other useful uses of macros. [1] http://en.wikipedia.org/wiki/Hygienic_macro http://en.wikipedia.org/wiki/Hygienic_macro
    - dbaupp 11y ago
      It's the opposite: macros currently leak their internals in certain circumstances with unsafe and privacy/name resolution, i.e. are slightly non hygienic (they are properly hygienic with respect to local variables, which is the major advantage of hygiene). The changes would make macros more hygienic in those aspects.
- 11y ago
aidenn0 11y ago
I'm glad specialization is listed as a Top Priority; it's something that I've wanted in Rust for about 2 years nos.
da4c30ff 11y ago
I wish I could use 'type' as a variable name or as a field on a struct. It's one of the most used identifier names and the inability to use it is frustrating.
- heinrich5991 11y ago
  You could sidestep it like Python does, adding an underscore after variables that are named the same as keywords (e.g. `type_`).
amelius 11y ago
I wonder if Rust would support something like the following. Say, I have a mmapped file, and in this file I'd like to store data-structures such as maps, sets, lists, etc. Basically, they are the same data-structures as one would use on the heap. Because the mmapped file is offsetted at a different point in memory every time it is opened, the actual pointers used to access these data-structures will be different every time. But the pointers inside the data-structures will be the same every time the file is mmapped. So, this requires some special pointer arithmetic (and perhaps a special type system). It would definitely be a very interesting and useful feature!
thuffy 11y ago
LOL, the new Godwin's Law: Edward Snowden. (See my valid but then NSA downvoted answer to the question below regarding GO vs. Rust that no one else could answer and were forced to make jokes about -- if you are wondering what I mean.) Sorry rust thread. :( (now kicked off the front page)

After using Go for a couple of pet projects in the last couple of months, I came out bored. Many people seem to be quite excited about Rust. I'm setting up my (new) Emacs end for Rust. Any cool projects I can take a look at?

malkia 11y ago
Servo. Seriously that was the first one I took, and compiled, and kept on reading (not that I understand a lot of it)
andrewchambers 11y ago
The problem with rust is that it has been around for nearly as long as Go, yet is nowhere near stable or production ready in nearly every aspect. Go has been ready for years.
- arthursilva 11y ago
  Well, once you compare both languages you can see why. Hint: inovation/complexity (not that either is a good or bad thing). Anyway, that's only one possible reason... I think Go is actually 2 years older.
  - andrewchambers 11y ago
    Go hasn't changed much from its initial versions, iirc rust is unrecognizable compared to early versions. Rust didn't know what it wanted to be from the start. I wanted to give rust a crack years ago, but I am glad I didn't because it would have required constant updates for anything serious.
    - dbaupp 11y ago
      Go hasn't changed much from its initial released version, or initial internal version? As I understand it, Go was released in a much more final state, whereas Rust was developed in the open from very very early. Rust has always known what it wanted to be, it has just taken a while to find the best way to actually fill that goal. That isn't really a fundamental problem with the language (in fact, I see the constant iteration and change as a good thing: the language was developed empirically, removing features that didn't work/pull their weight, adding ones that did), although it is definitely a good reason for people to have not used Rust historically. In any case, this discussion seems like a non-sequitur: whether Go is boring to hanlec or not is orthogonal to whether Go is more stable than Rust or not. The fact that a language has been stable for years rather than only just now approaching stability might be something you value highly, but clearly hanlec has a different utility function.
      - andrewchambers 11y ago
        Go hasn't changed much, because it is the natural extension of plan9 C and other languages from the past. If you look at the project layout of the plan9 source tree, it matches the Go project layout now. I think plan9 C even used CSP channels in the form of a C library for most of the servers. They just took what they already knew worked, and tried to polish it and add garbage collection. Rust is trying many things at once then letting things die off as they prove useless.
        dbaupp 11y ago
        > Rust is trying many things at once then letting things die off as they prove useless. Yes, this is perfectly true. I cannot tell from your phrasing whether you think experimentation, learning from experience and removal of pointless code is good or bad. I personally think all of those are good, but you're perfectly entitled to differ. Go was designed with the lessons learned and experienced gained from plan9, Rust was designed with the lessons learned and experienced gained from iterating on Rust itself. Seems pretty similar. :)
        11y ago
- oldmanjay 11y ago
  of course, if you're interested in rust's memory safety, performance, low-level control, and expressive type system, then in a very real way, go isn't ready at all. it does have some marquee names behind it, though. I suppose if you squint, that can make up the difference.
  - andrewchambers 11y ago
    Go performance is going to converge on C performance with new optimization's being written after go 1.5. Any gains from rusts expressive type system are lost by all the memory lifetime annotations imo. I still think rust is probably going to be the best language for embedded software like router firmware, as they need to be fast, low overhead and secure.
    - seanmcdirmid 11y ago
      As an upper performance bound for a GC language, I don't think Go will be able to surpass C# (which has stack allocation in the form of structs, ahead of time compilation, and many other goodies). Rust, on the other hand, has more potential as a non GC language, though at the end of the day it might be hard to tell given equivalent applications.
      - andrewchambers 11y ago
        The upper performance for garbage collected languages (and rust) is potentially higher than C. The reasons are non aliased pointers allow more aggressive optimization, and batched garbage collection plus memory compaction can perform better than regular mallocs. Rust still has these advantages though, time will tell. Does rust have a way to avoid bounds checks on arrays? I suppose that requires unsafe annotations.
        kibwen 11y ago
        Rust essentially never wastes cycles on bounds checking thanks to the design of its iterators. The Servo team tells me that bounds checking has never shown up in any performance profiles.
- kibwen 11y ago
  Rob Pike has been working on Go's design since Newsqueak in the 90s, and further explored the same space later with Limbo. For reference, Newsqueak is a C-inspired language that features CSP for concurrency (which should sound familiar to Go programmers). Here's some example syntax (which should look familiar to Go programmers): a := mk(array[10] of int) Given this lineage, it seems disingenuous to compare the ages of the two languages. Modern Rust is to early Rust as Go is to Newsqueak.
  - andrewchambers 11y ago
    This is true, but it does confirm my point about language flux potentially being a problem. It may work out nicely though.
    - kibwen 11y ago
      Indeed, it may ultimately turn out that modern Rust is to early Rust as Limbo (rather than Go) is to Newsqueak. I expect Rust will experience growing pains over the next few years as people begin employing it on an industrial scale and discover where the dark corners of the language lie. But nobody's saying that Rust will be the last systems programming language to ever be written. :)
- tatterdemalion 11y ago
  This comment is very strange. Go was made public when it was stable (or maybe shortly before?), Rust was made public long before it was. Rust will be stable in 4 weeks, Go was stable several years ago. So what? If we judged languages by how early they were stable, we would all be writing Fortran 57, Algol 58, and COBOL 60.
  - andrewchambers 11y ago
    I'm not judging the language, I'm just warning people to be careful in choosing to build a product with it. The team still seems to be changing stuff like crazy even after the "stable beta" release.
    - dbaupp 11y ago
      I think you have the wrong impression about the recent changes, e.g. a recent "regression report"[1] found only two regressions between nightly and the original released beta. Furthermore, several changes have been rejected due to being breaking. The team is seriously committed to stability. [1]: http://internals.rust-lang.org/t/regression-report-beta-2015-04-03-vs-nightly-2015-04-10/1860 http://internals.rust-lang.org/t/regression-report-beta-2015...
      - andrewchambers 11y ago
        You can be sure if more people used rust, there would be many more detected breakages. The undetected ones are more worrying. I get that the language is a beta, but be warned. One example I saw - http://internals.rust-lang.org/t/memcpy-is-backwards/1797 http://internals.rust-lang.org/t/memcpy-is-backwards/1797
        dbaupp 11y ago
        Breaks during beta that are not detected seem fine to me: people were not using the feature, and the improvement/bug fix could land without issue. That particular change caused heartache, yes, but it was purposely made before the beta release, exactly because it was breaking.
deleted 11y ago
[deleted]
jmilloy 11y ago
Is there a law for this yet? It seems like any time I see discussion about Rust, over half of the discussion is actually about Go.
- kibwen 11y ago
  Likewise, in any discussion about Go on HN half of the discussion will be about Rust. A truly bewildering phenomenon. Would anyone like to compare Rust to ATS instead? Maybe Erlang? Anybody??
  - dorfsmay 11y ago
    Rust: ATS for the rest of us!
  - doublec 11y ago
    I can help with a Rust vs ATS. ATS is more like a safe version of C wrapped in ML syntax vs Rust as a safe version of C++. ATS is lower level. You can do memory safe pointer arithmetic whereas in Rust you'd use unsafe blocks. Some things are implicit in Rust but explicit (and more verbose) in ATS. For example, Rust has destructors for RAII whereas ATS requires manually calling functions to clean up resources. The type checker tells you when you need to do this (via linear types) but programmer still needs to do the call. Borrowing is automatic in Rust. In ATS it requires keeping track of borrows in proof variables and manually giving them back. Again the type checker tells you when you get it wrong but it's more verbosity. ATS has a restricted form of dependent types - Rust is not dependently typed. With current implementations, ATS compiles to C which can be compiled independantly of an ATS install. You can ship the C code to someone to build without them needing ATS. Rust uses LLVM. The two languages feel very differently when programming.
    - kibwen 11y ago
      This is awesome, I'm so happy to finally hear from somebody with experience in ATS. :) > For example, Rust has destructors for RAII whereas ATS > requires manually calling functions to clean up > resources. This especially intrigues me, as recent events have shaken my faith a little in RAII. Who knows, maybe Rust will one day regret not embracing linear types wholeheartedly...
aikah 11y ago
I wonder why each time there is a news on Rust, people somehow manage to talk about Go in a negative fashion? At that point it's just trolling. Go is mentioned 45 times in that thread about Rust...
- oscargrouch 11y ago
  And Rust are almost-always mentioned in threads about Go :)
- unfamiliar 11y ago
  They are the two new systems languages on the block, which take quite different approaches. It makes perfect sense that they would be compared often. There are plenty of people in this thread also complaining about aspects of Rust and its development.
  - xiaq 11y ago
    Except that go is hardly a "new" system language.
    - unfamiliar 11y ago
      It's 6 years old as opposed to 43 years old, I would call that new.
    - apta 11y ago
      Or even a "system" language :-)
- thuffy 11y ago
  Because there is a battle going on. The lines are being drawn. People who where fighting this battle will see this happening before those who were unaware to start with; however, the lines are now being drawn thanks to Edward Snowden, and this battle is becoming visible to all. Meaning: GO was dead at birth from out of the sphincter of the NSA.

rck 11y ago

Does "ARM support" include bare-metal arm at all? I know there are several projects that move in that direction, but it's not obvious to me how mature they are relative to the rest of Rust (granting that everything in the ecosystem is in an early state)...

kibwen 11y ago
Rust exists to support Servo, and Servo's most important platform may very well be Android. I expect that Rust will see a lot of interest by hobbyists who hack the compiler to work with various fringe platforms, but in terms of official support I wouldn't expect Mozilla and Samsung to contribute anything beyond what's required for Android.
- shmerl 11y ago
  I hope Servo will be important for non Android mobile Linux as well.
  - sinistersnare 11y ago
    Rust builds for straight up ARM, see https://zinc.rs/ https://zinc.rs/ Now we only need to dependencies for Servo to move along and it could work. I would imagine this would be a lot of work for the OpenGL implementation they use.
    - shmerl 11y ago
      I should try building Rust with Mer SDK. Would be useful for Nemo, Sailfish and Plasma Active. Weren't Samsung also working on Servo? Did they consider it for Tizen as well?
    - higherpurpose 11y ago
      They should keep in mind that the Vulkan API is also coming soon, and I imagine it will be integrated in Android 7.0 next year.
- ZeroGravitas 11y ago

kibwen 11y ago

I think one thing that we need to emphasize is that Rust 1.0 does not indicate that we think the language is "complete". It is merely the result of recognition that getting to that "complete" state can, as of very soon, be done in a stable and backwards-compatible fashion. I expect the post-1.0 releases to see a flurry of activity as we flesh out deficiencies in existing features and add new features to address pain points, but over time the rate of feature growth will slow. Rust has no intention of becoming a ball-of-mud programming language.

mook 11y ago
Hi! I'm sure you get asked this a lot, but it wasn't found in a quick skim of the FAQs, so: How long do you (the Rust community) expect Rust to remain backwards-compatible? That is, once 1.0 ships, on what sort of approximate timescale would significant effort be made to ensure code that worked with the initial release (assuming no experimental features / libraries in use) would keep working? On the order of months, years, decades? I'm interested in writing some random things in Rust, but very much not interested in _re_writing Rust code in newer Rust. This probably means it's still too early for me, if the standard library is expected to expand soon after 1.0. But given e.g. the prevalence of Python 2 versus Python 3, it seems like there's quite a lot of people who think similarly. Background: I used to write Firefox extensions and things like that. Stopped being active around Firefox 4, when they declared that they are fine with breaking backwards API compatibility (and, IIRC around that time or soon after, put in arbitrary checks to force recompilation). This was just before the short releases started.
- fjh 11y ago
  > I'm interested in writing some random things in Rust, but very much not interested in _re_writing Rust code in newer Rust. This probably means it's still too early for me, if the standard library is expected to expand soon after 1.0. Why would you have to rewrite code because of an expanding std lib?
- Manishearth 11y ago
  > How long do you (the Rust community) expect Rust to remain backwards-compatible? The hope is for all of 1.*. I forget what the plan is for 2.0, but I think we want to keep things the same (mostly). In practice there will be minor breakages due to unavoidable bugfixes. Expanding the stdlib will never break your code. All changes now are being made with backcompat in mind; older code should never have to update.

LVB 11y ago

I really wish better Windows support was available now. Solid cross-platform support has allowed me to move some Python code to go. My attempts to do the same with Rust have been failures, on multiple occasions, but as recently as their 1.0 beta and nightlies (both 32/64 bit were tried). After giving it a few hours with the IRC channel riding shotgun and hello_world.rs still crashing on Windows, I've again hit snooze of Rust. A pity too... I am quite re-interested after seeing some Rust demos/discussion at PyCon.

kibwen 11y ago
One of the difficulties is that we really need a Windows platform expert, but they are remarkably elusive. Bit of a chicken/egg problem. Hey you reading this! Yeah, you! If you happen to be an expert in integrating native compilers with MSVC, we desperately need your help!
- moomin 11y ago
  Not to be funny, but you've been saying this for years now. Might be time to either give up on windows or accept you're going to have to make your own experts.
  - kibwen 11y ago
    Worst-case scenario is that Mozilla lends us some of their Windows experts when it's time to integrate Rust components into Firefox (which uses MSVC) later this year. But that's not a satisfying answer to people who want to develop on Windows today!
unethical_ban 11y ago
"cargo new helloworld ; cargo run" doesn't work for you in Windows? I did some REALLY REALLY MINOR code in Windows before doing it on Ubuntu, and I had no issues dependent on OS.
- kibwen 11y ago
  I'm guessing that the parent poster was trying to do a "hello world" equivalent of calling Rust from Python (as per the Pycon presentation), which would definitely cause grief on Windows if Python isn't compiled with the same toolchain that Rust is.

choward 11y ago

For a language that was written by Mozilla, I find it very annoying that they steal my browser's built-in ctrl+f functionality that I'm perfectly fine with using. Also, my vimium plugin doesn't work. This is the first time I've encountered something like this. This better not become a thing.

tatterdemalion 11y ago
This is a comment on http://www.discourse.org/ http://www.discourse.org/ , the software used to drive the internals.rust-lang.org forum, which is not written in Rust nor developed by Mozilla.
kibwen 11y ago
The forum software has nothing to do with either Rust or Mozilla. It's Discourse ( http://www.discourse.org/ http://www.discourse.org/ ), and personally I agree that it's kind of a pain. :)
- mkesper 11y ago
  Please use something different. Something utterly broken like this (keyboard navigation?) casts a bad light on a project that's - at least mentally - connected to Mozilla.

Animats 11y ago

From the proposals: "Perhaps the biggest is the lack of "privacy" or "unsafety" hygiene (meaning that it's not possible to define macros that have privileged access over normal code). This prevents macros from being used to define abstraction barriers." That may be a misfeature. One would like to reduce the need for unsafe code, not make it easier to write unsafe code. Unless you're talking to hardware or another language, you should not need unsafe code. If you do, the language has a problem. I'd suggest identifying each use of unsafe code in a large system and then looking at why it was necessary. It's important to keep Rust from going off into template la-la land, as C++ did. C++ generics are starting out with roughly the complexity level it took C++ two decades to achieve. Try to keep the metaprogramming fanatics from driving the language design, please. That doesn't end well.

tatterdemalion 11y ago
I'm not sure what Niko Matsakis means by that comment, but I think it is not exactly about the `unsafe { }` block kind of unsafety. Nothing about the macro_rules! system right now stops you from writing an `unsafe { }` block inside a macro_rules! macro.
- lomnakkus 11y ago
  The wording makes me think that's it's purely about allowing non-hygienic macros[1] in some sensible way. (At least a quick glance at the Rust book/manual suggests that macros are always hygienic in Rust.) Hygiene is a good default, but it does prevent certain other useful uses of macros. [1] http://en.wikipedia.org/wiki/Hygienic_macro http://en.wikipedia.org/wiki/Hygienic_macro
  - dbaupp 11y ago
    It's the opposite: macros currently leak their internals in certain circumstances with unsafe and privacy/name resolution, i.e. are slightly non hygienic (they are properly hygienic with respect to local variables, which is the major advantage of hygiene). The changes would make macros more hygienic in those aspects.
11y ago

aidenn0 11y ago

I'm glad specialization is listed as a Top Priority; it's something that I've wanted in Rust for about 2 years nos.

da4c30ff 11y ago

I wish I could use 'type' as a variable name or as a field on a struct. It's one of the most used identifier names and the inability to use it is frustrating.

heinrich5991 11y ago
You could sidestep it like Python does, adding an underscore after variables that are named the same as keywords (e.g. `type_`).

amelius 11y ago

I wonder if Rust would support something like the following. Say, I have a mmapped file, and in this file I'd like to store data-structures such as maps, sets, lists, etc. Basically, they are the same data-structures as one would use on the heap. Because the mmapped file is offsetted at a different point in memory every time it is opened, the actual pointers used to access these data-structures will be different every time. But the pointers inside the data-structures will be the same every time the file is mmapped. So, this requires some special pointer arithmetic (and perhaps a special type system). It would definitely be a very interesting and useful feature!

thuffy 11y ago

LOL, the new Godwin's Law: Edward Snowden. (See my valid but then NSA downvoted answer to the question below regarding GO vs. Rust that no one else could answer and were forced to make jokes about -- if you are wondering what I mean.) Sorry rust thread. :( (now kicked off the front page)