maelkum's comments

I can't recommend Sourcehut enough!

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 think the Shadowrun adage is applicable here: "Watch your back, shoot straight, and never, ever, cut a deal with a dragon."

Microsoft is the dragon here. Even if it appears friendly you still don't cut a deal with it, or you become a pawn in its game.

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

Probably the latter. The "deadbeef" string as a "random" hexadecimal example is pretty common.

In a true hackerish style, I rolled my own solution: https://github.com/marekjm/issue

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.

/end of shameless plug

You mean "The most resilient torrent website in the Galaxy"? The TPB crew was ahead of the times.

> Where Viua stands in terms of performance for both generated code speed and compilation speed?

The performance is, frankly, abysmal. At this time you shouldn't use Viua if what you need is execution speed, as I haven't spent much time optimising the VM. Compilation speed is a different matter. I only provide an assembler so the "compilation" process is simple and straightforward, and shouldn't take long. Separate compilation is available, although a bit awkward, which should help.

The assembler supplied with Viua does not perform any optimisations on source code.

I don't use any library for register allocation. The bytecode is not compiled to native code so I can just supply whatever number of register a function needs.

I haven't planned building a JIT compiler for the code, but I thought about it. Don't expect it any time soon as I don't have the chops to do it right ;-)

The long term plans and goals... Ah, these deserve a separate post.

The shortest possible summary: I do not plan to take the part in speed arms race; what I want for the VM is to provide best-in-class correctness and reliability. That wasn't always the case (and it shows if you know where to look), but now every feature and change is evaluated in the light of "How can X help with writing correct programs?". The same for VM's source code. I compiles warning-free, it doesn't leak memory. It does not contain UB. I am not able to provide you with the greatest performance out there, but I can give some correctness guarantees - this is where I focus with the development of the VM.

Hi, Viua VM's developer here.

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.

Hi, Viua VM's developer here.

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.

Viua VM's developer here.

That's sort of the point of the VM. Maybe not to become the new Erlang, but to become the new BEAM.

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

A piece of trivia: why name it "Viua"? "Viua" is pronounced a bit like "wiła" in Polish. Wiła is a female daemon in Slavic mythology https://en.wikipedia.org/wiki/Supernatural_beings_in_Slavic_...

If you have any other questions, just ask!

Hello everyone, the Viua VM's developer here! If you have any questions, just ask, I will try to answer them.

Mind you, I am not the one who posted the VM here. I was specifically trying to maintain a low profile (and giving only a few presentations about it) until I polished the VM to some acceptable state. But here we are, so just ask me anything ;-)

Well, yes. He can't.

I assume you already know why but, in case you don't, let me put it in simple terms for you: it's easier to create something from scratch than to extend existing code base.

Have you every tried to fix a bug in or make an improvement to GCC? I did; I tried many times and I failed. Maybe it's just that I am not hacker enough (I'd say it's exactly the reason), but... The size of the code is enormous, the documentation scarce and of limited use to new people - sort of like with man(1) pages: if you already know what you're looking for they're great, but if you don't and need real help then I'm sorry, but tough luck. You'd better know where to look for parser, optimiser, code generator, etc. and how they interact with each other; where to get information about source code you're translating (keep in mind that there are "new" and "old" ways, and for some constructs only one is available). Unless you have tons of time on your hands (don't have to work, or are lucky enough to go to a University which has some people working on the code), or work for one of the companies developing GCC then you have pretty slim chances of actually getting through.

I don't know how it is with LLVM/Clang. Maybe there it's easier to contribute.

But HELL YES it's easier for a lone developer to "(...) create a whole new language, complete with a module system, a proof system, a constraint system, a parser/lexer (...)" and it is ridiculously hard to "(...) extend C by adding new flags to the compiler that are optional and don't necessarily break anything from old code and lets you selectively upgrade your sources.".

I know this from experience as well as, I'm sure, many others. I am building a parallel VM: I designed its instruction set, built a compiler and static analyser for it, went with it to a conference, etc. etc. It's not that hard and I bet you could do it too. But to take an existing language (read it as "an existing compiler") and "add new stuff without breaking anything" or just "add new stuff"? Man, that's orders of magnitude more difficult.

There's also the satisfaction factor at work: when working on new project you get instant gratification - "Test pass!", "New feature!", "A bug fixed!", and "I get to implement this cool idea I had and nobody's gonna stop me!". When you work on an existing project (especially one as big as GCC or Clang) you have to brace yourself for several hours of reading the code before you can begin to think about where to start. If you did read the code and tinker with it every day then it will get easier, but you have to have the will power to burn through all that code, and not everyone does.

Just my $0.02.

> The Wallaroo license seems to be non-free, which I think is very unfortunate and a misses an opportunity to be more widely used: (...)

Maybe. But then, if they require you to buy a license when you're using it to make money yourself (and don't try tell me that you can afford to run your hobby project on more than 24 CPUs but can't throw some money on the devs of your tools) then it is no longer "unfortunate" - it's just business. And don't forget that programmers need to eat too. "Widely used" does not directly translate to "making tons of money".

Bonus points to them for doing it from the beginning, instead of changing the licensing mode mid-flight.

You know... there's a difference between "(...) with people on ARM, Google, Apple, Blommberg, Sony, IBM, Microsoft's payroll?" and "people on Google payroll". In one case you have many companies cooperating, in the other - just one company.

This is a useful comment. The suggestion to go with an interpreter first if you want to have something in a relatively short amount of time is a good one.

> When i'm debugging/developing/whatevering code that is going to run the same in all supported browsers, (...).

Completely off-topic remark: I always find it funny that Web is hailed as the Write Once, Run Everywhere there is a browser, but then words "supported", or "compatible" start cropping up.

Maybe... but not everything can be cancelled.

What if you are too late and, say, asynchronous write to a disk was already commited and the data is out of your program and on the drive?

And how do you cancel a sent email?

At some point there is no sense in sending a "cancel" message, or there is no way of cancelling an action. How would you proceed in such a situation?

Well, given sufficiently good libraries everything can be written in 10 lines of C.