Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
carbon-lang
Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
-
checkedc
Checked C is an extension to C that lets programmers write C code that is guaranteed by the compiler to be type-safe. The goal is to let people easily make their existing C code type-safe and eliminate entire classes of errors. Checked C does not address use-after-free errors. This repo has a wiki for Checked C, sample code, the specification, and test code.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
cryptography
cryptography is a package designed to expose cryptographic primitives and recipes to Python developers.
-
CppCoreGuidelines
The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++
-
bc
An implementation of the POSIX bc calculator with GNU extensions and dc, moved away from GitHub. Finished, but well-maintained.
-
-
-
In theory yes, but there's a lot of quirks and limitations.
The main issues are:
- Rust string types assume UTF-8, but Windows generally uses double-byte Unicode encodings. The Windows string type isn't even UTF16, because it can include invalid code points. This means that at every API call there will be the overhead of converting the string encodings.
- Rust compilation is still very slow. In C++, it was a simple matter of including "windows.h" and then start typing code. In Rust, trying to do this naively would result in terrible "inner loop" for the developers. There are some fixes, but they're fiddly.
- Enormous API surface with missing metadata. This is a problem with Rust-to-C interop in general, but the Win32 APIs are so huge that it's impractical to solve manually. There have been efforts by Microsoft to produce official and authoritative interface definitions with additional metadata such as tagging "in" and "out" parameters, etc... This isn't sufficient for Rust, which has a much more complex type system than vanilla C pointers. E.g.: lifetimes, non-null by default, etc...
At this time, programming in Rust for Windows is basically writing C++ code in Rust syntax, but with a slower compile time than C++ would have. Arguably, there isn't even much of a safety benefit, because that would require an extensive set of "shims" to be produced to make Win32 act more like Rust and less like C/C++. Take a look at the size of the .NET Framework standard library to get an idea of what that entails. Not impossible, but not a trivial effort either!
The best and most authoritative bindings are: https://github.com/microsoft/windows-rs
The "demo" looks okay at first glance:
unsafe {
> Even a doubly-linked list is impossible to get through the borrow checker.
https://github.com/rust-lang/rust/blob/master/library/alloc/...
It's part of standard lib. And you don't get more idiomatic than that.
Most of the worst issues with C++ can't actually be fixed without backwards incompatible changes that would break large amounts of existing code. Google spent several years advocating for the approach that you're suggesting, but was unable to persuade other members of the C++ standards committee and recently announced that they're working on a replacement language. The rationale for Carbon goes into great detail on why fixing C++ isn't a viable option.
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
https://github.com/carbon-language/carbon-lang
Yes. Microsoft Research is working on "Checked C": https://www.microsoft.com/en-us/research/project/checked-c/
As a test, someone ported FreeBSD's networking stack to Checked C. It was easy and there was no overhead to performance and binary size.
I have a good news for you. Recently, two IBM employees appeared on Rust's issue tracker and reported their intention to port Rust to AIX.
https://github.com/rust-lang/compiler-team/issues/553
People are working on it, here is a draft: https://spec.ferrocene.dev/
Compare Stepanov's brilliant design of the STL to Rust's current reworking of their 'binary search api'. https://github.com/rust-lang/libs-team/issues/81
Maybe 'memory safety' isn't the most important thing in this world. To me, writing software that does useful things in the simplest and most correct way is what matters. I get the feeling it's harder to understand my program's correctness with Rust (I mean algorithmic correctness). The C++ standard library has time and space complexity for every algorithm. I'm not seeing that's the case with Rust (correct me if I'm wrong).
> I am curious. Could you give some more context?
Probably talking about this: https://github.com/pyca/cryptography/issues/5771
> If you're perfectly attentive and constantly vigilant, maybe
That used to be the case 10 or 15 years ago. Today it is much easier to "follow the rules", because:
1. You used to need to tread carefully to both follow them and do what you needed to; now you can do more complex things more easily. Example: In the past, you couldn't avoid new and free being strewn around your code. These days, you can avoid them entirely when not implementing a complex data structure of your own.
2. A decent version of "the rules" is basically explicit: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
3. The standard library and other FOSS libraries do a lot of the rule-following for you
(4. Compilers are more attentive and do more static checking.)
>Notice that I said to find a memory bug in a release, not just any commit.
You did not say anything of the sort.
>But I also said to find one in the program, not the library.
You did not say anything of the sort.
You said:
>>The code is my `bc`. [1]
>>Find a memory bug, any memory bug, in my `bc` after 1.0.
>>[1]: https://git.yzena.com/gavin/bc
But okay, let's acknowledge the moved goalposts.
>I issue that challenge again: find a memory bug in the `bc` or `dc` program in a release after 1.0.
Tell me what subset of the repo named "bc" you consider to be "the program"
>Oh, and the double-free with `SIGINT`? Rust isn't going to help you much there. Signals are not part of Rust's model.
Crates like tokio-signal allow a signal to be converted to a stream of events, which can be handled along with any other events in the program, instead of interrupting the current fn in the middle and necessitating longjmp shenanigans.
Most GUI apps don't need what Qt provides though. They mostly need stability and cross-platform support, so ... they should start with something like Tauri or Sciter, and if there is something they need natively they will be in a much better situation to pick their poison.
https://github.com/tauri-apps/tauri uses OS provided WebView
https://github.com/sciter-sdk/rust-sciter uses Sciter
Most GUI apps don't need what Qt provides though. They mostly need stability and cross-platform support, so ... they should start with something like Tauri or Sciter, and if there is something they need natively they will be in a much better situation to pick their poison.
https://github.com/tauri-apps/tauri uses OS provided WebView
https://github.com/sciter-sdk/rust-sciter uses Sciter
It's not a guaranteed guarantee as far as I can understand.
Or such bugreports would make no sense: https://github.com/denoland/deno/issues/15020