5 ms·
There are new programs being written daily in COBOL and Fortran, and I'm fairly certain that I see new PL/I floating around occasionally. C and C++ aren't goin
by ninefathom 4y ago
There are new programs being written daily in COBOL and Fortran, and I'm fairly certain that I see new PL/I floating around occasionally.
C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time.
Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything is x86, and one of five operating systems" issues as recently as late 2021. Rusties of the world: your language might be ready to take up the mantle of C- it's you and your ecosystem that I question.
If Rusties want Rust to displace C... simplify your dependency chains. Get a build system that's easily workable without an Internet connection and recent TLS support. Make it easy for beginners to build out Rust infrastructure for OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU. Make it feasible to get Rust everywhere that C currently is... then we'll discuss getting rid of C. Until then it's just wind.
- humanrebar 4y agoThe fact that Rust has a whole other ecosystem is the main thing that gives me pause. For all their faults, C and C++ targets the ecosystem you have: gems, pip, Conan, Nix, ...doesn't matter. They don't expect you to port to a new ecosystem. They can contort to meet your needs. Herb Sutter's latest proposal and, to a slightly lesser degree, Carbon are more interesting in that respect.
- Ar-Curunir 4y agoWhat? You can totally compile Rust for compatibility with python libraries or Ruby libraries or whatever you want. Rust can offer the same API that C/C++ offer, so it can be a drop-in replacement.
- humanrebar 4y ago...as long as you're fine shelling out to cargo, right? What if that's not appropriate or ergonomic? There's a world where Rust is as easy to use as C, C++, Fortran, etc. outside of cargo, but it's not an interesting use case for the Rust community to support right now for whatever reason. That's basically my point. And it's common enough to have linked programs in which python calls C that calls C++ that calls Fortran that calls C. Replacing arbitrary layers with Rust is technically possible, though Rust doesn't tend to be deployed in situations like that, at least not yet. I'll consider the Rust ecosystem more mature when you see Rust used mixed ELF situations like that.
- ninefathom 4y ago"There's a world where Rust is as easy to use as C, C++, Fortran, etc. outside of cargo, but it's not an interesting use case for the Rust community to support right now for whatever reason. That's basically my point." Yep. The Rust ecosystem is very much a product of the always-connected, move-fast-and-break-things, DevOps-CI/CD-SCRUM-Agile, horizontal scaling world... which is fine right up until the point where it needs to be used outside of that world, at which point all hell breaks loose.
- nindalf 4y agoWhat a strange comment. It’s true that building Rust projects is easy with cargo and hard without. But how did you go from that to “move-fast-and-break-things”? Could you give an example of a broken thing? Is the Linux kernel “DevOps-CI/CD”? Does Linus Torvalds manage the project in a “SCRUM-Agile” way? Let’s find out if “all hell breaks loose” when we get Linux 6.1.
- unrealhoang 4y agoRust-for-Linux doesn't use cargo, yet no satan or demon appears anywhere. Yes, adding dependencies is not single line updated like Cargo-based workflow, but also not that much different than adding a C/C++ dependency.
- pornel 4y agoC/C++ target a fragmented mess that's different on every platform and inconsistent across projects. Technically you can invoke rustc the same way you invoke cc, and craft makefiles and handle all your dependencies the old way, but it's so tedious and fragile compared to Cargo that nobody wants to.
- humanrebar 4y agoIt's also possible to have simple enough C and C++ packaging. A lot of the problem is just inertia and education. But a lot of the problem is also that C and C++ are designed (if only implicitly) to work in all kinds of contexts as a feature.
- nicoburns 4y agoNope, C and C++ target the C and C++ ecosystem. If that’s the ecosystem you have then presumably that’s because your a C or C++ developer and that’s what you’re used to. Personally I find installing C and especially C++ libraries a massive pain.
- humanrebar 4y agoI can't speak to your experiences, but there isn't one C or C++ ecosystem. It's common to write C or C++ to target: ruby, python, Java, Linux distros, C++ package managers, numeric analysis ecosystems, OS kernel development, embedded ecosystems, game ecosystems, robotics, wasm, and JS ecosystems. And I'm positive that's not a complete list.
- lmm 4y ago> If Rusties want Rust to displace C... simplify your dependency chains. Get a build system that's easily workable without an Internet connection and recent TLS support. Make it easy for beginners to build out Rust infrastructure for OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU. C is welcome to that niche IMO. The priority is getting people to stop using C or C++ for regular applications that are exposed to the internet; if Rust can replace those use cases then it'll be job done.
- notacoward 4y agoMost of those applications would probably be just fine with a GC language, so the cognitive load of doing things safely in any non-GC language is probably a waste.
- lmm 4y agoSure, but given that even today people still feel the need to write applications in non-GC languages for some godforsaken reason, it's good that Rust is there for them. Making a new language is easier than educating the developer population, sadly.
- nicoburns 4y agoMost of them might be fine in a GC language, but most of those GC language apps will bind to C libraries as some point. It’s those underlying components we need to start to replace for truly robust systems.
- markus_zhang 4y ago> The priority is getting people to stop using C or C++ for regular applications that are exposed to the internet; But I think this is already been taken care of by Java and others?
- WiSaGaN 4y ago> Get a build system that's easily workable without an Internet connection and recent TLS support. I'll say typing `cargo build --offline` can qualify as "easily workable".
- shakna 4y agoHow do you vendor to local, without the recent TLS support?
- howinteresting 4y agoCopy it over from a normal computer.
- baq 4y agowith an USB stick? like an animal? /s
- pitaj 4y ago> C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time. Nobody denies this, which is why one of Rust's main goals was supporting the C ABI, so Rust can use existing C libraries, or an application written in C can use Rust libraries. > Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything is x86, and one of five operating systems" issues as recently as late 2021. I am curious. Could you give some more context? > Get a build system that's easily workable without an Internet connection and recent TLS support. Cargo supports vendoring dependencies and local dependencies. > Make it easy for beginners to build out Rust infrastructure for OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU. When has it even been easy for beginners to build out systems infrastructure? Progress is being made on allowing Rust to target more platforms, including `rustc_codegen_gcc` and `gcc-rs`.
- imron 4y ago> I am curious. Could you give some more context? Probably talking about this: https://github.com/pyca/cryptography/issues/5771 https://github.com/pyca/cryptography/issues/5771
- spoiler 4y ago> Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything is x86 Anecdotally, I had the same issue recently with a C++ tool I wanted to tun on arm linux (forgot what it was; but it was a WASM tool. I ended up using a Rust alternative that was less mature, but did all I needed anyway) Lastly, the issue you're describing is more of a DevOps one. C++ has a longer history, and one would hope it has accumulated more DevOps wisdom over that period of time.
- ninefathom 4y ago"one would hope it has accumulated more DevOps wisdom over that period of time" Yep. My thoughts exactly.
- baq 4y ago> beginners > OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU what?
- pie_flavor 4y agoIt's not like it's any different for C. Rust gives you a choice of five operating systems? A given C library gives you a choice of one, on a good day. And if you've got your favorite C library already then binding to it is a breeze. I don't understand the mindset that because Rust and its entire ecosystem is less than perfect it should be junked for C which never even cracked a quarter of the distance.
- svnpenn 4y ago> Rusties please don't
- kweingar 4y agoIsn’t the whole shtick with programming language devotees that they have names for themselves like Rusties and Gophers and whatnot
- svnpenn 4y agoI use both of those, and I would just say "I use Rust and Go". I don't think "Rusties" is appropriate, unless you are 13 years old.
- Zanneth 4y agoCan’t be worse than “Rustaceans.”
- ninefathom 4y agoUpdate: Based on the comments here, I see that I need to clarify two things, as edits are locked. First, I actually happen to rather appreciate the Rust language itself. It is both powerful and pragmatic, and has quite a bit to recommend it. Even in situations where its addition has been personally very problematic for me (e.g. Firefox), I can still tip my hat to the added value. What I take strong exception to is Rust evangelism, i.e. the idea that Rust and its ecosystem are clearly superior to all other options in a given use case, and any person using other options must be either insane or uninformed. This represents, at best, a very narrow view of the computing ecosystem in the 21st century. My comment is a rebuke of the evangelism, not the language. Second, the term "rusties" might have (reasonably) seemed like a label that I applied to any Rust developer. This is not the case, and the perception is a result of my failure to clarify. There is a particular class of person whom one meets, with whom any discussion of any technology project inevitably leads to "well you really should write that in Rust." Such folks- overzealous Rust evangelists- are "rusties" in my vocabulary. If that describes you, feel free to take insult if you like. If that doesn't describe you, then my apologies for any misunderstanding.