Julia is another contender. Julia code can be as performant as C++ code, but Julia code may be even more elegant than C++. Even without accounting for Julia's metaprogramming features, the compile-time expressiveness is top-notch.
It shares some of the same drawbacks as C++, though. The language is extremely powerful, so while it is easy to write performant code, it is also easy for non experts to write very suboptimal code.
> Number isn’t an interface—there are no operations common to all numbers.
When creating a new type, it should be more clear cut when is subtyping Number (or Real, etc.) valid. Should unitful quantities be numbers? Should intervals be numbers? Related: I think there are some attempts by Tim Holy and others to create/document "thick numbers".
Furthermore, I believe it might be good to align the Number type hierarchy with math/abstract algebra as much as possible without breaking backwards compatibility, which might making Number, or some subtypes of it, actual interfaces.
> Subtyping Number is a way to opt into numeric promotion and a few other useful generic behaviors. That’s it.
I don't think testing against every existing dependent would make sense currently. The issue is the lack of tooling for mechanically checking whether the dependent accesses implementation details of the dependency, in which case it would be valid for the dependency to break the dependent.
There are some proposals to forbid the registration of a package release which trespasses on the internals of another package, though.
I hope someone tackles the above sooner or later, but another issue is the approach of testing every known dependent package might be very costly, both in terms of compute and manual labor, the latter because someone would have to do the work of maintaining a blacklist for packages with flaky unit tests. The good news is that this work might considerably overlap with the already existing PkgEval infrastructure. We'll see.
What I wanted to say is that I'm skeptical regarding "interfaces", either as a language feature or as a package. Although TBH I have not yet given any specific "interfaces" design more than a cursory glance, so my position is not really justified.
> the culture of not prioritizing correctness in computation
On the contrary, it is my impression the experienced Julia programmers, including those involved in JuliaLang/julia, take correctness seriously. More so than in many other PL communities.
> there are people working on traits/interfaces - but these are still peripheral projects and not part of the core mission to my knowledge
What exactly do you mean by "traits" or "interfaces"? Why do you think these "traits" would help with the issues that bug you?
The Julia world is already quite careful with testing and CI. Apart from the usual unit testing, many packages do employ integration testing. The Julia project itself (compiler, etc) is tested against the package ecosystem quite often (regularly and for select pull requests).
Julia is not without warts, but this blog post is kinda rubbish. The post claims vague but scary "correctness issues", trying to support this with a collection of unrelated issue tickets from all across Julia and the Julia package ecosystem. Not all of which were even bugs in the first place, and many of which have long been resolved.
The fact that bugs happen in software should not surprise anyone. Even software of critical importance, such as GCC or LLVM, whose correctness is relied upon by the implementations of many programming languages (including C, C++ and Julia itself), are buggy.
Instead the post could have focused more on actual design issues, such as some of the Base interfaces being underspecified:
> the nature of many common implicit interfaces has not been made precise (for example, there is no agreement in the Julia community on what a number is)
The underspecified nature of Number (or Real, or IO) is an issue, albeit not related with the rest of the blog post. It does not excuse the scaremongering in the blog post, however.
I agree those features are essential for an Xorg replacement, but you're missing the fact that the Wayland designers excluded them intentionally, so Wayland is intrinsically hostile to the features and the power-users that use them. See my comment at the top level of this thread.
> Just because Red Hat is moving resources away it doesn't really mean it is sabotaging the project
I think you may have misunderstood the commenter you replied to: they were probably referring to the careless breaking of backwards compatibility that was being done while Xorg was still nominally being maintained. I think a good example is refactoring the Server while silently breaking extensions they don't care about.
The trouble here for those who use Unix-likes as graphical programming environments is that Wayland is the intended replacement for Xorg, and the quoted statement comes from the perspective of making products for non-technical end-users instead of something power-users (like many of us here) can use efficiently. I will not claim here that it is theoretically impossible for efficient graphical programming environments to be based on a Wayland compositor, but the facts are firstly that currently Wayland based systems are a downgrade compared to Xorg (I think the Wlroots/Sway is currently the only compositor that tries to cater to power users, and the issue with Wayland is also that support from the compositor is necessary and difficult for almost any feature), and secondly that the Wayland design is hostile to features that power users are already accustomed to from X Windows. More broadly, Wayland is actually hostile to features like screenshots that all users of other operating systems are accustomed to, meaning that Wayland is actually causing an unnecessarily ugly image of Linux systems among users of other systems. Causally related to the above is the fact that the Wayland design necessitates great duplication of effort for both compositor implementations and applications that want to be able to use more than one incompatible compositor.
Three days ago there was a discussion here on basically the same topic, and because my comment there[1] is completely relevant, I'm going to mostly just copy it here:
A too common complaint about Wayland (or Wayland compositors, more specifically) is that it is taking a long time to catch up to X11. The elephant in the room is that this situation stems from a deeper issue: Wayland has a horrible design, for an X11 replacement, a design that leads to massive fragmentation issues across the graphical part of the Linux ecosystem. Implementing a Wayland compositor requires much more effort than implementing an X11 window manager and each new compositor implementation reinvents the wheel many times, leaving users with less options for a desktop environment than on X11. Even worse, Wayland does not standardize on or is hostile to some essential features, meaning that users need to rely on compositor specific behavior for those features, if they are even available. E.g., an application that needs to grab the entire screen will need separate code for each compositor it supports screenshots on, or it must use a protocol outside Wayland to get the screenshot. Quoting Red Hat:
> Furthermore, there isn’t a standard API for getting screen shots from Wayland. It’s dependent on what compositor (window manager/shell) the user is running, and if they implemented a proprietary API to do so.
An xdotool (an input event automation tool, imagine wanting to inject or intercept input events) replacement is not possible on Wayland (without having separate support for each compositor, of course). These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile), this[0] Reddit comment puts it nicely:
> It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones. But for some reason we absolutely need this technology on the desktop, like we had not enough pain and lose ends over here without it.
But the lack of these features AFAIK also causes big trouble for users with special accessibility needs. Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games.
This looks great, but while one is playing with it (or, alternatively, while one has classes on electronics), it may be good to know that you do not need your browser to simulate electr(on)ic circuits: try ngspice (should be available on all operating systems where one could expect such software; Unices, Windows, Mac): it is an implementation of the SPICE simulator, but with many modifications, including scripting support (it has its own language built-in, or one can use tcl or C to control ngspice). The main difference while getting started is that one does not lay out schematics while working with nspice, rather one just describes the circuits as graphs where the edges are electronic components. It is more abstract in that sense, but I think it is closer to programmers in these ways, and it provides more power to the (programming) user. (Note that one would probably draw the graphs on paper before describing them for SPICE/ngspice.)
Side question: I would like to get to being able to design PCBs which I could then get produced and populated in very small quantities, just as a hobby. What are the fields of knowledge which one should approach before designing PCBs oneself? Any good books? After that, I would need to choose between gEDA and KiCAD, while the latter seems to be quite a bit more popular, gEDA's supposed design in the UNIX philosophy (as a suite of tools that the user uses through programming/scripting) appeals to me, so does somebody have any experience with gEDA to share (pros, cons, etc.)?
Another question, more on-topic: could somebody clarify in what cases can we simulate electronic circuits while representing values with phasors/complex numbers? As far as I understand there are some limitations, like it is always a correct identification if all components are linear, or if the AC parts of the signals have "small" values compared to the DC parts of the signals. Am I mixing stuff up? What are some of the real world situations in which simulating with phasors breaks down?
It shares some of the same drawbacks as C++, though. The language is extremely powerful, so while it is easy to write performant code, it is also easy for non experts to write very suboptimal code.