Athas

Compared to Halide:

* Futhark does not expose a scheduling language that gives you precise control over code generation. This is probably the main selling point of Halide.

* Futhark has a much broader focus than Halide, which is mainly oriented towards image processing. Futhark wants to support arbitrary data parallel computation. E.g. see this compiler written in Futhark: https://github.com/Snektron/pareas

Compared to Sycl:

* Futhark is a non-embedded language that is more high level than Sycl. The goals are similar in the sense that both systems to try make (data) parallel programming more accessible. The vision behind Futhark is that the conventional functional programming vocabulary is actually a pretty good fit for parallelism, and that an aggressively optimising compiler can reduce or eliminate the overhead of abstraction. I don't think Sycl is as focused on high levels of abstraction, but rather focuses on being a relatively low-level portable programming interface.

I work on Futhark. We hope that WebGPU-through-Emscripten is viable, but I haven't yet had the spare cycles to make sure. I did find some examples that looked promising.

Does anyone know why the clang that comes with macOS does not support OpenMP, even though upstream clang does? I use OpenMP to teach basic parallel programming, and it is really annoying that the macOS users have to install another compiler to get it working.

(The problem is exacerbated by the ridiculous fact that macOS includes a 'gcc' alias that is not in fact GCC, and which risks shadowing a proper GCC that the students install themselves.)

I thought BSL was a subset of Scheme, so it avoids most of those problems you mention. Or do I misremember?

The downside of building in stuff is that you can't easily replace it. I don't have any VMS experience, but the versioned file systems I've studied are very far from being a replacement for what I would consider version control today. They're more like the automatic writing of backup files in Emacs.

Distributed FS sounds like something with a huge design space. It's better to do that in userspace. Was Plan 9 really the first time virtual file systems could be implemented in userspace? It seems like such an obviously useful idea in retrospect.

My impression is that Arch is not technically unusual among distributions, but is simply well-polished, documented, and very active (and has an easy way to install unvetted community packages). If this impression is correct, you still run the risk of unnoticed outdated software if the amount of volunteers drop, or a particularly critical one no longer has the time.

Which part of Arch's design prevents the issue described in the grandparent post? The issue is "distros lagging behind for years to provide a new package because they can't break all the things depending on the old version", which is solvable either with enough manpower or by sandboxing a la NixOS, where you can keep old versions around indefinitely for the things that need them. Does Arch use such sandboxing now?

Yes, it is very memory unsafe. Subverting the type system often the main source of memory unsafety in most languages. It typically means you can treat an arbitrary integer as a pointer to any other object.

Even plain unsafePerformIO is memory-unsafe, as it will let you construct a polymorphic IORef, through which you can implement unsafeCoerce.

> MacPorts is still alive and well (https://www.macports.org), and in-fact has basically all the same packages brew does.

I used macOS for a few years to try it out, and I found that Macports lacked many things I needed. Taking a quick look again, let's see...

* Oclgrind: No.

* Futhark: No.

* GHC: Yes! And updated to boot. (But I'd expect such major programs to be in any package system.)

* MLkit: No.

* hledger: Yes, although not the newest version.

* git-annex: Yes, but a rather old version.

* ispc: Yes, but again a rather old version.

The impression I got (which may be inaccurate) is that Macports has a long tail of older packages, but it does not have a lot of newer stuff. It is very easy and convenient to add packages to Homebrew (just a PR with a package definition in a Ruby DSL; most things are obvious), which I think is the main reason it has become successful.

Nowadays I suggest everyone just use Nix, of course. It's not as slick and has a tough barrier to entry, but it's built on fundamentally better principles than legacy package managers.

> It is: using Flakes you're thrusted into a more pure evaluation mode by default, and it creates a (standard) artifact of the revision you're on: the flake.lock.

Can you name a specific example of the kind of nondeterminism/nonreproducibility I risk by simply pinning Nixpkgs itself (or to be more principled, using Niv)?

> But pinning Nixpkgs alone does get you much of the way there (and for many use cases— those where the only referent on it is 'nixpkgs' or 'nixos'— does make NIX_PATH redundant anyway).

What is missing compared to using flakes? The only `NIX_PATH` components I normally use is `nixpkgs` which hooks into the whole channel system (which is bad), but by settings my `pkgs` variable to a specific commit/tarball, I can ignore `NIX_PATH` entirely, right?

Is this more deterministic than pointing Nixpkgs at a specific commit/tarball in the configuration? I have often done this to make reproducible builds in other Nix settings and it has worked well.

Don't those still give you a terrible error message if you use them in a default config?

No, the problem is that the platforms involved do not support any 16-bit float type in an ergonomic way. (The most accessible type on all the platforms, and the one used, is ultimately IEEE 754 binary16.)

You always had to tell Futhark about the CUDA include directory at compile-time. The difference is that now you also have to tell it about it at run-time.

Further, at compile-time the usual CPATH/LIBRARY_PATH environment variables are respected, which I think is not the case for the run-time NVRTC compiler.

Paredit is so good that even after taking a break from Lisp for years, as soon as I opened up an .el file to do some Emacs customisation, the muscle memory was fully intact and I was able to perform structural edits without even thinking about which keys I pressed. I try not to write too much Lisp these days, because I inevitably become depressed at how clumsy it is to manipulate syntax in the languages I use more commonly.

Also by Wirth: https://en.wikipedia.org/wiki/Euler_(programming_language)

Consider the documentation for the similar compiler flag in the OpenCL specification:

> -cl-unsafe-math-optimizations

> Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid, (b) may violate IEEE 754 standard and (c) may violate the OpenCL numerical compliance requirements as defined in section 7.4 for single-precision floating-point, section 9.3.9 for double-precision floating-point, and edge case behavior in section 7.5. This option includes the -cl-no-signed-zeros and -cl-mad-enable options.

While it stops short of saying "this will likely break your code" (maybe because it doesn't have the nonlocal effects of -ffast-math), it makes it much more clear that this flag is generally unsafe and fragile, except under rather specific circumstances. Also, it is reasonably exact about what those circumstances are. I'm not sure -ffast-math is documented with enough precision for a programmer to even know whether it will break their code. Best you can do is try and see if the program still works.

I never understood the motivation for allowing tuples without surrounding parens. There are a few very simple functions that look cuter this way, but it constantly trips me up in more complex situations.

Modern journals don't actually print all that much, and I'd expect the marginal cost of publishing additional papers to be very low.

I wonder if this culture arises out of necessity. Many conferences claim to not have a set quota of papers they accept, but in practice there is a limitation to how many presentations can be accommodated given the physical and temporal limitations of the venue. The quota may grow slightly over time, either by shrinking the time allotted to every presentation (ICFP is really squeezing it these years, for example) or adding parallel tracks, but there are ultimately fairly hard physical restrictions. This inevitably limits how many submissions can be accepted, which also creates an otherwise unnecessary air of competition, even between otherwise unrelated papers.

Journals don't have this restriction; you can always put out more volumes. I suppose I enjoy conferences as much as any CS practitioner, but it does not strike me as a sustainable or scalable publication method.

> still how do you give the user the option to say "I know what I'm doing."

You make configuration available. Most of these disabled-by-default protocols can be enabled by a user who really knows what they are doing (and isn't just saying so). A few might have been outright removed from the code base. In that case, you really need to know what you are doing, but you can still bring them back by installing a custom patch or downgrading the program in question.

I think it is a good idea to create friction along pathways that are probably mistakes. The people who really need to go down that path will put in whatever effort is necessary, while people who are motivated by the path of least resistance will be nudged in a safe direction.

If something is broken in the default installation, you'll notice quickly during acceptance testing and can go and fix it (for example by re-enabling insecure protocols).

If something is unexpectedly insecure, you will probably not notice until it's too late.

I think the admittedly annoying security people are right in this instance.

> 1. Wasn't clear on environment/toolchain and ended up compiling for a long time just to install one package. Pretty sure I was doing it the wrong way but saw inconsistent information about what to do. I'm almost sure this is fixed by now, or at least enough for me to stop complaining about it.

This can still happen. Unless you use Nix (don't do this unless you already like Nix), there is no distribution of precompiled Haskell packages. Some "framework"-like packages recommended to beginners may depend on a huge number of other packages.

> 2. The runtime seemed more annoying than I'm accustomed to. I remember trying to load some haskell code into another program, and it was modifying the signal handlers, which was totally unacceptable for my use case so I gave up. This is an area rust is much better.

It is still annoying. Haskell will definitely hijack your signal handlers. It needs them to handle timers, to handle garbage collection, and maybe do other things in the concurrent IO system. I'm not aware of any work to make it collaborate with other signal handling shenanigans, but I haven't looked. I doubt it is possible; Unix signal handlers really are not a good foundation for modular design.

> 3. It was difficult to use ghci-like functionality from another program (compile bits of haskell code). Maybe it's more library-like now and I can just use ghci now? Neither rust nor haskell is great here.

This is most likely easier. GHC has become much more friendly to library use.

Yes, the next Haskell will be strict; that's generally although not universally accepted.

I have however noticed that while much Haskell code doesn't make very fancy use of laziness, it is widely used for very local control flow. E.g. a pattern I see relatively often is `fromMaybe (error "...some message")`, which would be problematic in a strict language (because `error` would always be evaluated).

Even without partial functions, laziness can also simplify code structure when you can just 'let' bind any value that will possibly be used on any control flow path, without worrying about unnecessary computation.

These conveniences are not deal-breakers - I get by without them just fine in SML - but they do serve to make the language a bit nicer.

I am aware. My post was about Rust not originally being intended for much of the non-concurrent and performance-agnostic application programming it is currently being used for (e.g. the enormous amount of CLI utilities cropping up). Its popularity in this domain is due to qualities that were not part of (or at least orthogonal to) the original vision.

Yes, Rust as a language wasn't originally intended for much of what it's used for now. Many of the applications written in Rust would probably be fine without the borrow checker, and instead paying a performance overhead to have GC. I think Rust is succeeding on the strength of its tooling and the overall relative modernity of the language (e.g. proper sum types and sane metaprogramming). Of course, Haskell has these things too, although some of the incarnations may be a bit more crufty (Rust macros seem a lot more accepted than Template Haskell does).

As a language, I think it was always good. Haskell is my main working language, so I tend to mostly see the warts, but whenever I have to use another language I end up feeling very constricted. Haskell does have some very real warts, but I would say that for example the current state of the tooling is only bad when compared to the very best (e.g. cargo is arguably better than cabal, but cabal is better than what a lot of other languages have).

I'm uncertain about Haskell ever becoming very popular. Rust seems to be sucking a lot of oxygen out of the room for new application programming languages, and Haskell is so old that I'd expect it to already be popular if it were ever going to become popular on its own merits. This doesn't matter much to me. There is enough manpower in the community to maintain the tooling and infrastructure, which keeps improving, and the language is fundamentally very very good.

I originally learned Haskell from the book Real World Haskell. It's probably dated now (the language and libraries have changed), but I would certainly welcome an updated second edition.

I need to use printf to interpret the escape character:

    while true; do printf "  $(date)\r"; sleep 1; done

> I'm not convinced it's "serious" --- thread-local-storage easily solves that.

What about other cases of exceptional control flow? What happens if a signal arrives while that static area is being used, and the signal handler also needs to use the static area?