33 ms·

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

157 points by amaccuish 7y ago

prideout 7y 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!
- eej2ya1K 7y 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 7y 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.
    - eej2ya1K 7y ago
      The last one I tried was ripgrep, and something about the default behavior just drove me insane... I'll freely admit that it's all about aesthetics and there's no right answer, but that doesn't mean my preferences go away ;)
      - ik7tb 7y ago
        It's not meant to work exactly like `grep`, if that's what you're on about. If anything, I'd say reimplementing working tools in another language is pointless. It's like when bands cover songs. Who cares if another band plays the song if they don't put their own spin on it? So it's more that you don't care for the tool than the language in this case. Although, I invite you to try ripgrep again and/or lay out some of your gripes with it. I find it a very good replacement for grep.
      - burntsushi 7y ago
        alias rg="rg -uuu" That will disable all smart filtering and make it behave more like `grep -r`. Defaults matter and a lot of folks appreciate them, including plenty of old Unix greybeards that I've talked to about it. (I used plain grep myself for well over ten years before writing ripgrep.) But the defaults don't need to pin you down. They can be disabled very easily. :)
      - feanaro 7y ago
        Did you not also mention problems with portability and UNIX conventions?
        eej2ya1K 7y ago
        Yes, and sorry, that's not specifically related to ripgrep. About a year ago I tried to compile a few rust tools and a bunch of them just straight up didn't work at all because they made assumptions that are only valid for debian/ubuntu based distros. I'm glad people are enjoying rust, and sure, memory safety is nice. Fun and comfort are even better, though, so I'll stick to C, Lua and Go for my personal projects.
        feanaro 7y ago
        Yeah, I was just surprised since I specifically found Rust tools to generally both fun and comfortable due to having (what I consider) excellent UX.
        feanaro 7y ago
        Here is for instance a Rust tool that I just stumbled upon that seems to have an exemplary UX and adherence to Unix principles while packing a lot of features which I would personally call "fun". https://github.com/sharkdp/pastel https://github.com/sharkdp/pastel
        Corrado 7y ago
        Wow, that's a tool that I didn't know I needed until now. Being a back-end engineer I don't often deal with color information, but every once in a while I have to build a web page or tweak some CSS and it always a pain for me to remember color hex values. This tool should make this much easier. As a bonus, it gives you similar colors and can generate random or distinct color pallets.
  - steveklabnik 7y 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.)
    - burntsushi 7y ago
      Yeah this is a big benefit that is undersold. If I were in the C or C++ ecosystem, I probably wouldn't be able to support Windows as well as I do. It would be too much work. The foundations on which Rust's standard library are built means I can regularly go through entire release cycles without opening my Windows laptop to test anything. Which saves a lot of context switching overhead for me personally.
  - jedisct1 7y ago
    When it comes to portability, Go is really awesome.
- Diggsey 7y 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.
  - eej2ya1K 7y 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...
    - dunefox 7y ago
      > Rust is the first one I'm too stupid to understand. More complicated than Haskell, etc.?
      - eej2ya1K 7y ago
        I'm probably too stupid for Haskell, too, but in my experience the Haskell community actually acknowledges that the language is hard! The patronizing attitude of rust defenders here on HN, on the other hand, man... it just pushes me further away.
    - _bxg1 7y ago
      It's not that hard, it just brings very unfamiliar ideas to the table. If you've used a bunch of different languages, most other languages can be picked up pretty quickly by combining different aspects you're familiar with from the ones you know. That's not the case for Rust. It takes a few solid weeks of feeling stupid until you really start to grasp borrowing, and that experience may feel offensive to people who are used to knowing what they're doing, but a few weeks really isn't that much time in the grand scheme of things.
- degraafc 7y 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 https://ziglang.org
  - dgellow 7y ago
    Both V (https://vlang.io/ https://vlang.io/) and Zig seem really interesting, I also hope they will reach maturity
    - networkimprov 7y ago
      +1 for Zig, tho it has a long way to go. I've seen ppl say that something seems amiss with the V project.
    - Verdex 7y ago
      There is also: https://github.com/odin-lang/Odin https://github.com/odin-lang/Odin and https://www.kitlang.org/ https://www.kitlang.org/ That are trying to get into the C replacement business.
  - jedisct1 7y 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.
- guggle 7y ago
  Ah ! Nim... as a Pythonista, I'm loving its aesthetics. However in the end it's all about community support, available libs, tooling...
sleepysysadmin 7y ago
Rust and Python. I see Rython in the future. edit/sorry?
- dbcurtis 7y 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 7y ago
    Maybe he means a python implemented in rust
    - dbcurtis 7y ago
      Good point! That would probably make validating the Python interpreter easier.
  - fb03 7y ago
    I too am having problems 'getting into' Rust because of all that salad-y syntax. It looks like Perl at some times ;__;
    - eterps 7y ago
      My thoughts exactly, it reminds me a lot of Perls (lack of) readability. I would love a Rust variant with a mix of Python/Nim/F#/OCaml syntax.
    - johnisgood 7y ago
floor_ 7y ago
Rust has a npm package problem. For reference: https://twitter.com/bascule/status/1166583003021283333 https://twitter.com/bascule/status/1166583003021283333
- dpc_pw 7y ago
  But also has a solution: https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev
  - floor_ 7y ago
    This is a solution to a problem that shouldn't have happened in the first place.
    - swsieber 7y ago
      It's a naturally occurring phenomena when publishing packages is easy. There are various ways to address it: * Make it harder to publish * Make it easier to find quality packages I'd prefer the latter.
      - deleted 7y ago
        [deleted]
    - dpc_pw 7y ago
      The alternatives are: * Have every single common thing live in a standard library which makes them stagnate, slows down language development and so on. * Have people roll their own half-baked, half-broken code every time. I stand firmly that big organic ecosystem of packages and thin library is the right way, and all we need is just better tools to manage trust and quality. https://twitter.com/dpc_pw/status/1166754923381280768 https://twitter.com/dpc_pw/status/1166754923381280768
      - johnisgood 7y ago
        1. If it is really common, then yes. Why not? It does not necessarily stagnate or slow down anything. People working on current official crates can do that were it in the standard library. 2. I am not so sure about that. There are many crates that are just a few lines of code. They are not that difficult to get right, but the mentality dictates that you import a crate instead of writing those "easy" one to ten lines. I am not sure it is the right way of doing it because it suffers from the same problems npm does. Making (and maintaining) more tools to patch up these issues is not exactly a great solution to me. What if these tools have issues, too? Do we create tools to patch up the issues of these other tools, ad infinitum? Few lines of code you write yourself, or: https://pbs.twimg.com/media/EDCMkVMXkAIwdI1.png https://pbs.twimg.com/media/EDCMkVMXkAIwdI1.png
ErotemeObelus 7y 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 7y 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.
  - ErotemeObelus 7y ago
    "C is portable" for some definition of portable I suppose
  - pjmlp 7y ago
    At Bell Labs, on the outside people where already using plenty of Algol and PL/I variants.
- damnyou 7y ago
  Why are closures unsuitable for systems programming? Rust does them really well, not even allocating in the most common cases.
  - jerf 7y 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.
jedisct1 7y 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 7y 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 7y 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 7y 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.
jefftime 7y 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 7y 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?
  - jefftime 7y ago
    That's a good point! This might be a good way to go about it
- JoshTriplett 7y 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-Fish 7y 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.
    - 7y ago
davidhyde 7y 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 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 7y ago
  >Most Rust programs, like most c programs, do have a runtime. See https://doc.rust-lang.org/0.12.0/guide-runtime.html 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.
- roblabla 7y 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.
- steveklabnik 7y 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 7y 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 7y 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.
codesushi42 7y 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 7y ago
  Can you show some sample code in Rust with this memory management cost that C doesn't have?
- atoav 7y 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.
  - codesushi42 7y 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.
    - pjmlp 7y ago
      C will be replaced, as soon at the last dev that keeps religiously using C89 with language extensions retires.
jeffdavis 7y 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.
- pjmlp 7y 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 7y ago
    Yes. But then you have to use COM :P
    - smitty1e 7y ago
      I knew this one guy who still did a little VBA when he thought no one was looking. . .
    - pjmlp 7y ago
      All major Windows APIs are based on COM since Vista, as the .NET Longhorn ideas got rebooted as COM libraries. With Windows 8, it got a new facelift (WinRT, UAP, UWP) and the large majority of Win32 APIs are as they were in Windows 7. Anyone doing modern Windows development, has to use COM in some form.
      - 7y ago
blub 7y 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 7y 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++?
  - blub 7y ago
    Yes, C++. Although I'm not convinced that Intel's ready to move away from C to be honest.
- damnyou 7y ago
  I like Rust because C++ is simply beyond my cognitive abilities.
dang 7y ago
https://news.ycombinator.com/item?id=20790681 https://news.ycombinator.com/item?id=20790681
sdinsn 7y 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.

157 points by amaccuish 7y 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!

eej2ya1K 7y 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 7y 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.
  - eej2ya1K 7y ago
    The last one I tried was ripgrep, and something about the default behavior just drove me insane... I'll freely admit that it's all about aesthetics and there's no right answer, but that doesn't mean my preferences go away ;)
    - ik7tb 7y ago
      It's not meant to work exactly like `grep`, if that's what you're on about. If anything, I'd say reimplementing working tools in another language is pointless. It's like when bands cover songs. Who cares if another band plays the song if they don't put their own spin on it? So it's more that you don't care for the tool than the language in this case. Although, I invite you to try ripgrep again and/or lay out some of your gripes with it. I find it a very good replacement for grep.
    - burntsushi 7y ago
      alias rg="rg -uuu" That will disable all smart filtering and make it behave more like `grep -r`. Defaults matter and a lot of folks appreciate them, including plenty of old Unix greybeards that I've talked to about it. (I used plain grep myself for well over ten years before writing ripgrep.) But the defaults don't need to pin you down. They can be disabled very easily. :)
    - feanaro 7y ago
      Did you not also mention problems with portability and UNIX conventions?
      - eej2ya1K 7y ago
        Yes, and sorry, that's not specifically related to ripgrep. About a year ago I tried to compile a few rust tools and a bunch of them just straight up didn't work at all because they made assumptions that are only valid for debian/ubuntu based distros. I'm glad people are enjoying rust, and sure, memory safety is nice. Fun and comfort are even better, though, so I'll stick to C, Lua and Go for my personal projects.
        feanaro 7y ago
        Yeah, I was just surprised since I specifically found Rust tools to generally both fun and comfortable due to having (what I consider) excellent UX.
        feanaro 7y ago
        Here is for instance a Rust tool that I just stumbled upon that seems to have an exemplary UX and adherence to Unix principles while packing a lot of features which I would personally call "fun". https://github.com/sharkdp/pastel https://github.com/sharkdp/pastel
        Corrado 7y ago
        Wow, that's a tool that I didn't know I needed until now. Being a back-end engineer I don't often deal with color information, but every once in a while I have to build a web page or tweak some CSS and it always a pain for me to remember color hex values. This tool should make this much easier. As a bonus, it gives you similar colors and can generate random or distinct color pallets.
- steveklabnik 7y 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.)
  - burntsushi 7y ago
    Yeah this is a big benefit that is undersold. If I were in the C or C++ ecosystem, I probably wouldn't be able to support Windows as well as I do. It would be too much work. The foundations on which Rust's standard library are built means I can regularly go through entire release cycles without opening my Windows laptop to test anything. Which saves a lot of context switching overhead for me personally.
- jedisct1 7y ago
  When it comes to portability, Go is really awesome.
Diggsey 7y 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.
- eej2ya1K 7y 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...
  - dunefox 7y ago
    > Rust is the first one I'm too stupid to understand. More complicated than Haskell, etc.?
    - eej2ya1K 7y ago
      I'm probably too stupid for Haskell, too, but in my experience the Haskell community actually acknowledges that the language is hard! The patronizing attitude of rust defenders here on HN, on the other hand, man... it just pushes me further away.
  - _bxg1 7y ago
    It's not that hard, it just brings very unfamiliar ideas to the table. If you've used a bunch of different languages, most other languages can be picked up pretty quickly by combining different aspects you're familiar with from the ones you know. That's not the case for Rust. It takes a few solid weeks of feeling stupid until you really start to grasp borrowing, and that experience may feel offensive to people who are used to knowing what they're doing, but a few weeks really isn't that much time in the grand scheme of things.
degraafc 7y 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 https://ziglang.org
- dgellow 7y ago
  Both V (https://vlang.io/ https://vlang.io/) and Zig seem really interesting, I also hope they will reach maturity
  - networkimprov 7y ago
    +1 for Zig, tho it has a long way to go. I've seen ppl say that something seems amiss with the V project.
  - Verdex 7y ago
    There is also: https://github.com/odin-lang/Odin https://github.com/odin-lang/Odin and https://www.kitlang.org/ https://www.kitlang.org/ That are trying to get into the C replacement business.
- jedisct1 7y 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.
guggle 7y ago
Ah ! Nim... as a Pythonista, I'm loving its aesthetics. However in the end it's all about community support, available libs, tooling...

sleepysysadmin 7y ago

Rust and Python. I see Rython in the future. edit/sorry?

dbcurtis 7y 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 7y ago
  Maybe he means a python implemented in rust
  - dbcurtis 7y ago
    Good point! That would probably make validating the Python interpreter easier.
- fb03 7y ago
  I too am having problems 'getting into' Rust because of all that salad-y syntax. It looks like Perl at some times ;__;
  - eterps 7y ago
    My thoughts exactly, it reminds me a lot of Perls (lack of) readability. I would love a Rust variant with a mix of Python/Nim/F#/OCaml syntax.
  - johnisgood 7y ago

floor_ 7y ago

Rust has a npm package problem. For reference: https://twitter.com/bascule/status/1166583003021283333 https://twitter.com/bascule/status/1166583003021283333

dpc_pw 7y ago
But also has a solution: https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev
- floor_ 7y ago
  This is a solution to a problem that shouldn't have happened in the first place.
  - swsieber 7y ago
    It's a naturally occurring phenomena when publishing packages is easy. There are various ways to address it: * Make it harder to publish * Make it easier to find quality packages I'd prefer the latter.
    - deleted 7y ago
      [deleted]
  - dpc_pw 7y ago
    The alternatives are: * Have every single common thing live in a standard library which makes them stagnate, slows down language development and so on. * Have people roll their own half-baked, half-broken code every time. I stand firmly that big organic ecosystem of packages and thin library is the right way, and all we need is just better tools to manage trust and quality. https://twitter.com/dpc_pw/status/1166754923381280768 https://twitter.com/dpc_pw/status/1166754923381280768
    - johnisgood 7y ago
      1. If it is really common, then yes. Why not? It does not necessarily stagnate or slow down anything. People working on current official crates can do that were it in the standard library. 2. I am not so sure about that. There are many crates that are just a few lines of code. They are not that difficult to get right, but the mentality dictates that you import a crate instead of writing those "easy" one to ten lines. I am not sure it is the right way of doing it because it suffers from the same problems npm does. Making (and maintaining) more tools to patch up these issues is not exactly a great solution to me. What if these tools have issues, too? Do we create tools to patch up the issues of these other tools, ad infinitum? Few lines of code you write yourself, or: https://pbs.twimg.com/media/EDCMkVMXkAIwdI1.png https://pbs.twimg.com/media/EDCMkVMXkAIwdI1.png

ErotemeObelus 7y 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 7y 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.
- ErotemeObelus 7y ago
  "C is portable" for some definition of portable I suppose
- pjmlp 7y ago
  At Bell Labs, on the outside people where already using plenty of Algol and PL/I variants.
damnyou 7y ago
Why are closures unsuitable for systems programming? Rust does them really well, not even allocating in the most common cases.
- jerf 7y 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.

jedisct1 7y 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 7y 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 7y 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 7y 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.

jefftime 7y 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 7y 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?
- jefftime 7y ago
  That's a good point! This might be a good way to go about it
JoshTriplett 7y 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-Fish 7y 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.
  - 7y ago

davidhyde 7y 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 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 7y ago
>Most Rust programs, like most c programs, do have a runtime. See https://doc.rust-lang.org/0.12.0/guide-runtime.html 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.
roblabla 7y 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.
steveklabnik 7y 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 7y 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 7y 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.

codesushi42 7y 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 7y ago
Can you show some sample code in Rust with this memory management cost that C doesn't have?
atoav 7y 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.
- codesushi42 7y 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.
  - pjmlp 7y ago
    C will be replaced, as soon at the last dev that keeps religiously using C89 with language extensions retires.

jeffdavis 7y 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.

pjmlp 7y 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 7y ago
  Yes. But then you have to use COM :P
  - smitty1e 7y ago
    I knew this one guy who still did a little VBA when he thought no one was looking. . .
  - pjmlp 7y ago
    All major Windows APIs are based on COM since Vista, as the .NET Longhorn ideas got rebooted as COM libraries. With Windows 8, it got a new facelift (WinRT, UAP, UWP) and the large majority of Win32 APIs are as they were in Windows 7. Anyone doing modern Windows development, has to use COM in some form.
    - 7y ago

blub 7y 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 7y 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++?
- blub 7y ago
  Yes, C++. Although I'm not convinced that Intel's ready to move away from C to be honest.
damnyou 7y ago
I like Rust because C++ is simply beyond my cognitive abilities.

dang 7y ago

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

sdinsn 7y 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.