I hope we can have something that combines the meta-programming capabilities of Zig with the vast ecosystem, community and safety of Rust.
Looking at the language design, I really prefer Zig to Rust, but as an incompetent, amateur programmer, I couldn't write anything in Zig that's actually useful (or reliable), at least for now.
I Agree. I tried briefly Zig and quickly gave up because, as someone used to Rust, the compiler wasn't helping me find those issues at compile time. I know that Zig doesn't make those promises, but for me, it's a deal breaker, so I suppose Zig isn't the language for me.
On the other hand, I do like the concept of comptime vs Rust macros.
"the community" meaning one weirdo commenter you've seen on HN? Cause I can assure you no people I know in the Rust community think that way.
Personally I would really like to code some stuff in Zig if I had more time. It's not really appealing to me in many ways (like I prefer to spend a bit more on designing types for my programs and have safety guartantees), so I wouldn't probably ue it long term, but I admit stuff like comptime is interesting.
The Rust Discord is one of my favourite places on the internet. I've met so many helpful, friendly, interesting and incredibly smart people here. And this is coming from someone who's had a lot of frustrations on my rust journey, and who does evil things like use small unsafe blocks instead of bringing in dependencies - they even refused to ban me for this!
There are definitely a few loud, unpleasant voices in the rust community. But quite frankly the Rust discord was a lot more pleasant than the Zig one.
YMMV, I do have a fondness for Zig, and I honestly did find Loris's "safety coomer" comment really funny. But I've had such good experiences with rustaceans that I feel I must defend their honour every time it's besmirched like this.
I don't think the author intends to provide a serious production solution, at least not for now.
Runit tools in busybox - up to the task?
Let's test busybox's runit applets in a hypothetical ;) scenario
when someone needs to stop running, say, systemd on, say, a Fedora machine.
No doubt this will expose various shortcomings.
To me, This just seems like a fun experiment to demonstrate busybox's capabilities.
> (abstract) ... However, a persistent difference, called the Hubble Tension, is seen between the value of the constant measured with a wide range of independent distance indicators and its value predicted from the afterglow of the Big Bang. The NASA/ESA/CSA James Webb Space Telescope has confirmed that the Hubble Space Telescope’s keen eye was _right all along_ (emphasis mine), erasing any lingering doubt about Hubble’s measurements.
This feels like bad reporting to me. A better title would be "Webb confirms Hubble's measurement of Universe’s expansion rate", but that would probably be less exciting...
Hey! Thank you for this cool editor! However, has it been written with cross-platform support in mind? Otherwise, porting from mac to linux could be rather painful and time-consuming... Will there be an ETA for us linux users? I saw it on the roadmap [0] but without an ETA.
Wolfram would like to say that he invented Mathematica all by himself, but in its core, it is basically a lisp: everything is an expression, and mathematics are just transformations of the expressions. Afaik this makes it the best tool (conceptually and practically) for generic symbolic manipulations. For example, `1 + 1` in Mathematica is just syntactic sugar for `Plus[1, 1]`, and `a = 1` is `Set[a, 1]`.
I am a PhD student in theoretical physics and almost everyone in our field has no choice but to use it (I do know one or two people that use maple, but the overwhelming majority chooses mathematica).
Despite its elegant design, many people hate it with a passion, as it has grown to be a huge bloated mess that takes forever to run. Also, due to the closed source nature, it is very hard to debug when something goes wrong. For example, it is quite often for the basic functions like `Simplify` and `Integrate` to get stuck running forever, but there is no way to keep track of the internal transformations that mathematica is doing, since everything is sealed up.
Re "it is a lisp" and "everything is an expression", I would like to add a bit of clarification.Or, given that you use Mathematica regularly while I was just reading surface docs (for purposes of doing some stuff with Wolfram Alpha), rather a question if my perspective is well-founded.
Based on my understanding of how expression evaluation works, the slightly more revealing statements would be "it is a lot of lisp macros" and "everything is an s-expression". Which means, a big mess. Let me expand:
As a functional programmer, "everything is an expression" sounds comforting, and I would expect there are clear transformation rules on how expressions are evaluated (and, maaybe, type signatures).
Instead, what you get is, "you can throw in some random form of expressions into this function, and it will do something with them". As in, it takes an AST input, and transforms them in some loosely specified way. There doesn't seem to be a type system, so you don't have types to guide you, rather you likely need to figure what kind of expressions work with which functions.
Now, if I'm wrong about this, and the functions behave consistently in what they take and how they transform it, then I'm more than open to be corrected. It is just that my high expectations (based on marketing of the lang) and the subsequent realization left me a bit bitter.
It's really, really difficult to come up with a type system for mathematics. Let's just talk about Plus, the symbol for using the plus sign. What's its type? You might say it takes a few numbers and returns a new number. But what kind of number does it return? It is capable of returning machine precision numbers or their custom high precision numbers. It can return integers, rational numbers, real numbers or complex numbers, as the case may be. It is capable of working on lists of numbers and matrices of numbers, and it returns lists of numbers or matrices of numbers. But wait Mathematica doesn't require a list's elements' types to be homogeneous, so it can return different types of numbers for each element of the returned list. It is capable of working on completely undefined symbols, much like in real mathematics you expect a teenager to be able to reason about the expression `x+x+x` and simplify it to `3x` without knowing what `x` might be. It could very well leave everything the same, for example when you add two undefined symbols `x+y` and get back `x+y`.
So I personally think it is perhaps not productive to think about type systems and type signatures when working with Mathematica. But you can definitively think in terms of transformation rules. And Mathematica either documents these rules or makes these rules intuitive.
It is possible to put filters on function arguments, e.g., the definition
f[x_Integer] := ...
will define a rule for f[] that only matches expressions where the argument to f[] has the head "Integer". It is even possible to use arbitrary predicates:
This lets you sort-of have type-checking. This is entirely opt-in, so you have to be somewhat rigorous about its use or it does not do any good. Also, in practice if any invocation of f[] does not have arguments which match the types for which you have defined it, the expression just remains unevaluated, which can create a mess (but maybe less of a mess than evaluating the function on input of the wrong form). The performance impact (particularly of the predicate version) is also non-zero, but my experience is that the biggest performance limitations come from trying to keep your machine from grinding to a halt when a runaway expression applied to the wrong thing explodes in complexity and eats all of your RAM... and this helps avoid that.
While I have found this to be very helpful for writing and debugging hairy expressions, I used Mathematica for years before I even knew this was a thing. In reality almost no one does this, certainly not with any consistency, and the situation is as bad as you fear it would be.
Lisp-style macros are actually difficult to write because of the infinite evaluation of the language. I was able to write a quasiquote package for myself to help with that that though.
These are all valid criticisms. There is no type system, although some safeguards can be implemented through pattern matching and conditions (see the answer by @derf_ above). For quick and dirty transforms on symbolic math expressions, these are often good enough, but it is indeed a mess to use as a full fledge programming language.
I do like that the lispy language itself closely mirrors math expressions, and it is consistently accessible throughout the user interface. For example, the mathematica notebook frontend (IDE) is simply some `MakeBoxes[]` of the expressions, which are all valid mathematica code themselves. I tried sympy a while ago, which I believe took an object-oriented approach, and it was very clumsy when compared to mathematica.
Still, I would not recommend using mathematica for general programming, precisely because of the mentioned shortcomings. By default, it is also impure and not lazy (eager eval, although it can be forced to be lazy on a case by case basis using `Hold` or `Unevaluated`).
> I am a PhD student in theoretical physics and almost everyone in our field has no choice but to use it
I got my theoretical physics Ph.D. in 1987. I’ve never met anyone who uses Mathematica, except to try it out a bit out of curiosity. Perhaps you’re referring to a particular research group?
Ah, to be more precise, I work in high energy theory (hep-th): https://arxiv.org/archive/hep-th. I shouldn't have spoken for theoretical physics in general, but in hep-th, mathematica is basically a requirement (nowadays, can't say for 1987). I believe the same applies to high energy phenomenology (hep-ph) in which some fundamental packages (e.g. feyncalc) are written in mathematica.
Looking at the language design, I really prefer Zig to Rust, but as an incompetent, amateur programmer, I couldn't write anything in Zig that's actually useful (or reliable), at least for now.