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.
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.
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.
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).
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).
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.
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.
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.
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.
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.
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.
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
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.
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.
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?
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).
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.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.
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.
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?
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].
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.
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?
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?
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.
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.
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.)
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.
121 comments
[ 4.1 ms ] story [ 183 ms ] threadProgramming 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.
(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.
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.)
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!
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.
I wouldn't say never, of course. I'm looking forward to using Rust. Just not now.
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.
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.
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.
My "mojikun" brainfuck variant is certainly dead, but then again, it was never really 'alive' either.
If you're using C for something, then probably not, for the same reasons you are not using C++.
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?
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.
And yet strictness typing seems to be on nobody's plan for future Haskell extensions.
TBH, Rust looks a bit stillborn - too weird to live, too rare to die.
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 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.
I disagree with "too weird to live" but at least it makes sense. What does "too rare to die" mean?
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 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.
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.
I think Rust strikes a chord with a lot of people, even those with no investment in it.
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.
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.
Young ecosystems: lots of opportunity, but 'opportunity' also means pain for those on the other side of the chasm...
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.
p.s. I love rust.
p.s.2 . It is completely logical and most of agree rust is in early adopt stage.
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.
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
[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/
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.
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.
For PHP PEAR is dead. Packagist is the de facto central repository for packages.
You don't need everything be pure Rust. Just use C libraries to fill in the gaps.
Hopefully more people share their stacks on http://www.stackbus.com/ (FYI, I build it) so that it help others to decide better.
[1] https://github.com/thijsc/mongo-rust-driver
Another is compiler plugins: it's much easier to stabilize an MIR than it is to stabilize the compiler's internal functions.
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?
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.
[1] https://github.com/draperlaboratory/llvm-cbe
[2] http://boomerang.sourceforge.net/
(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.)
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).
That is what most people want it for anyways.
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.
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.
Could you post your Cargo.toml?
Adding a
and building works fine here... hm.(also that [[bin]] section is just repeating the defaults, you don't strictly need it)
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?
(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.
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.