Rust is the future, C is the new Assembly: Josh Triplett (Intel)

https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/

by amaccuish • 7 years ago

157 235 7 years ago

hub.packtpub.com

prideout2• 7 years ago

Rust really does seem to be taking off in the realm of native languages. Personally I would've preferred something simpler, such as nim or Kotlin Native.

However I'm excited for the future of system-level programming: we were stuck with C/C++ for a long, long time and maybe that's finally changing thanks to Rust!

eej2ya1K6• 7 years ago

It's taking off, sure, but every single piece of Rust software I've tried has been, uh, I'll be nice and say not to my taste. Almost like the safety guarantees Rust provides means that developers stop caring about portability, UNIX conventions or just... general... comfiness.

smhenderson• 7 years ago

Do you have some examples of what you've experienced that you didn't like? I keep reading about people replacing tools written in C with Rust versions but I haven't really pursued it further and seen them in action.

steveklabnik14• 7 years ago

As a Windows user, the Rust ecosystem feels far more portable than any other ecosystem I've used; I run into issues extremely rarely, even though most people are on Mac OS or Linux. (Our last survey did show ~30% of people using Windows, though.)

jedisct15• 7 years ago

When it comes to portability, Go is really awesome.

Diggsey3• 7 years ago

Both Nim and Kotlin Native have a runtime in the form of a GC/automatic memory management, so you'd still need another language "beneath" them to get the job done.

In the system programming world, "simple" means having the program do what you tell it and no more, so that there are no surprises when you come to run it.

Rust has a very complicated compiler, and a moderately complicated syntax, but the semantics of the language are amongst the simplest out there - far simpler than C (purely because of the UB), Nim or Kotlin Native IMO, and that really helps when writing low-level code, or even just when contributing to an unfamiliar code-base.

eej2ya1K6• 7 years ago

The semantics of Rust aren't simple at all. I've used a huge number of languages, both professionally and for personal projects, and Rust is the first one I'm too stupid to understand.

("Modern" JavaScript comes close, but that's not because of semantics, it's more because everything is incredibly overengineered...

simiones• 7 years ago

Both Nim and Kotlin Native have a runtime in the form of a GC/automatic memory management, so you'd still need another language "beneath" them to get the job done.

That is not necessarily true. Not sure in the case of Nim or Kotlin Native, but the GC itself can be written in Nim/Kotlin Native in principle as well.

5-• 7 years ago

I would be wary of calling 'simple' the semantics of a language that requires intimate knowledge of particular optimisations in its code generation framework to implement dynamicaly allocated arrays.

https://doc.rust-lang.org/nomicon/vec-alloc.html

someoneiam• 7 years ago

IIRC at least in Nim the GC is optional. Never tried it myself though, so I have no idea how it feels to manage memory manually with Nim.

hu3• 7 years ago

I don't know how to put this politely.

There's nothing simple about Rust.

The compiler is complex and slow.

The borrower semantics is anything but simple.

It isn't uncommon for the syntax to look arcane.

The standard library is shallow often making developers have to resort to third party libraries for trivial things.

Rust improved upon languages like Cyclone but it's a far cry from being the next C/C++ when it comes to potential market adoption.

prideout2• 7 years ago

Agreed overall, this might be why Rust is winning. (By the way neither Nim nor Kotlin Native have a heavy runtime in the same way that Java / JavaScript / Python do. Garbage collection in Nim occurs only at specified times.)

JoshTriplett4• 7 years ago

That's definitely the most critical property of Rust. Not long before 1.0, they decided to drop the runtime and green-threads support entirely. If they'd kept them, I think Rust would have been just one more runtime-based language in a sea of such languages. But by ditching them, Rust became a language with no manual memory management and no garbage collection, exactly what systems programming needs.

pjmlp25• 7 years ago

Just like Oberon has the whole OS written in it.

http://www.projectoberon.com/

degraafc• 7 years ago

I'm hoping for Zig [1] to reach maturity and offer that kind of simplicity, because I just can't get a handle on Rust (not that I've spent a massive amount of time trying).

[1] https://ziglang.org

dgellow• 7 years ago

Both V (https://vlang.io/) and Zig seem really interesting, I also hope they will reach maturity

jedisct15• 7 years ago

I'm hoping for it to get more exposure.

The fact that Mozilla was behind Rust played a lot in Rust becoming popular.

But a lot of nice languages have stayed under the radar, and have been eventually abandoned.

To succeed, Zig needs maturity, but also marketing. And that is hard without some big name advocating it.

guggle2• 7 years ago

Ah ! Nim... as a Pythonista, I'm loving its aesthetics. However in the end it's all about community support, available libs, tooling...

sleepysysadmin3• 7 years ago

Rust and Python. I see Rython in the future.

edit/sorry?

dbcurtis4• 7 years ago

How do you see that working? Rust and Python come from very different philosophies. I like them both, but they are a strange mix. Python extensions in Rust? That could be a good thing. Much easier to write a reliable Python extension. I imagine tooling for that already exists and I am simply unaware.

Or, maybe Rust semantics with Python’s readability? I would like that. Rust is the wave of the future, but ultimately the language will not be a long-term survivor, entirely because of the ASCII-salad syntax. I predict that we will learn huge amounts about language semantics from Rust, thank the team, and then replace it with something pleasant to read.

Rust is the Algol of a new generation. I mean that as both high praise and as a sad prophecy.

enriquto• 7 years ago

Maybe he means a python implemented in rust

fb03• 7 years ago

I too am having problems 'getting into' Rust because of all that salad-y syntax. It looks like Perl at some times ;__;

sleepysysadmin3• 7 years ago

Well I was thinking similar to Cython which is just python that gets compiled(to over simplify I'm sure)

Rust is the wave of the future, but ultimately the language will not be a long-term survivor, entirely because of the ASCII-salad syntax.

I can agree with that. Hence Rython.

Rust is certainly the future when compared to C or C++.

Rotareti• 7 years ago

Python extensions in Rust? That could be a good thing. Much easier to write a reliable Python extension. I imagine tooling for that already exists and I am simply unaware.

There is https://pyo3.rs/v0.7.0/

JoshTriplett4• 7 years ago

There are Rust crates for implementing Python modules in Rust, and for embedding a Python interpreter.

dbcurtis4• 7 years ago

Thanks! Now I need an excuse to write a Python extension. Seen any shaggy yaks around here?

floor_2• 7 years ago

Rust has a npm package problem.

For reference: https://twitter.com/bascule/status/1166583003021283333

dpc_pw2• 7 years ago

But also has a solution: https://github.com/crev-dev/cargo-crev

floor_2• 7 years ago

This is a solution to a problem that shouldn't have happened in the first place.

swsieber3• 7 years ago

As great as that tool is (I do think it's good) I wouldn't call that a solution, I'd call that a mitigation. If the ecosystem is terrible (dependency-bloat wise), then a tool like that doesn't make a big impact.

swsieber3• 7 years ago

So, a single example enough to state there's a problem?

I admit - Rust is on the easier side of packaging, which tends towards proliferation of dependencies, but the general feeling I get right now from rust communities is a deliberate restraint when it comes to dependencies.

CuriousCosmic• 7 years ago

If you read into it a bit more, those are optional dependencies and if you drop support for redox OS while on windows you lose all but five of the dependencies and those are a config dependency, libc, and winapi and winapi architecture packages (32bit support + 64 bit support). On Unix/Linux, it only depends on the config dep and libc.

the_duke4• 7 years ago

Interestingly the situation is somewhat similar to Javascript: a very lean standard library, paired with a great package manager that makes sharing code simple.

I agree that the dependency problem is getting continuously worse though. An important factor is people splitting up crates into multiple sub-crates, proc macro crates (which have to live in a separate crate), and generally having a much too cavalier attitude about adding dependencies.

The last year has been particularly bad, but on the flip side there is also increased awareness and motivation to counter this.

Rust will never have a stdlib like Go, with http server/client, compression and crypto algorithms, ...

But I do think that it needs to be conservatively extended with some core primitives that are missing. A problem is the still heavily evolving language. A few upcoming features could change idiomatic API design, so putting anything in std now could be a big mistake in the long term.

nindalf2• 7 years ago

This is FUD. Almost all of those dependencies exist only to support Redox, an OS you likely don't use. If you actually compiled it for Linux or Windows, it would have 3 dependencies. One of the people replying to that tweet actually attached a screenshot of this.

Since you commented "I don't actually care about Rust, I'm only farming karma to downvote posts on this trash news aggregator", I hope your bad faith attempt to spread FUD fails.

est31• 7 years ago

Those dependencies still get downloaded and shipped by tools like cargo vendor, because cargo vendor has no target specific vendoring support [1]. The dependencies still bloat up the Cargo.lock files and thus probably have a negative impact on Cargo resolution graph creation (which is an NP complete problem). And to top this, the code isn't even used on Redox [2].

[1] https://github.com/rust-lang/cargo/issues/7058

[2] https://gitlab.redox-os.org/redox-os/users/issues/26

cryptonector• 7 years ago

Is there any language / distro that doesn't?

In the end you need gatekeeping. That's a security-critical function, and it's a people function, not a function of language.

ErotemeObelus• 7 years ago

People who say "C is the new assembly" don't understand why people moved from assembly to C.

Assembly is bad because it is typeless. Because it is typeless, there is no way to check for program correctness. Rust is okay because it doesn't require garbage collection and types, but the best language would be C with a highly-elaborate strong type system and no closures or other unsuitable concepts for systems programming.

gnaritas• 7 years ago

That's not why people moved from assembly to C, C is portable, assembly is CPU specific, the move to C was about abstraction to a higher level language in the name of portability to multiple processors, not about verifying program correctness.

pjmlp25• 7 years ago

At Bell Labs, on the outside people where already using plenty of Algol and PL/I variants.

damnyou3• 7 years ago

Why are closures unsuitable for systems programming? Rust does them really well, not even allocating in the most common cases.

jerf2• 7 years ago

Closure often have really weird lifetimes, so typically they've ended up implemented either with GC of some sort (possibly refcounting), or required such exceedingly careful handling that the cost/benefit analysis gets a big fat lump of "cost" that isn't a problem in most other environments because trying to track the transfer of ownerships across scopes, up and down stacks, and perhaps even between threads is just insane. Typically the entire purpose of the closure is precisely to inject some code's logic into a quite distant other bit of code, so the problem is not amenable to normal techniques around rearranging things to be on the stack and so on. The very nature of a closure-type abstraction in C is go to stomping right over the generally-fragile informal, unsupported organization of what code is responsible for what memory.

I once was working with libpurple in a glib environment that made heavy use of segfaults in C. I mean closures. Closures in C that made it really easy to segfault when calling to a closure that had been freed, or really easy to leak if you didn't free them. I encountered situations where the common paths used by the "standard UI" for libpurple worked, but even when I was quite sure I was handling one of my closures correctly, the system would crash because it still free'd my closure, even though it should have been my responsibility to do so, and so on.

Prior to Rust, I'd agree with the common wisdom that closures and systems programming had gone together poorly. It's a demonstration of the power of Rust's approach to the matter that closures become practical in system programming with it; that had not previously been the case.

pornel3• 7 years ago

    (0..1000).map(|x| x*2).sum()

compiles to

    mov eax, 999000

Rust takes full advantage of its ownership, mutability, lifetime tracking and generics to have closures with zero overhead.

pjmlp25• 7 years ago

Interesting, because clang does support closures in C, thanks to Apple.

jedisct15• 7 years ago

Hard to predict what the "Future" is.

Rust fills a niche. It's not the answer to everything.

The learning curve is steep, and for many applications, the benefits are nonexistent.

Although you can use Rust (or anything, even Bash if that's your thing) to write web applications, Ruby, Python, PHP and Javascript are far more productive and this is not going to change tomorrow.

Rust's borrow checker doesn't add anything besides complexity here.

Go is also a nice balance between being simple to use and powerful as a system language (unless "has no GC" is how you define a system language).

Swift has most of the best parts from the language above.

Crystal is a pleasure to write and runs fast.

Zig may eventually get more traction.

Something like Rust, but accessible, readable, that compiles quickly, is stable and has a natural way to do async operations could quickly make Rust obsolete.

maerF0x0• 7 years ago

Triplett broadly defines systems programming as “anything that isn’t an app.” It includes things like BIOS, firmware, boot loaders, operating systems kernels, embedded and similar types of low-level code, virtual machine implementations. Triplett also counts a web browser as a system software as it is more than “just an app,” they are actually “platforms for websites and web apps,” he says.

Even though I love golang and use it daily for my job, I'd suggest that golang is not a good fit for Triplett's definition for systems programming.

sanderjd• 7 years ago

Ah that quote actually clarified for me why browsers feel different than "normal" applications: in their role as a platform for other applications, they have a lot in common with straight-up VMs.

geodel• 7 years ago

But then Triplett's definition for systems programming is not some ISO standard. In lot of companies I have seen they call their large internal applications development as systems programing.

Also compilers, runtimes, GCs, databases, cloud schedulers (Kubernetes etc) are also not 'apps' could fit in systems programing definition.

onebot3• 7 years ago

I often see "steep learning curve" cited as a negative about Rust. But I think it is far less of a learning curve than it is to be a reliable C and C++ programmer.

I am not sure how much Rust you have done yet, but the borrow checker is a tremendous confidence booster. Especially refactoring code. I have never had anything where I can feel at ease in making big changes to an existing code base. As all things, I don't think you notice it once you learn how to write safe Rust code.

Go is certainly a good balance. One of its best things is the rich standard library. I wish Rust took more of that approach.

One thing about Rust that is maybe overlooked is that it is, like C/C++, truly "full-stack". By that I mean you can go from low level embedded (microcontroller with no MMU) all the way up to web server, etc. I don't think it is really a "niche" language--at least it has a very horizontal use case.

Having been at this for a super long time, I have seen the popularity languages come and go from ASM, Perl, Java, Python, .Net, etc. I can assure you nothing is gonna "quickly" make another language obsolete. New languages are incredibly hard to get off the ground and be relevant for a long time.

EpicEng3• 7 years ago

I often see "steep learning curve" cited as a negative about Rust. But I think it is far less of a learning curve than it is to be a reliable C and C++ programmer.

Man of us are already competent in C and/or C++, so to make a move there has to be a big value prop if it's a large investment. I'm not saying there's not, but most of us aren't deciding to pick up C, C++ or Rust from scratch.

atoav2• 7 years ago

This reflects the feelings I had when I tried Rust for a few side projects. I read everything I could and did all the tutorials, but I still felt there was some sort of invisible glas wall between me and enlightenment. I tried very hard to program in structures I thought I had to use, mainly out of experience from other languages (OOP...)

At some point the friction just grew too hard and I said to myself: "Ok you stupid Rust, I will do it your way, I just want this to work" and then it made click and everything fell into place – builder patterns, traits, composition over inheritence – I realized that clinging to all the patterns I had learned was idiotic, because Rust has given me maybe even more powerful ways of expressing myself.

If it wasn't for the friendly Compiler yelling at me, I doubt I would've gotten so far.

dan_quixote• 7 years ago

I am not sure how much Rust you have done yet, but the borrow checker is a tremendous confidence booster

I recently spent an entire week diving into Rust for a personal project. While it certainly had a learning curve that slowed me down (particularly regarding the borrow checker), I realized that I only had 1(!) runtime error all week...in a language I was unfamiliar with. That gave me a huge amount of confidence in memory safety.

pizza234• 7 years ago

Crystal is a pleasure to write and runs fast.

Crystal has no support for parallel execution, which is an important feature nowadays, at least, when one compares it to Go and so on.

jedisct15• 7 years ago

https://github.com/crystal-lang/crystal/pull/8112

jswizzy• 7 years ago

Go and Crystal are slower than Java which has a much better ecosystem.

jefftime2• 7 years ago

I use C a lot on my personal projects, and I have enjoyed learning Rust and playing with it to potentially replace my use of C. For the most part Rust has everything I want, but interfacing with C libs and headers can be so unergonomic. I wish there was a good alternative to bindgen that didn't shoot your build times up. Offline binding generation works, but then you have to manually deal with versioning. I don't really know what the solution is, but it's currently one of the pain points I have with Rust

okl• 7 years ago

Can't you call bindgen from a build management tool that checks if the source file has changed? Or do you mean building in a CI setup?

jefftime2• 7 years ago

That's a good point! This might be a good way to go about it

JoshTriplett4• 7 years ago

That's one of the items on the list to get better C parity. Binding to C libraries should work as easily as C's #include.

Tuna-Fish3• 7 years ago

Wouldn't the simplest solution be to just make bindgen emit "from <file name>@<hash>" into the /* automatically generated by rust-bindgen */ comment?

Then when it loads a .h, hash it, and if the hash is unchanged don't write anything. This way, the cargo/rust incremental compilation does the rest of the work. Minimal change to how it works now, yet the compile times go way down.

If you are willing to live dangerously, you could always use modification times instead of hashes to avoid having to even read the .h files on compile, but frankly that sounds like it'd just make enough heisenbugs that people would start doing clean compiles just in case.

davidhyde• 7 years ago

What sets it apart from other modern languages is that it does not have a garbage collector or runtime system of any kind.

This is not strictly true. Most Rust programs, like most c programs, do have a runtime. See https://doc.rust-lang.org/0.12.0/guide-runtime.html

However, this runtime can be replaced which is what makes Rust suitable for certain systems programming scenarios (like building operating system kernels). This is the realm of [no_std]

Arnavion• 7 years ago

Most Rust programs, like most c programs, do have a runtime. See https://doc.rust-lang.org/0.12.0/guide-runtime.html

You've linked to the docs of a release from 2014, back when Rust did have a runtime.

(Unfortunately it's very easy to get results for ancient Rust releases from search engines. Similarly there are three different versions of the Rust book and many of the search results are for the oldest one.)

However, this runtime can be replaced which is what makes Rust suitable for certain systems programming scenarios (like building operating system kernels). This is the realm of [no_std]

What `no_std` allows you to do is not use libstd, ie the standard library. libstd is certainly a "runtime" in the sense that libc is the C runtime, but it doesn't mean it enforces green threading or garbage collection like the word "runtime" evokes for other languages and is used in the page you linked. This latter meaning is also what the sentence in the TFA was using.

roblabla3• 7 years ago

You're linking to an old version of the rust documentation from before it was even 1.0.0. Rust used to have a runtime before 1.0.0 to implement green threading. But this is not the case anymore. Rust can be entirely statically linked into a self-contained library that has no runtime requirements whatsoever.

steveklabnik14• 7 years ago

I think you're being downvoted a bit unfairly.

1. Your link is incorrect, as the sibling comments say, but you're also correct that Rust has a runtime. It's about the same amount of runtime as C, but like C (as you say), it does exist.

2. no_std does not remove the runtime. I think the closest you can get is no_core, but to be honest, I'm not actually 100% sure.

zwieback• 7 years ago

Anything that wants to unthrone C not only has to be better and no worse than C but also has to beat "C plus domain-specific libraries". A lot of things C itself lacks can be added with relatively thin libraries. The problem with that, of course, is that we can always circumvent libraries, conventions, type checkers, etc. and do dangerous things.

In that sense Rust does seem very interesting.

Endy• 7 years ago

Maybe it's the new Assembly. With what little hacking and programming I am willing to put effort into, I will always prefer to work at the direct hardware access level rather than the massive abstraction that is required to run C & the relevant interpreters. Then again, I prefer working on 6xxx architecture (6502,6507,6809,etc) and cap out around 286 IBM compatible with MS-DOS for any real tasks.

codesushi4210• 7 years ago

C is not the new assembly. This line has been reused for years, even decades. And it has always been a lie.

Memory safety and automatic memory management come at a cost. Even in Rust. C will always have a use for critical performance in the embedded world.

random314• 7 years ago

Can you show some sample code in Rust with this memory management cost that C doesn't have?

atoav2• 7 years ago

I am pretty sure the article didn't claim that C won't always have it's place – alone for all the existing codebases it makes sense to use it. If people still learn latin many centuries after the fall of Rome, why would they ever stop to deal with C?

I am somebody who uses C on embedded but really likes the way Rust does things too. Sometimes my naive Rust implementations outperformed my optimized C code very easilly (maybe I am not good enough, who knows). What I especially liked are the zero cost abstractions, which allows you to keep that cost you were talking about very low.

And if I like to do stuff on my own I just do it inside an unsafe block and I am very close to what I could/would do in C.

Even if Rust would fade away it teached me a few hard lessons that definitly improved my C programming.

codesushi4210• 7 years ago

That is fair. I am responding to the click baity title of the article.

C has been declared dead and replaced so many times over the years that I have lost count. It is not going to be replaced enitrely by Rust, and definitely not in the embedded world. C will not be the new assembly, it will continue to be C.

C++ could be an entirely different story.

adrianN2• 7 years ago

What's the cost? If you're not afraid of `unsafe`, you can do in Rust exactly the same stuff you do in C, while still having strong guarantees for all your safe code. You might argue that fighting the borrow checker has development costs, but the memory issues that it prevents also have a development cost.

kllrnohj6• 7 years ago

C will always have a use for critical performance in the embedded world.

Based off of what reasoning? It's not like C is any faster or more efficient than Rust or C++. Heck you can often go faster in C++/Rust than you can in C thanks to the ease of using abstractions that just make things go-faster for you automatically (such as SSO in things like strings, or constexpr for compile-time resolution).

The embedded world isn't using C because it's a good fit, they are using it because of legacy inertia and lack of motivation to move to anything else. IoT is starting to change that, as all those C memory vulnerability issues turn into product support costs.

And also realistically embedded isn't even restricted to C already. Very popular microcontrollers like the esp8266 or esp32 also have javascript runtimes.

codesushi4210• 7 years ago

It's not like C is any faster or more efficient than Rust or C++

Huh? C is certainly faster than C++.

go-faster for you automatically (such as SSO in things like strings, or constexpr for compile-time resolution).

That is a terrible example. You shouldn't be using the STL (i.e. std::string copying) for performance critical sections to begin with.

Very popular microcontrollers like the esp8266 or esp32 also have javascript runtimes.

First, esps are not low end microcontrollers at all. Second, no one uses JS runtimes for performance critical code on microcontrollers (e.g. JS will not give you direct memory access). What an absurd claim.

jeffdavis2• 7 years ago

If you invent the next image format, compression scheme, encryption scheme, etc., and you write a Go library for it, then it can be used by Go programmers. If you write a C/C++ library, it can be used by any programmer (perhaps with a wrapper) on billions of devices.

Now, we add Rust to the list. You can write that library in Rust and it can be used by anyone, too. That's because there is no GC or other extraneous code, and because you can make structures with specifically-defined layout in memory.

Making a list of options go from two to three is a big deal. Especially when, a lot of the time, C++ ends up looking like C when you need to interface it with something else. So Rust is kind of like going from one to two optons.

I'm ignoring other good languages, I know, but those are often just not chosen for a variety of reasons. Rust seems to be breaking out of that trap because of a good community, a few nice features, the fact that it's new, and a bit of luck.

pjmlp25• 7 years ago

In Windows I just implement in COM and it can also be used by any language on the platform, without resorting to plain old C.

Ygg2• 7 years ago

Yes. But then you have to use COM :P

colejohnson66• 7 years ago

Now, we add Rust to the list. You can write that library in Rust and it can be used by anyone, too. That's because there is no GC or other extraneous code, and because you can make structures with specifically-defined layout in memory.

Genuine question: Can you link a Rust binary with a C/C++ binary?

steveklabnik14• 7 years ago

Absolutely.

baq2• 7 years ago

notably firefox has a few modules implemented in rust.

mlindner• 7 years ago

You can link a Rust library to a C/C++ binary and you can link a C/C++ library to a Rust binary. https://doc.rust-lang.org/nomicon/ffi.html

Notably you need to use the C ABI to call things from C++ as Rust FFI doesn't support C++ directly.

mrbonner• 7 years ago

I have written a proof of concept for making a lib in Rust and then use JNR (a wrapper of the abominable JNI) to call and be called from that lib. I was surprised to see how much easy it is to write an ABI in rust to be used in the JVM. I am sure this lib will even have an easier time integrating with Python/Ruby comparing to Java. With that in mind, I think for my future native ABI development, I would be seriously considering building in Rust instead of C/C++.

trulyrandom• 7 years ago

Fun fact: you can expose a Go library in the same way using the c-shared build mode.

jeffdavis2• 7 years ago

But how many want to link the Go runtime into their program? Maybe they just don't want it there, or maybe they already have other runtimes linked in their program and don't want one more, or maybe they have runtime version conflicts, etc.

Also, such interfaces generally require more copying around of structures to match the format the language is expecting. With rust, it can use plain C structs directly without translation.

blub2• 7 years ago

The Rust community definitely believes in the idea that if you repeat something enough times it becomes reality.

At least the Rust subreddit figured out that there's this other language which fulfills the same requirements of being a higher level C, except unlike Rust it has a massive ecosystem, mind share and vendor support - including from Intel. It does have worse PR, but this is mostly because Rust is unbeatable here.

It would be interesting to also hear from Josh's colleagues which work on a large number of C and C++ projects. Do they agree that Rust is the future? And does that mean that all of Intel's money-making software is essentially obsolete? Is Intel the company aware of that?

dhyft• 7 years ago

At least the Rust subreddit figured out that there's this other language which fulfills the same requirements of being a higher level C, except unlike Rust it has a massive ecosystem, mind share and vendor support - including from Intel. It does have worse PR, but this is mostly because Rust is unbeatable here.

Which language are you talking about? C++?

blub2• 7 years ago

Yes, C++. Although I'm not convinced that Intel's ready to move away from C to be honest.

damnyou3• 7 years ago

I like Rust because C++ is simply beyond my cognitive abilities.

dang• 7 years ago

https://news.ycombinator.com/item?id=20790681

sdinsn• 7 years ago

I think Rust is a cool language, but I've never seen any job postings for it.

I'm still not sure what type of applications to use it for to be honest- not having good support for embedded systems and no CUDA/OpenCL support makes it not appealing.

Rust is the future, C is the new Assembly: Josh Triplett (Intel)

Related Stories