56 ms·
Perhaps the future of software isn't "rewrite everything in Rust", but instead we end up annotating existing C/C++ with borrow checking information. This would
by matthewbauer 7y ago
Perhaps the future of software isn't "rewrite everything in Rust", but instead we end up annotating existing C/C++ with borrow checking information. This would be similar to how there is a push in JavaScript to add TypeScript annotations everywhere. It gives you the flexibility of the existing language and ecosystem while still allowing you to use new techniques in programming languages.
- swsieber 7y agoI think we'll c/c++ increasingly use those (in addition to the other wonderful tooling it has). I think Rust still has a strong future though - it has safety by default, and I really like it apart from the borrow checker. That said, I like this push for more programmatic checks.
- rubber_duck 7y agoMy problem with C++ isn't the lack of borrow checker - this is the feature I like the least in Rust (I know it's their core design goal but frankly the inconvenience and limitations it imposes don't seem worth it for my use case, and then theres the compile times). C++ lack of modules and package management on the other hand is a huge PITA and I'm not optimistic either of those bolted on so late in to the language lifecycle will provide a useful solution. It's a pity D took it too far in the other direction with GC and runtime - I really could use a C with classes and modules.
- abraxaz 7y agoI think conan has real potential when it comes to package management Some example of what can be done with it https://gitlab.com/xadix/xonan https://gitlab.com/xadix/xonan It is kind of like gentoo portage or nix pkg and can be used to manage your tool chain also
- plq 7y agoI don't get conan. Portage can already create a linux root in your homedir (see the prefix project) and has a huge package repo. What am I missing?
- ComputerGuru 7y agoI find vcpkg to be a much more well thought out solution, or at least did at the time I was doing research into suggesting one for neovim during that discussion. It was clearly developed by a team that’s been around the proverbial dependency management block a few times, and offered more accommodations for working with existing codebases than Conan did.
- colatkinson 7y agoI could be wrong, but conan's "killer feature" is its integration with traditional artifact management solutions. Using it with Nexus (which also takes care of PyPI, npm, and basically every other binary package type under the sun) is fairly smooth sailing. vcpkg, on the other hand, as far as I know only exports to nuget and compressed archives. Nuget is great and all if you're purely in MS land, but otherwise... not so much. And with compressed archives, you're kinda on your own w.r.t versioning and so on. That being said, I'm much more familiar with conan, so please correct me if I'm wrong. Additionally, conan, being configurable via normal Python code (for better or worse), can really hack together pretty much any codebase (I've used it with autotools, MSBuild, CMake, and even Xcode). I will definitely agree that the vcpkg team does ultimately seem to be more experienced, and it's a more polished tool (the conan docs are... lacking in areas, and updating conan will occasionally break things). It'll be interesting to see the direction both tools go in the future, as I would really like cross-platform C++ dependency management to stop being a total PITA.
- arka2147483647 7y agoThe value borrow checker in Rust comes from the systemic ability of to eliminate an entire class of bugs. The value these kinds of smart Cpp/Compiler features comes from the ability to eliminate some instances of bugs. Which is great, and all, but I don't see that all of the great masses of Cpp code and libraries would be rewritten or annotated to use these new features. Which will sadly leave the impact of these developments particial.
- jononor 7y agoFor Python there are tools that automatically add static-typing hints. One could imagine the same to add most of the annotations for existing C++ code, such that only some of the code must be manually annotated. For critical codebases one could also imagine a linter rule that insists on full coverage. But sure, it is somewhat of an uphill struggle. Still a worthy goal, as I don't think we will get rid of the many massively popular C++ softwares anytime soon.
- ethanhunt_ 7y agoWhile partially using annotations only allows you to eliminate /instances/ of bugs, if you completely apply the annotations then it can allow you to eliminate the entire class of bugs (theoretically). Consider nullabiliy in java. > I don't see that all of the great masses of Cpp code and libraries would be rewritten or annotated to use these new features. It's much more likely and tractable that C++ libraries will be annotated than that they'll be rewritten from scratch in Rust.
- akling 7y agoI certainly hope that's where we're headed. The more we can tell the compiler about our code, the better. It might also be interesting to provide hints like "this int should only ever be in the range 1-30" :)
- bluGill 7y agoyou mean a contract https://en.cppreference.com/w/cpp/language/attributes/contract https://en.cppreference.com/w/cpp/language/attributes/contra... c++20 has this, baring something unexpected happening in ISO.
- zingermc 7y agoIs this a baby version of dependent types?
- riffraff 7y agoI believe contracts are checked at runtime, so not really.
- bluGill 7y agoContracts come in several forms. Some are checked at compile time. Some are checked at run time. Some the check is too expensive to actually run but is left for documentation. Compilers are expected to have a switch to turn off run time checking for production (just like assert)
- bigcheesegs 7y agoNothing in C++20 contracts requires any checking to be done at compile time. The only options currently required are runtime checking and no checking.
- bluGill 7y ago
- wyldfire 7y agoIn fact, Sutter (et al) are working on lifetimes in CppCoreGuidelines [1]. I built their clang tree and tried it out without bothering to RTFM and tried out the warning on a pile of C++ code. I naively assumed that it might be a generally-useful warning ("-Wlifetime") that's not ready to be introduced upstream. That's not the case AFAICT. What I suppose I would've learned from RTFM is that the profile specified by the guidelines is sorta like an opt-in 'dialect' to annotate/specify lifetime information. Without it, there's lots of spurious findings. Either that, or the codebase I tried it on isn't as good as I thought it was. Here's a couple of interesting examples of failure modes -Wlifetime can detect on godbolt[2][3]. I watched a video [5] a while back on the Guidelines Support Library (GSL) [4] and it seemed like a really interesting concept. I think it's a valuable idea and I'd love to see popular C++ projects leveraging it. I'm a card-carrying RESF member† (but have a day job w/mostly C++). Don't RIIR for one thing, RIIR to get all the things. Cargo is the sleeper hit of Rust. Hygienic macros and more! [1] https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetime.pdf https://github.com/isocpp/CppCoreGuidelines/blob/master/docs... [2] https://godbolt.org/z/dymV_C https://godbolt.org/z/dymV_C [3] https://godbolt.org/z/_midIP https://godbolt.org/z/_midIP [4] http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-gsl http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#... [5] CppCon 2017: Kate Gregory “10 Core Guidelines You Need to Start Using Now” https://www.youtube.com/watch?v=XkDEzfpdcSg https://www.youtube.com/watch?v=XkDEzfpdcSg † Rust Evangelism Strike Force -- maybe we really should have cards
- matthewbauer 7y agoRewriting stable software in Rust is a very bad idea. Especially in open source, where we don't have enough maintainers, it ends up hurting the ecosystem. A certain prominent GNOME maintainer has been trying this recently and breaking things along the way: https://gitlab.gnome.org/GNOME/librsvg/issues/456 https://gitlab.gnome.org/GNOME/librsvg/issues/456 Apparently, GObject Introspection doesn't even work in Rust, yet it is expected to be a perfectly valid replacement: https://github.com/gtk-rs/gir-files/issues/35 https://github.com/gtk-rs/gir-files/issues/35 Please don't be like these people! Keep the stable software we have, and maybe write new software in Rust.
- 7y ago
- arcticbull 7y agoThis is especially frustrating as the whole concept of moved values in C++ was introduced fairly recently in C++11. They did such a poor job of it that they introduced this whole new class of use-after-move bugs that should never have existed in the first place. Now we need annotations to make sure the new feature they half-assed a few years ago works the way it was supposed to? It appears the C++ working group is firing out new bugs faster than third-party teams can patch them. IMO it's time to accept C++ is a failed state, and move on. Luckily there are compatibility options to help you use C/C++ libraries in Rust.
- pcwalton 7y agoC and C++ cannot add borrow checking soundly while remaining any semblance of compatibility with the ecosystem. Consider what you would do with global variables, just to name one of many, many issues.
- de_watcher 7y agoWhy not? It's all done when you don't pass around raw references and pointers. The only hole that's left is use-after-move.
- pcwalton 7y agoVirtually all C++ in existence uses raw references and pointers. You can't even call a method without using one (the "this" pointer).
- billylindeman 7y agoAs someone who just re-wrote his project (from python) in rust I will say that it has been an incredibly rewarding and pleasant experience. C++ is fine, but most projects are riddled with ugly macros and #defines for features / platform specific code. Rust solves this in a fairly elegant way. Also, not having a package ecosystem in C/C++ is frustrating as hell. Cargo was the thing that pushed me over the hump to learn rust instead of just opting for c++, and it has paid off. It's not quite as ergonomic as go, but overall it has won me over and is my new favorite language. I'm excited to see how the story for rust plays out over the next 5 years :)
- pjmlp 7y agoHave you ever written a Rust macro? They aren't properly an example of beauty versus C and C++ ones. Cargo has gotten definitely better, but lack of support for binary libraries is a pain point.
- zahllos 7y ago"C++" (C++ people would argue this is not a language issue and therefore out of scope for them, hence the quotes. I'm not implying this is a bad decision to make, simply saying it's the argument I've read before) doesn't really support binary libraries well either. Name mangling, object layout, exception handling, dynamic dispatch are all things that different compilers are not guaranteed to implement in the same way. There's a survey of some of the implementations of these features here: https://www.agner.org/optimize/calling_conventions.pdf https://www.agner.org/optimize/calling_conventions.pdf , although it is a few years old now. This is to say nothing of differing implementations of functionality between different versions of the same compiler, which is of course possible. Most binary C++ libraries I've dealt with either require you use the same compiler, or export a C interface through extern "C". Rust doesn't really support shared objects from Rust to Rust at all, from what I can tell (caveat that I've never actually tried it). There's no stable ABI (https://github.com/rust-lang/rfcs/issues/600 https://github.com/rust-lang/rfcs/issues/600), and therefore the only way to go is via a C interface. So Rust is more or less in the same place, just with fewer compilers.
- Ar-Curunir 7y agoThe plus points of Rust aren't just borrow checking, but also the removal of sons of cruft and the benefit of modern tooling and language design.
- _pmf_ 7y agoEvolutionary improvement of mature tools instead of jumping on bandwagons is not very street, yo. Greenfield development or GTFO.