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.

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 :-)

To be fair: snaps can work for all kinds of things all over the stack from the kernel to individual applications, while flatpak just does applications. Canonical is building a lot around those abilities to handle lower level things, so I guess it makes sense for them.

IMHO flatpak does the applications better and more reliably and those are what I personally care for, so I personally stay away from snaps.

It is all about whos freedom you care for: GPL protects the freedom of end users, MIT and other permissive licenses focus on the freedoms of developers instead.

GPL defines freedoms end users of software have. It has to limit the freedoms of developers between the GPL project and the end user so that those developers can not strip out any of the freedoms the GPL wants end users to have. The hope is to build a better society by enabling everybody to understand the machines they own.

MIT and other permissive license care for the freedoms of people using the project directly, granting freedoms to those users only. Those people are free to forward the same rights to their own users or to remove them as they see fit. Thatbis way simpler for developers to work with: Basically do whatever you want.

Guess which option is more popular with developers and the companies that employ many of those developers?

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”.

You are not done one the config is written: A configuration requires maintenance effort: New plugins get released, others stop getting developed, APIs change. You constantly need to adapt your configuration.

That is why I recommend using a distribution like astonvim. A distribution takes care of keeping the basics going and gives a well msintained base and thus gives you more time to fiddle with the interesting bits of the configuration.

Astronvim in particular is “just” a lazy nvim config and very easy to customize, filtering the standard override process defined by the lazy plugin manager.

I actually got rid of most custom config I had on top of astronvim by using its community repository: It contains easy to add config snippets that fully integrate other plugins with all the plugins in the astronvim config (lsp setup, treesitter, snippets, completion, …). This ranges from adding one plugin to entire language packs with all the recommended bells and whistles to work with some programming language.

A good choice… another ist astronvim.

Astronvim covers the basic setup and their community repo with its language packs the specifics :-)

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:-(

The basics are all the same:. memory, cpus and caches in between ;-)

But rust does approach many things very differently from C or C++. Learning those new approaches takes time and practice.

Watch out: That mindset is what got me into Rust in the first place!

I was so fed up with everybody drowning on about Rust that I thought I need to read up on it a bit so that I can argue against the hype. I am a seasoned C++ dev after all, I use a language that I picked because it allowed for robust and fast code. What could Rust add on top of that?

Well, I have a job working almost exclusively with rust now and do not plan to ever go back.

https://docs.rs/document-features/latest/document_features/ helps to document features.

But yes, features are under-documented.

I did tick that, since I saw text boxes and went “give me everything” without reading:-)

Fixed. Thank you for pointing this out.

Slint fits the bill: We have a demo running on a line-buffer in a microcontroller with <300KiB of RAM. Framebuffers are of course supported as well, as is GPU-accelerated rendering.

What is actually meassured there? “Line goes down” is not necessary a bad thing:-)