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?).
> 2. modifying how things are printed requires modifying global state
This only applies to std:: cout and std::cerr. Other stream interfaces, like std::fstream or std::stringstream don't have this problem. Also, it is orthogonal to operator overloading.
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]).
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.
_Atomic is a problem because it doesn't map onto any existing D semantics. D's `shared` is distinctly different. So I decided to move it down on the list of priorities, instead focusing on what I can get done in the shortest time.
I'll eventually circle around to it, or someone may beat me to it. It is open source, after all!
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");
Thanks, but how is a waiter suspended? The typical await implementation will do a CPS conversion of the waiter function, but to trigger the conversion it needs to see an await call, or pessimistically generate two versions of each functions.
But from your example it seems that Zig just do context switching (not knocking it, I'm a big fan of it over await), but then why would it need an await/async keyword at all?
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.
I develop Regent, a programming language for distributed computing based on Terra [1]. We're one of the larger (largest?) Terra codebases and indirect source of users.
(I also help maintain Terra, but this answer is more focused on my capacity as a user.)
Terra is a workhorse and it gets the job done. Overall, compared to a previous iteration of Regent (that was built entirely from the ground up in Python), it's been a good experience. Having first-class code generation capabilities has been really nice, especially with built-in support for things like parsing C header files, vectorization, and CUDA code generation. The language is stable and generally doesn't have many surprises. Unlike, say, C++ or Rust, there aren't as any corners to hide odd behaviors. (Obviously, there still is some room for such things, as you can see in the sibling comments. But I still think it's better than most languages.)
The main issue is, as siblings have noted, the size of the community. While most stuff works, if you find something broken you're likely going to have to fix it yourself. This is an area where we're always looking to grow.
Please note: The entire "windows" portion of that article has largely been resolved at this point, because I fixed it myself. Some of the more egregious documentation problems have been fixed, but others remain unresolved.
Thanks for pointing that issue out! I had a fun time figuring out the codegen algorithm by putting printf statements in every function I thought was relevant.
I presume that's after the works of h. p. lovecraft, who created an association between non euclidean geometry and horrific nightmare realms and beings.
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.
