A Slint fanboy from Berlin.
That depends a lot on how you define “correct C”.
It is harder to write rust code than C code that the compiler will accept. It is IMHO easier to write rust code than to write correct C code, in the sense it only uses well defined constructs defined in the C standard.
The difference is that the rust compiler is much stricter, so you need to know a lot about details in the memory model, etc. to get your code past the compiler. In C you need the same knowledge to debug the program later.
That depends on how you decide which bucket something gets thrown into.
The C++ community values things like the RAII and other features that developers can use to prevent classes of bugs. When that is you yard-stick, then C and C++ are not in one bucket.
These papers are about memory safety guarantees and not much else. C and C++ are firmly in the same bucket according to this metric. So they get grouped together in these papers.
The quote above covered exactly what you just said: “yet were also more likely to rate their insecure answers as secure compared to those in our control group” at work :-)
I am looking forward to follow up articles like “woodworking as a career isent right for me”, “bookkeeping as a career isent right for me” and the really enlightening “any job sucks when your boss is shit”.
The problem is that you lose out on dev attention when moving away from github.
I moved my projects into github when placeholder projects literally containing a README with a link to the real repo only got way more interaction on github than in the real repository: More stars, more views, more issue reports and even more PRs (where the devs have obviously Cloned the repo from the actual repository but could not be arsed to push there as well).
If you want your project to be visible, it needs to be on github at this point in time:-(
supply chain attacks are a serious problem that needs addressing.
Last I checked: I am not a supplier. So I will not invest effort to secure some supply chain for people that I do not have any obligations to: The license clearly states “no warranty” for a reason. I do those projects for fun, not to bother me with security stuff, notifications about security problems some automatic thing “found” that do not really effect my code and bogus merge requests to upgrade dependencies for no reason… this are all cool things if you are a supplier, do not get me wrong, but I am not. No, I will not invest hours of my free time to sign binaries nobody uses either or to fill out security surveys for badges I can display on github.
If you want me to act like a supplier: Pay me like all the other suppliers you have. I doubt there is any interest to do so for the projects I have on my private github :-)
For your own projects, it might be worth considering a move away from GitHub. (I’ve been thinking about it since Microsoft bought them.) Codeberg looks like a good alternative.
That also has associated costs: Your project gets instantly much less visible, so you need to keep a mirror on github for visibility. Unfortunately that also means that you will also get interactions on github, so you will need to log in occasionally to not make people think the project is dead.
We can always use a UX person over at https://github.com/slint-ui/slint :-) Slint is a UI toolkit written in rust, but the UI is defined in a simple custom language that is really easy to pick up.
You could polish up existing demos, to create new ones and could even come up with new widgets.
We try to be a nice community, feel free to drop by and chat if you have questions in our mattermost instance hosted at https://chat.slint.dev/
What is actually meassured there? “Line goes down” is not necessary a bad thing:-)
What do you mean by “system support”? The system is mostly pushing bytes along, the programming languages/UI ovaries tend to do all the hard work. So it is usually more interesting to see what those support.
I’d go for open source projects. They usually have bigger code bases and good practices, that they enforce on their contributors with code reviews and such.
It’s a good way to get feedback on your code, something miss out on personal projects and get much less of in university and corporate projects.