Announcing Rust 1.2 | Hacker News Reader

Announcing Rust 1.2

blog.rust-lang.org

385 pointssteveklabnik116 comments

I am currently evaluating Rust for a project where speed is important (I am working with graph data in the context of code analysis). Although I find Rust very appealing I still see C++ as the better option, mostly because I fear that Rust would lack good suppport libraries (e.g. for talking to DBs, generating/parsing data formats such as JSON or for generating cryprographic hashes) and that I would end up implementing many of those myself. As of today, many Rust wrapper libraries (e.g. for BerkeleyDB) seem to be written by a single author, which makes me wonder about their stability and maturity even more.

I wonder if this is an irrational fear though. Has anyone here implemented a large project with many external dependencies (DB, data serialization, interfacing with other programming languages etc.) in Rust? If so, what were your learnings and would you do it again?

I find that the discussion about whether a programming language is "good" or not always focuses on the core features of that language and less on the actual system of support libraries that are available for it and that make it actually useful in a real-world setting.

There are certainly library deficiencies, but we do have good Postgres bindings, and multiple JSON generating/parsing crates.

Young ecosystems: lots of opportunity, but 'opportunity' also means pain for those on the other side of the chasm...

I can't answer personally, but these might help:

https://doc.rust-lang.org/book/ffi.html

https://www.reddit.com/r/rust/comments/3axeu8/whats_the_stor...

I guess the answer is that it depends on what libraries you'll need.

The examples you gave (DB, JSON, etc) are big enough that there would be decent support for those in Rust. But, your concern is definitely valid for more niche requirements. If your primary concern is availability, stability, maturity etc of a language's ecosystem, then IMHO, you should not choose a language as new as Rust. Rust is currently in the "early adopter" phase, and it is going to go through the same issues (and excitement) that most early adopters do in any field.

I hope this was downvoted by mistake, because it's true that Rust is still in early-adopter territory. It's only been stable for three months! :P

Sadly I have seen people get downvoted just because tell the truth . This is really sad for me because we are in HN , we should not have see this kind of bias in place like HN.

p.s. I love rust.

p.s.2 . It is completely logical and most of agree rust is in early adopt stage.

The library support already seems quite excellent; the Cargo ecosystem seems to have most of what I want covered. And for anything that isn't covered, Rust has an exceptionally good FFI layer, so you can just call any available C library directly.

It's not by any means a conservative, "safe" choice (in the business sense); you'd be choosing an early-stage language, with everything that implies. But I think it's a reasonable choice for a new project starting today. And the community around it is incredible.

One advantage of Rust is its excellent C FFI. So as long as your dependencies have a C interface, you should be fine.

    Although I find Rust very appealing I still see C++ as the better option, mostly 
    because I fear that Rust would lack good suppport libraries (e.g. for talking to 
    DBs, generating/parsing data formats such as JSON or for generating cryprographic 
    hashes) and that I would end up implementing many of those myself. As of today, 
    many Rust wrapper libraries (e.g. for BerkeleyDB) seem to be written by a single 
    author, which makes me wonder about their stability and maturity even more.

Rust is in its very beginning[1]. Only time can tell if it will have a rich set of support libraries that are stable and mature.It has one big advantage over C and C++ in this regard.

It has a central repository for all the support libraries.

I always found it difficult to assess the stability and maturity of libraries for C or C++ found on the internet. Of course there are the standards, like libpng or zlib, and you know they must be good because so many projects use them. For more exotic tasks you are on your own. With a central repository, you can at least estimate the popularity of a certain library. crates.io shows a download count for example. Also many other popular languages have one

   Java     Maven
   Perl     CPAN
   TeX      CTAN
   PHP      PECL, PEAR
   Python   PyPI 
   Ruby     RubyGems 
   R        CRAN 
   Node.js  npm 
   Lua      LuaRocks 
   Haskell  Hackage

[1] I know that Graydon started it over 5 years ago, but from user standpoint Rust is more a child of 2015.

[2] https://crates.io/

Package managers have their own problems. Unless they are curated well they lead to many libraries that all claim to do the same thing. I wont name any specific examples, but using some of the above takes a fair amount of judgement in how rock solid the package is.

I, for my part, think I'm still better off with a central repository with problems than without one.

For Java there are commercial curated Maven repositories and I'm not aware of anything like that for C/C++. So Cargo can be an enabler for Rust in big corp.

The closest thing for C and C++ is probably Debian's apt repositories and the like from other distros. Just search for any package starting with lib-, then look for the ones with the most results in apt-cache rdepends.

I think a better design would be a p2p system with crates.io being a tracker and official seeder.

It's a nice approach in theory. Not so great in practice.

Whether we like it or not most developers are hired by a company. And for most medium to large companies there is no way they are going to let a P2P system go through their firewall.

Many don't even allow developers to access official repositories which is why products like Nexus (repository proxy) exist.

The standard clients don't need to seed by default. Provided there are organizations willing to seed, they could share the costs between themselves.

That is a problem with or without package managers. Maybe package managers should start doing PageRank style sorting and return results in the order of how popular they are?

Just for the sake of nitpicking:

For PHP PEAR is dead. Packagist is the de facto central repository for packages.

Experiment and report back! It's entirely possible that the single-author libs are already stable, and simply don't require the work of more contributors because the language makes it easy to get things right & robust the first time. (I don't have experience with Rust, so I'm not saying this is so - just that it's possible).

> Although I find Rust very appealing I still see C++ as the better option, mostly because I fear that Rust would lack good suppport libraries

You don't need everything be pure Rust. Just use C libraries to fill in the gaps.

Whenever a new language popup, I always wonder 1) who us it 2) why they use it 3) what they use it for

Hopefully more people share their stacks on http://www.stackbus.com/ (FYI, I build it) so that it help others to decide better.

We encountered this issue because we use MongoDB as our primary database and there was no driver available. I wrote a really nice (if I say so myself) wrapper [1] around the C driver, which really wasn't that much work. I think in general anything you can think of can be used by integrating with a C library.

[1] https://github.com/thijsc/mongo-rust-driver

Mongo has been paying a few interns to write a driver, actually. They presented at the last NYC meetup, and I've been doing code review.

What do you mean by "speed", and what is your primary working language?

1.2 is great (the nascent MSVC support is especially promising), but I'm most excited by the ongoing work in nightly to completely overhaul the compiler middle-end. The high-level overview is that the middle-end is being refactored to operate on its own intermediate representation instead of the raw AST, which should open the door to a whole host of improvements in compiler speed and code generation. It's technical debt whose bill is long overdue. :)

Will the MIR/HIR stuff also help with adding features? I'm thinking of things like non-lexical scoping/SEME regions/etc. which might be easier to implement with it.

When I started reading your comment, I was ready to respond with "yes, one example is non-lexical lifetimes", sooo :)

Another is compiler plugins: it's much easier to stabilize an MIR than it is to stabilize the compiler's internal functions.

Yes, MIR will help with non-lexical borrows.

Yep, the MIR allows the compiler to understand control flow more accurately and more precisely. Non-lexical lifetimes in particular are one of the big features that the MIR should help enable.

Does it open the door to being able to incrementally update the representation and have the compiler used as a library for IDE support?

Yup!

Well, as I usually do when a new Rust comes out, I tried recompiling some programs that used to work. So far, not so good:

    > cargo clean; cargo update; cargo build;
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Compiling libc v0.1.8
    Compiling regex-syntax v0.2.1
    Compiling memchr v0.1.3
    Compiling aho-corasick v0.3.0
    Compiling regex v0.1.41
    /home/john/.cargo/registry/src/github.com-0a35038f75765ae4/regex-0.1.41/src/lib.rs:394:34: 
    394:51 error: #[feature] may not be used on the stable release channel
    /home/john/.cargo/registry/src/github.com-0a35038f75765ae4/regex-0.1.41/src/lib.rs:394     
     #![cfg_attr(feature = "pattern", feature(pattern))]
                 ^~~~~~~~~~~~~~~~~
     error: aborting due to previous error
     Could not compile `regex`.

Looks like Rust 1.2 broke Rust's regular expression module. Somebody isn't running enough regression tests.

Hm, this looks like a nightly vs stable issue, are you sure you weren't on nightly before? Or, maybe something has turned on the 'pattern' feature, which is nightly only, accidentally.

The `cfg_attr` explicitly means that the `feature(pattern)` (the problem here) only gets activated when someone opts into it by activating regex's `pattern` feature, and by activating it they're opting-in to being nightly-only, i.e. outside the core stability guarantees of the stable releases.

Could you post your Cargo.toml?

    [package]
    name = "hello_world"
    version = "0.0.1"
    authors = [ "John Nagle <nagle@animats.com>" ]
    [[bin]]
    name = "hello_world"

That doesn't have any dependencies listed, how is it pulling in regex and such?

Adding a

  [dependencies]
  regex = "*"

and building works fine here... hm.

(also that [[bin]] section is just repeating the defaults, you don't strictly need it)

I dunno. Probably Cargo had some previous state stored somewhere that 'clean' didn't clear. I don't have time to figure out the internals of yet another weirdo build system.

Okay! That's not consistent with how Cargo is supposed to work, so if you can share anything, please open an issue. Sorry about that.

But you have time to condescendingly call it "weirdo".

Besides it having a bug (perhaps, it could have been messed up as they say from previously running nightly), what exactly looks "weirdo" about it?

This is error could have been caused by having `regex_macros` listed as a dependency. (Which has never worked on Rust stable.)

(The failure mode is bad here. Instead of reporting a compiler error on `regex_macros`, it's trying to compile `regex` with the `pattern` feature enabled, as specified in `regex_macros` Cargo.toml.)

`regex` has worked on Rust stable since 1.0.

Nice to see bors in the contributor list!

Bots are people too! /r/botsrights! :)

My current dream: Rust compiling to C, WebAssembly, .NET and JVM. We could finally have a fast, powerful, memory-safe language that can run anywhere without requiring a runtime or GC.

This will happen. Rust is going to be the language that runs everywhere, easily, and interops with everything. In the next year or two Rust devs will be able to easily build and test for Linux, Windows, Android, OS X, iOS, and asm.js/webasm from a single unified toolset.

Your statement is so optimistic that I am almost worried you are being sarcastic and making fun of me. :) Is this really going to happen?

I notice you left C, JVM, and .NET off the list. What's the story for how you could run Rust on a JVM, or on a platform that has nothing but a C compiler?

what platforms in 2015 only have a c compiler (and not, for example, an assembler)

An assembler is probably pretty common. But assemblers aren't standardized or portable.

I can believe that the Rust toolchain is pretty portable. But it's also big. Say someone wants to install my software on some weird platform like, say QNX. I'm not comfortable saying that step 1 for installing my (relatively small and simple) thing is: install the (very large and complex) Rust toolchain.

I want to be able to ship C source that will compile anywhere. Though I am comfortable needing two separate C sources: a 32-bit source and a 64-bit source.

LLVM has a C backend [1], though I don't know how complete/stable it is. Getting a bit sillier, it's possible (albeit probably not sensible) to decompile asm to C [2].

[1] https://github.com/draperlaboratory/llvm-cbe

[2] http://boomerang.sourceforge.net/

Yes I have been watching the revivied C backend with a great deal of interest! Haven't gotten it to work for me yet, but I haven't tried it for a little while. I would love to see it become a more common and well-supported part of the overall LLVM ecosystem.

brson isn't being sarcastic. He's the driving force behind getting to that goal.

(I personally wonder if the MIR work mentioned elsewhere in this thread would allow for creating a simple compile-to-C backend without too much effort.)

I am serious, but as you observed I also did not quite address your specific use case. Rust as-is with it's LLVM backend and lack of runtime has a clear path forward for anything LLVM can target (which is a lot now, and will be more in the future). This should get us into many platforms.

The compile-to-C case is the most straightforward of the three you mention, but also the one I'm most skeptical of. I do understand that there are some venerable old and/or small platforms where C is the only option. I don't know any specific examples of what people want to do by transpiling to C though. The only thing I know with any certainty is '8-bit microcontrollers', and this is one case that Rust is likely to be a tough fit for (largely because it wants pointer-sized things to be 'big enough', as well as other reasons I've forgotten).

Still, if it's necessary, it can be done with great effort (see the perennially broken LLVM C backend), but it's very low priority as of now.

I'm not sure yet the role of a JVM/.NET backend for Rust (besides the coolness factor) and I don't think people have put a great deal of thought into it. What we will have though is easy ways to bridge between the managed runtimes and Rust for accelerating your managed code or binding to system APIs. This will be necessary for creating decent Android/Windows environments.

(On the .NET topic a MSIL backend would also get us non-asm.js JS via [JSIL](http://www.jsil.org/) which would give Rust access to the DOM. This is quite a flight of fancy though).

I think more than a C backend, LLVM needs "C as an IR". Which LLVM can internally use to "trivially" add support for embedded-type platforms that only have a C compiler.

That is what most people want it for anyways.

Backend is the correct term: C is by no mean an IR which means "intermediate representation", from which you can more or less easily understand the thing behind the code (eg: types, control flow, variable bindings). An IR is a data-structure that obey some rules, a C file is flat text that needs parsing. Not the same.

If C is the output of the compiler, then we speak of a C Backend, which means the part that transform the final IR in the other language we want to translate to (eg: x86, arm6, sparc, ... C :)

As a final note, it's likely that platforms so conservatives that they only provide a C ansi compiler, will not be aroused by Rust.

You could reasonably do some for loop stuff using a C AST as your IR if you wanted. Not really sure why you would do this if coming from another language, but you could.

I don't really grok what this means - WebAssembly, .NET, and the JVM are runtimes, how does Rust compiling to them lead to a future that doesn't require a runtime?

Rust doesn't require it's own runtime but will be able to use existing ones eventually.

I'm speaking of the program itself not requiring a runtime. It can run on platforms where there is no runtime, like directly on POSIX.

And the fact that the program isn't tied to a specific runtime also would make it more compatible with other runtimes. You can't really run a JVM program on .NET, because the JVM and .NET have two totally separate universes of assumptions the runtime makes. When the program is runtime-agnostic, it can more easily be retargeted to different runtimes.

Memory management in Rust is much nicer than C but it still requires manual effort. I wouldn't want to use Rust for problems where a GC runtime was acceptable. What's the niche where you see running Rust on a VM as valuable?

The improvement in build speed is just exciting. Thank you to anybody that made it possible.

There are still enormous improvements to be made! In a year I think we'll be astounded at what we'd managed to put up with all this time. :)

Is there a master tracking bug for compilation speedup ideas? Just curious.

Which projects are the most notable Rust users as of today?

MaidSafe (http://maidsafe.net) and Skylight (https://skylight.io) are both written in Rust, Maidsafe having recently moved to it from C++.

In addition to nathan7's answer, there's also terminal.com (and I'm assuming here that we're not counting Mozilla's usage of Rust in Servo (and soon Firefox)). There are other companies putting various pieces of Rust code through their paces and we have outreach programs to help these companies in their explorations (I don't like name-dropping before announcements are fully ready, I'll be able to say more later this year).

In general though, remember what a young language Rust is (May wasn't that long ago!) and understand that large and notable projects take time to appear. Docker didn't appear until Go 1.0 was one year old, for example.

Isn't Rust the next C?

That depends on what you think of as being the core of C. Or, for example, some see Rust as the next C++, which is itself the next C, so is Rust _transitively_ the next C?

Programming languages never die, so I don't have a personal opinion on this point, exactly. For me, I would only write C code if I was working on a C project, or if I couldn't get a Rust compiler for the target platform. My starting point would be Rust, it would have to be disqualified for me to use C. Then again, I am the most biased person possible... (and also prefer C to C++) But regardless, C will never, ever die, so talk of Rust 'killing' or 'replacing' C is misguided, in my opinion.

I'd consider a language dead if there were no (or very little) new projects being done in it. For example you might say COBOL is alive because many financial institutions still run COBOL services, but you'd be hard pressed to find someone who would advocate to start a new standalone COBOL project.

(Queue person who started a COBOL project last week..)

In that sense, I think Rust has a real shot at at least severely wounding C++ or at least opening the door for the real C++ killer (it might be that Rust is a smidgen too strict in the mut ref department to really kill C++, I'm encountering a lot of push back from experienced C++ devs). We're talking about a 15 year timescale though, so that's at least 3 era's of computing.

> In that sense, I think Rust has a real shot at at least severely wounding C++ or at least opening the door for the real C++ killer (it might be that Rust is a smidgen too strict in the mut ref department to really kill C++, I'm encountering a lot of push back from experienced C++ devs).

Experienced X devs pushing back against Y doesn't mean that Y isn't going to displace X; the big factor in displacement isn't whether experienced devs will voluntarily shift (even if Y does displace X, the experienced X devs have the most vested interest, and will be among the last to voluntarily move to Y.)

  > I'm encountering a lot of push back from experienced C++ devs

Yeah, this bit is really interesting. It seems fairly split, though I'm not sure in what ratio. Some C++ devs are really into it, but others are very opposed. When you're used to total freedom, but then the compiler yells at you, there can be frustration...

We've also seen a _tremendous_ amount of interest from people who don't strongly identify as a 'systems programmer' at present. RustCamp was last weekend, and the audience is very broad. It's a classic "growing the pie" situation: Rust may or may not take away some of C++'s audience, but it very well just might make the pool of systems programmers significantly larger. We'll see!

> We've also seen a _tremendous_ amount of interest from people who don't strongly identify as a 'systems programmer' at present.

Can't underline this enough, as a long time WebDev with a lot of JavaScript, Python and Lua experience, Rust really feels like a door opener into the bare metal* world.

Especially as a Node Dev I felt right at home with Cargo. And as someone who only rarely touches C/C++, having the compiler scream at me for the first 10 days or so was probably the best "tutorial" about memory management and ownership I've ever "read" :) Rust really made me think a lot deeper about who / where and when stuff will be owned and eventually destroyed.

Overall, the language, cargo and everything around them fit so well together, learning it has been a real joy so far :)

* Well I've also done Z80 assembler on GameBoy before but that's probably not what people today would consider "bare metal" these days.

For me it's not really the freedom. I already said that elsewhere, but: I don't mind when the compiler yells at me. I just don't like the compiler to criticize my coding style by default. Initially, I liked Rust because it reminded me of C++. But then I began reading the book and basically it was full of statements about the coding style I prefer (and will keep) being bad. That's an incredibly stupid reason, but it kind of keeps me away from the language. But it's also the fact that C++ still is very widespread and has tons of libraries.

I wouldn't say never, of course. I'm looking forward to using Rust. Just not now.

Every language has different idioms. In many cases, what works in C++ doesn't work in Rust. Generally, anything the book says is bad you should take as qualified to mean bad in the context of Rust programming, not programming at large.

Sorry, I didn't make it clear enough. I was primarily referring to code formatting. Spaces instead of tabs, for example, or not writing opening curly braces on separate lines. These things are a matter of taste and should be friendly recommended at best. Guidelines for idioms are important and should occur as early as possible in the book, so that's perfectly fine.

I don't think telling you how to format your code for a particular language is a bad thing. I am quite happy using { on a new line in C# but on the same line in JS, using underscore_separated_method_names in C and camelCasedMethodNames in Java. To me, once you've been round the block with more than one or two languages you can get used to whatever style, but using the style for the language that you're writing in is something you should try to do for other people who read your code.

Reading Java code that uses undercore_separated_method_names or C# code that uses camedCased immediately makes me think the author doesn't know what s/he's doing.

I actually think that the scenario of Rust versus C++ is going to be quite interesting to see unravel, precisely because I don't think one is going to definitively weaken the other, but both be on their respective tails. This is because of the abnormally dramatic evolution C++ has seen over the past 5 years or so, and is hectically continuing.

Though this has pretty much definitively made C++ too large for any single person, and there are some fundamental semantics that ensure Rust will always have the high ground in some areas, the lines related to functionality are getting blurrier.

"Cue", not "queue". :)

"Programming languages never die"

There have been literally thousands of programming languages over the years ( https://en.wikipedia.org/wiki/List_of_programming_languages ) and I can't imagine that more than a handful (which most people itt can name) have survived from the 50s, 60s, and 70s.

Maybe I should say "Programming languages that were used at wide scale never die."

My "mojikun" brainfuck variant is certainly dead, but then again, it was never really 'alive' either.

This may be a bit like hair-splitting, but the language doesn't die, only the implementation does. As long as the language was specified in enough detail, a new compiler could be written for it, and be able to compile the old source code in the language. There is an interesting parallel to natural human languages here as well, a language like Latin is considered dead because no one speaks it as a primary language, but humanity still has the ability to translate and understand Latin texts. The same applies to say Egyptian Heiroglyphics as well. In any case it's interesting to think about.

Spiritually it seems to be a replacement for C++. If you're using C++ for something, Rust seems like a well-thought-out C++.

If you're using C for something, then probably not, for the same reasons you are not using C++.

If you're using C and encountering memory safety problems, however, then you may want to consider Rust. Moving to C++ from C offers a small safety benefit and a large expressiveness benefit at the cost of a very large complexity drawback. Moving to Rust from C, on the other hand, offers a large safety benefit and a large expressiveness benefit at the cost of a significant complexity drawback. (I think Rust as a language is less complex than C++, and the complexity of C/C++ undefined behavior rules completely vanishes in safe Rust.)

Can you elaborate on what you mean by the "very large/significant complexity drawback"? From what I've seen (which is admittedly small) Rust is much less complex than either C or C++.

Rust is a larger language than C, though far smaller than C++. More importantly, with Rust you should expect to spend more of your time convincing the compiler that you've written correct code, which requires a reasonable understanding of Rust semantics. (The compiler makes that fairly easy, but it can still be a bit of a shock when you're staring at code that seems obviously correct to you but the compiler has no way to know that.)

On the other hand, once you do convince the compiler, you have an excellent chance that the code actually is correct, and you'll spend far less time chasing down crazy runtime bugs.

> On the other hand, once you do convince the compiler, you have an excellent chance that the code actually is correct, and you'll spend far less time chasing down crazy runtime bugs.

That's what I love about Haskell as well. Know of any other languages like this?

I used to feel more strongly that way about Haskell. I still do about most types of errors, but I spent a long time debugging serious performance issues caused by unbounded laziness and insufficient strictness.

In general, I'm a big fan of static typing. I don't know any other language that manages to provide as much static memory safety as Rust, though; that's the main innovation in Rust.

The difficulty of reasoning about strictness and memory consumption in Haskell is by far its biggest flaw. This is why I stopped writing Haskell: even if you understand your own code perfectly, you can't tell how well-behaved it will be without reading your dependencies and all their dependencies.

And yet strictness typing seems to be on nobody's plan for future Haskell extensions.

Compared to C, Rust has generics, closures, a module system, hygienic macros, real strings, slices, lifetimes, and the borrow checker. But note that all the features that Rust adds over C are, in my view, one of (a) necessary for memory safety (which is an important feature in 2015); (b) improvements on C features (macros compared to cpp, strings compared to char *, modules compared to #include); (c) things you expect from a modern language (generics, closures).

I'd say that Go is a better "better C" than Rust, for already functional C programmers. The syntax of Go is as removed from C as Rust's, and it's more mature.

TBH, Rust looks a bit stillborn - too weird to live, too rare to die.

This is also why it matters to know what you mean by C: to me, a key aspect of C is the manual memory management and lack of a runtime. A C that adds GC is no longer C.

People say this. I looked into Go, to write modules for VoIP platforms. Go is a managed runtime environment. I can't drop it in where I'm currently using C. I can't easily start migrating pieces of a program to Go. But Rust does execute exactly where C can.

In fact, I don't see how Go is C like at all. It seems much more akin to other managed languages, like Java. The only reason it seems to come up in these discussions is that Google said it was for "systems" programming, using a new value of "systems".

Maybe you're referring to mindsets and syntax or something?

I strongly disagree with this assessment. Go may be a better Java or Python, but as a GC'd language it's not in the same league as C or C++ or Rust.

I also happen to prefer Go's syntax to Rust's, but I can live with GC'd performance. If I were writing something as performance critical as a browser rendering engine, I could get past the weird syntax. I think both Go and Rust have bright futures.

comparing go to c is like comparing python to c - those langauges are designed for different purposes. if you're happily delivering web services with go, stay with go, rust probably is not for you. if you OTOH don't want a GC or want to write a dll that you can then call via FFI from go/python/ruby, rust is the way to go, as is C or C++ (pretty much the only other choices available).

Go isn't designed for the same purposes as Python or Ruby, either. It's statically typed and far less expressive.

indeed there are critical differences regarding certain details like compilation to executables, compile-time time checking, etc. this doesn't mean the purpose can't be the same. it certainly is for many people (developing web sites).

Do you have specific reasons why Go is a better "better C" than Rust?

> too weird to live, too rare to die.

I disagree with "too weird to live" but at least it makes sense. What does "too rare to die" mean?

https://www.youtube.com/watch?v=B4c78PZRsHs

Go is more mature than Rust, and to the extent that they have similar advantages (which I don't think is very much) Go's first-mover advantage may help it.

OTOH, Rust is maturing quite well, and I think it has broader applicability and a very different area that is its strongest point that is the case for Go, so I think that its quite likely to do well initially in places where Go isn't much of a competitor, and in the long run may well be more successful than Go. (Particularly, its focus seems to be aimed at lower-level system programming than Go's, but a the same time it has constructs that, once good low-level libraries are in place, seem to make it potentially quite good for higher-level programming as well.)

I'm using Rust as a C replacement (I need speed and ability to produce libraries with a C ABI). To me Rust is "C with templates". Rust isn't an OO language in the same style as C++ (instead of inheritance it has trait polymorphism, which is nice, but doesn't always map to C++ design patterns).

I don't use C++, because for every thing that can be written in C++ there's always a more complex/clever version that should have been written instead.

Rust is suitable for a great deal of what C is used for (extending higher-level languages, writing language-agnostic libraries, embedded development, etc.) but Rust will likely never support as wide a variety of obscure platforms as C does. That said, Rust already supports Linux, OS X, Windows, and Android as first-class citizens, and support for FreeBSD, iOS, PSP, and lots of embedded and ARM platforms is currently provided by the community.

PSP?

https://fnordig.de/2014/12/03/a-story-of-hacking-or-rust-on-...

That's pretty cool! I haven't been in on the PSP "scene" in years. Nice to see things are still going on there.

PlayStation Portable, the predecessor to the PS Vita.

Yeah. Wasn't sure if that's what the abbreviation was for. I miss hacking and making PSP homebrew.

And C remains the linga franca of FFIs so that's there to stay.

I don't really see why a pile of different languages couldn't FFI through C-style interfaces without any of them actually being C, though.

How long until every minor Rust release is no longer a front page event on HN? Nothing against the language, but this doesn't really offer a whole lot in terms of discussion; reflected by the (current) point totals: 102 points and 4 comments.

I'm not even a rust user (tried it out a little haven't had the time..). I really enjoy the rust posts here though.

Watching the language evolve has been interesting for me. Its an interesting language for a variety of reasons. Those that did a lot of c/c++ programing are probably the biggest fans.

This post wasn't the greatest, but good to see where things are going/ improvements being made.

Normally I avoid making comments that are essentially upvotes, but I wanted to make it clear that acomjean is not an unusual case. I also haven't really used Rust much, but I've followed it's development since the 0.3 days when it was a completely different language. I find the kind of design ideas that go into it very interesting and I get especially excited by the fact that it's actually a serious language now.

I think Rust strikes a chord with a lot of people, even those with no investment in it.

I become irrationally excited whenever I see a Rust release announcement, so I hope they keep popping up to the front page!

Can't we discuss the new/changed/deprecated items?

Doesn't really look like it. Of the current conversations, only two are related to the the topic of changes, the rest are generic questions or thoughts about rust.

Yep and it makes total sense, there's not a huge changelog since there's a release every 6 weeks. If there were ground breaking changes we'd see more discussion though.

It was only posted an hour ago, give it some time. :)

It will reach front page as long as people are interested.

>102 points and 4 comments.

Well, how about 300+ points and 109 comments, as of now?

1.2 is not a "minor Rust release" as it brings quite a few changes. Besides, we get the same posts for Go releases and tons of other projects besides.

If you don't like them, skip them.

Reply on news.ycombinator.com