aeldidi

I believe this is the syntax highlighter’s repo: https://github.com/github/linguist/blob/master/CONTRIBUTING....

It definitely seems like they do: https://docs.joinmastodon.org/user/posting/

No, you’re definitely right. I’m not sure where the author of this article got the idea that Lebanese citizens are in any way “turning to cryptocurrency”. Most blanket statements about losing faith in banks and whatnot come from a Mark Iskandar, who is a CEO of a cryptocurrency company, the one who set up the bitcoin atms mentioned.

The article briefly mentions power problems, before misleadingly suggesting a solution is to trade bitcoin instead of mining it, because “no machines are involved in the trading process” (false). Later on in the article, the crypto company responsible for the atms says their solution is to rent electricity from other people to mine in exchange for a bit of money, which is heavily downplaying the amount of power needed to make mining profitable.

Unless I’m missing something, this article seems to have a lot of text, but doesn’t actually say much.

I believe it’s supposed to be like a shell variable, which are prefixed with “$”.

For example, my laptop (https://support.hp.com/ph-en/document/c07686423 I think) has a taskbar icon for the touchpad and a taskbar icon for the AMD graphics. Neither of those things are custom parts, just default out of the factory.

I hope this isn’t incorrect, but I recall Drew once saying he didn’t want people to make variations of the language by forking the compiler and changing a page or two of the spec, since that would result in slightly incompatible code.

How do you guys handle using other libraries? Everything I can see uses stuff like std::vector and the like at API boundaries, and I'm not aware of a way to construct an std::vector without throwing an exception.

I mean, the standard way to do IO in C++ involves spamming the left shift operator (<<), I can only assume because it looks like an arrow? This is definitely a shallow thing, but I'd argue that for this single reason operator overloading definitely causes more problems than it solves (in C++), due to things like:

1. translating format strings to other languages is extremely difficult because the position of expressions in the message is fixed.

2. modifying how things are printed requires modifying global state, and it's easy to forget to reset the flags on std::cout after setting the precision of floats or something.

There's also the famous question of "what does the multiplication operator do on vectors?" problem, but that's something that could be solved by simply having a standard "vector" interface that defines it in a particular way. Overall I don't fully disagree, but seeing as it happened once with C++, I can imagine it can happen again in some equally widespread language (Javascript with it's + operator on strings maybe?).

Companies will use whatever is at their disposal to grow faster and more efficiently, this is the free market working as intended (and isn't a bad thing by itself: see free software companies like SourceHut benefiting as well).

I think the core of the problem lies in distribution. We've gotten so used to other people distributing our code for us (through the use of package managers and such) that we've made it hard to actually have a dialogue with our users. Many consumers of packages just know their dependencies by the npm package name, rather than actually seeing what the person has to say about the software, how they plan to maintain it and for how long, etc.

Even things like licenses are really just ignored at large, with there being a general mentality of "it's on Github therefore it's probably MIT". There was something I remember reading a bit ago about a Go project whose license was simply "you do not have permission to use for any reason ever" which was depended on by projects from big organizations such as AWS[0].

This is mostly just a rambling and I don't have any concrete way to solve this, but I think it should be taken into account when assessing whether the problem really lies in the individual license choices of developers, or whether this is some kind of effort by big market actors to keep open source solutions at a subpar level of quality in comparison to commercial offerings (for example: some of Microsoft's VsCode extensions only work on the proprietary version, not any open source forks[1]).

[0]: https://fossa.com/blog/bouk-monkey-importance-knowing-your-d...

[1]: https://github.com/VSCodium/vscodium/issues/240

It's always a pleasure seeing your comments when it comes to language design. I noticed the spec currently says that _Atomic is ignored. Is that a current limitation of the implementation, or is it not planned to ever be implemented? I can see that breaking real C code in surprising ways.

Other than that, I can't wait to use ImportC in my own D projects, I have a couple cases where it would simplify builds dramatically.

I believe it's up to the programmer to implement this. Here's some code from the zig github[1] page that illustrates how it might look once zig is stable (this is from an issue).

  pub fn write(file: *File, bytes: []const u8) usize {
    // Note that this is an if with comptime-known condition.
    if (std.event.loop.instance) |event_loop| {
        // non blocking version
    } else {
        // blocking call
      }
  }

So I guess functions that don't support async could just do something like:

  if (!std.event.loop.instance) @compileError("X function only supports async");

[1]: https://github.com/ziglang/zig/issues/1778

Maybe as a joke they could call it D since that's the letter after C...

I remember reading something particularly negative about terra in 2019[1]. Although I haven’t used terra at all since the time I first tried it (not long after I read the above mentioned article), I think it’s relevant to mention that at least at one point, terra has had major problems regarding design. If anyone has used terra in any non-trivial capacity I’d love to hear what your experience with it has been like.

[1] https://erikmcclure.com/blog/a-rant-on-terra/

Wow that’s really convenient. I was just thinking of how nice it would be to have that feature literally hours ago while working on a side project involving a lot of D/C interop.

Major props to Walter and the rest of the D developers for being so seemingly in tune with what people are looking for in a language.

I agree. Although for most tasks I tend to prefer having a command line interface, just because of things like programmability and my typing speed, I'd be lying to go as far as to say the CLI is _always_ the best way to do something. For example, I like to construct git commits using a GUI, since I'm faster at selecting lines to commit than I am sifting through potentially hundreds of changes looking for the right one to add to a particular commit.

Additionally, I think some of the listed tasks are objectively better in the GUI, despite being possibly slower. For example, in the command line, deleting a file doesn't send it to the "Recycle Bin" or your OS's equivalent, it simply deletes it. This is better for things like scripts, but worse for someone using it as a GUI replacement, since now there's a risk that they could permanently delete an important file due to misspelling or something of the sort. I find it hard to remember sometimes that Emacs is a GUI too, and it can often be the best way to do any given task.

Rather than "Source Code is Worthless", I find it makes more sense to think of the lesson learned here as "Source Code is Only Worth Something to the Public if it's Well Documented and Stable", which happens to be true more often in practice.

For example, someone I used to know would always say that while the Linux kernel as a product (a free and open source operating system) is priceless, the source itself is worthless unless you have an understanding of its internals, and I think that this is generally true for codebases of similar size and complexity, although I'd argue Linux specifically doesn't fall into this area only because of the fact that drivers make up most of the code in it.

Stability is especially important when considering long term worth of code. When youtube-dl was removed from GitHub not too long ago, people were worried that the project would stop being updated and maintained, despite the fact that mirrors of the source code were everywhere. In that case, because the project needs constant updating and maintaining to keep up with websites like YouTube who have no incentive to continue to keep a stable API for downloading videos.