The SAOC submissions are now in and will be evaluated next week, a new dmd beta came out - with __traits(getLocation) which I'm personally a little excited about - and a bug bounty thing is now live. My hot take below.
See more at the announce forum.
The core team set up a new bug bounty system this week and I'm pretty skeptical again. D tried a platform called bountysource some years ago (IIRC 2011ish) and it wasn't very successful. In fact, I think these aren't just unsuccessful, but liable to be counterproductive.
The bounties currently are too small to attract significant work. Most the bugs that get bounties are fairly difficult to fix (though some of the ones here are relatively simple, historically, it is the big ones that get the most attention), yet the dollar amounts do not reflect the time commitment required for professional attention, and as such these amounts are unlikely to change people's behaviors. It is possibly going to attract students, but generally, these bounties are likely going to go to someone who was likely to fix the bug anyway. Especially given the onboarding cost - getting to know the code, getting used to the PR process etc. - gives very little remaining time to actually do the work.
And if they were going to fix it or not fix it anyway based primarily on time constraints rather than money... the bounty might be a nice little bonus, but it isn't actually going to accelerate work and certainly won't change priorities.
If you want people to change priorities, the dollar amount will have to be larger and most importantly, it will need to demonstrate reliability over time so someone can actually plan around it. I think if we aren't looking at basically hiring someone who keeps working on stuff consistently, these bug bounties will never really accomplish much.
Maybe I'm wrong though, we'll see.
Programmers have been trying to figure out how to reuse old code for decades, and I still don't think we've figured it out. A mistake I see a lot is reusing code just because it happens to match now, without concern about that could actually make changing stuff harder.
For example, consider this contrived code:
auto cityTaxRate = 3.0; auto countyTaxRate = cityTaxRate; auto total = sum.applyTaxRate(cityTaxRate + countyTaxRate);
Maybe when you wrote the code, the city and county taxes were the same, so you reused that value... but that rate is subject to change and their match is purely coincidental. This code may be DRY, you didn't repeat yourself on that 3.0 rate, but it misses the point. The point we need to be keeping an eye on is making the code easy to change later when requirements change. (In fact, I'd argue that is the key purpose of software! It is the soft in the word.)
With this code, a change in the city tax could inadvertently effect code handling just county tax. Our effort to not repeat ourself introduced coupling that is liable to bring bugs later.
When you are introducing abstractions, try to think about what it is actually doing - and most importantly, how it is likely to change and what bugs those changes might bring up. If a change should apply in multiple places, sure, reuse the code, but if not, you actually might want to copy/paste to reuse code instead of just calling the function to insulate yourself from those inadvertent changes!
I did a benchmark over the weekend that found std.concurrency.spawn has a decent amount of overhead (above that of core.thread.Thread btw), especially if you call it over and over again. My tip: spawn a thread, then use message passing to reuse the existing worker instead of letting it die and respawning. You'll probably see some memory improvements if nothing else at least.
So I think I am going to take a little break from day jobbing and write the game I've been wanting to write for ages. This will probably mean a little more work on arsd.minigui first, then making the game's map editor (etc.), then finally, making the game! I'll be sure to talk to you all as I progress.
I saw some D propaganda in a local church recently:
Clearly, the gospel of D is spreading! I agree with the sentiment here, learn D for yourself. It isn't actually important how far D spreads - the benefits can be seen by yourself for yourself.