The git.sr.ht service is just the tip of the iceberg, though. It also provides you with CI, issue tracking, mailing lists... And it works perfectly in Lynx so you don't even have to leave command line to use the browser interface.
I have a codebase that amounts to several kLOC of C++, available here: https://git.sr.ht/~maelkum/viuavm While I openly admit that parts of it are shoddily written, I also try to always use the "reliable subset" of C++.
From my experience it is not hard to make it a habit (e.g. using `::at()` and declaring variables as `auto const x = ...;` is muscle memory at this point) but the code becomes very verbose and looks like programmed defensively to a sometimes ridiculous extent.
So I understand your skepticism. To address the point of relying on developers being "ideal": just turn the compiler warning flags up to eleven, make all warnings errors, and run your tests two times - one time with sanitisers, and the other under Valgrind. This won't catch all errors, sure, but will still make you more confident in your code's reliability.
I am using this method to a great success at my current job. It leads to always having a clear, well-defined place where you look for changes related to issue XYZ.
Support from tooling also helps a lot, e.g. "checkout branch of issue XYZ".
Back in 2015, I decided that all the issue tracking systems I knew are too heavy-weight. I don't need kanban, agile, or any other buzz - I just need a simple tool to track my issues. I had several requirements: 1/ it must work off-line,
2/ it must be distrubuted (to allow many people working simultaneously on their off-line clones),
3/ it must work in command line,
4/ it must provide minimum distraction,
5/ it must allow me to tag, and search the issues,
and I worked from there.
fast forward to 2018 ...and I'm still using it. It does the job for my Free Software projects, and helps me at work (tested in three companies already). It is definitely not bug-free (but the risk of data-loss should be low), and the installation must be done manually from GitHub, but it Works For Me (tm) ;-)
Sample workflow:
$ issue open "OH noes, a bug"
$ issue ls --open
deadbeef OH noes, a bug
$ issue slug --git-checkout --git-branch --git deadbeef # or just issue sl -gBC de
...hack, hack hack...
$ git commit -am "Fix"
$ issue close -g HEAD de
$ git checkout master
$ git merge -
By using the `-` as the placeholder for "last active issue" I can make this sequence even shorter. Minimal distraction, no switching between the terminal and the browser, no waiting for slow Web interfaces.
It took me far too long to realise deadbeef was your example issue ID and not a username or something. Maybe I'm a little slow or maybe it's a lack of coffee.
Sure, compiling a language to a VM with mismatched semantics is not a pleasant experience. Viua's execution model of many processes communicating via messages is best suited to Erlang, or other actor model languages.
Yeah, the naming of "vector" is unfortunate, I'll give you that. In Viua, a vector is simply a data structure with push, pop, insert, etc. operations - a collection of values.
If I ever include vector instructions of the sort you expected then I'll base the design on what RISC-V did.
Hi, Viua VM's developer here - I am behind this project.
The initial target/goal for me was to create a programming language, but I found it hard to dig into GCC (didn't know about LLVM then), so I decided to create my own runtime VM. Thus, the VM was born.
Why I chose GNU GPL v3? Simply because I am a strong proponent of Free Software (you may have also found that Viua has a page on GNU Savannah).
The git.sr.ht service is just the tip of the iceberg, though. It also provides you with CI, issue tracking, mailing lists... And it works perfectly in Lynx so you don't even have to leave command line to use the browser interface.