Munksgaard

Utilitarianism is not the only moral framework.

> Is Truth Social basically paying Trump's ongoing legal costs?

Would that surprise anyone, Truth users included?

> When you refactor, make a change, or try to add new functionality, and end up fighting the type checker. That's friction to change you are experiencing and that experience is optional.

I'm not sure exactly what you're saying. If your language is strongly typed, you'll get type errors no matter what. The only difference is whether the type errors happen at compile time or run time. Let's take a hypothetical example:

Let's say I have a programming language called Foo. There are two ways to run programs written in Foo, using the interpreters A and B. A and B are identical, except for that fact that on startup, A will check that the given program is well-typed (static type checking), while B defers such checks to runtime (dynamic type checking).

Given a well-typed program X, I can run X with A or B without ever encountering a type error. Now, I make some changes, like you suggest, and I attempt to run it again. If the resulting code is not well-typed, I will immediately know when trying to run it with A, but with B I have to be lucky enough to hit the specific case that isn't well-typed.

If I understand you correctly, you're saying that you can easily make changes in a dynamic language without _ever_ causing run-time type errors. If that's the case, you would have _exactly_ the same experience whether you ran your code using A or B.

Yes. The Basis library does not live up to today's standards. Which is of course no surprise, given that it hasn't changed since the 90s.

The notable thing here is of course the new HIP backend for Futhark, which turned out to be surprisingly easy to implement and resulted in significant performance improvements in AMD GPU execution, specifically when performing scans.

> but it’s simply not rude to suggest reading docs would bring clarity

It's pretty rude to assume/insinuate that I haven't read the documentation just because you misunderstood my initial concern.

Your point is rendered moot by the fact that `in` is allowed in guards. See my other response as well.

> Because it is not meant to be a guard—it cannot further empower a function head and pattern match and be optimized and/or inlined by the compiler. Simple as that.

First of all, that's not an explanation, that is handwaving. The real explanation is that URI.char_reserved? could be rewritten using defguard, because it only uses `in`[0]. An arbitrary choice (whether conscious or unconscious) was taken, that this particular standard library function is not allowed to be used in guards. But there is no good reason for it.

Secondly, are you claiming that it is not useful to be able to use URI.char_reserved?/1 in a guard? That's obviously bullshit.

Finally: The real reason why some things can be used in guards and other can't, is that Elixir must be able to guarantee that no side-effects happen while evaluating a guard[1]. This is a good reason (a good follow-up question is, "why must guards be side-effect free?") and something you can use to form a mental model of which functions you can use in guards and which you cannot, but it is not described anywhere in the Elixir documentation. It's not an easy thing to form a mental model around, but it can be done.

To be fair, I think this is a shortcoming in Erlang as well. It would be better to be able to look at the type of a function and be able to tell whether I can use it in a guard or not. Or just allow all functions to be used in guards, such as in Haskell.

0: https://gist.github.com/Munksgaard/ccac61310651d3402571506e4...

1: https://www.erlang.org/docs/22/reference_manual/expressions#...

Then explain to me, purely by referencing the Elixir documentation, why URI.char_reserved?/1 is not instead called URI.is_char_reserved/1 such that I can use it in a guard.

There's nothing intuitive about memorizing dozens of built-in functions that are (for opaque reasons) different from all the other built-in functions.

There's no need to be rude. My point is that it is not obvious, given some arbitrary value and some property to test for, whether that property can be expressed using a guard or not.

Sure thing. My point is that, if I want to check whether an argument is a keyword list, I have to do extra mental work to guess whether the correct function to use is `is_keyword` or `keyword?`. There also doesn't seem to be a consistent rule I can apply to figure out whether it's one or the other. Conversely, I also get tripped up every time I want to add a guard to a function like, "is the thing I want to test written as a macro or not?".

I understand the reasoning for the distinction and its roots in Erlang, it's just not very elegant to work with.

While true, I think the larger problem is that it is not intuitive (at least to me) when I can expect a function to be of the `is_` vs `?` form. It's a leaky abstraction.

Cliff! I've had a plan to buy a bottle from you for a long time. Do you still have any left?

In Elixir that is a called a comprehension, just like the blog post is discussing.

There is no on-going work to support Metal apart from the work done by Miles. There's an old issue about it: https://github.com/diku-dk/futhark/issues/853#issuecomment-5...

We actually have a long-standing issue regarding WebGPU[0]. Long story short, we want to support it, and Athas did some exploratory work a couple of years ago and decided that WebGPU wasn't mature enough yet. We already have a WebAssembly backend, so as soon as it is possible to access WebGPU from WebAssembly it should be relatively straightforward.

[0]: https://github.com/diku-dk/futhark/issues/1403

Great to hear that you liked the language!

Regarding the performance, I'd be interested to hear more about your experiences. Because we compile to CUDA or OpenCL in the end, we cannot claim to be faster than what you could (in principle) write in hand. However, most of our benchmarks compare favorably with handwritten reference implementations, and the heavily optimizing compiler is able to write code that is tough to write by hand.

However, we're always looking for instances where we can do better. The goal is to be comparable to CUDA/OpenCL in as many cases as possible.

Shameless plug for Futhark[0], which you can use to write your computational kernels. The idea is to use functional constructs like map and reduce to express parallel code and let the compiler handle the generation of low-level OpenCL or CUDA.

Disclaimer: I've recently finished a PhD focused on memory optimizations in Futhark.

[0]: https://futhark-lang.org/

Edit: They do actually mention stuff like Julia and NumPy.

Shameless plug, but after reading this blog post the last time it was posted, I tried to implement some of the same dithering methods in Futhark[0]. You can see the results here, if you're interested: https://munksgaard.github.io/bluenoise/

By the way, that is a literate Futhark program, so the markdown is generated from the source file found here: https://github.com/Munksgaard/bluenoise/blob/master/bluenois...

[0]: https://futhark-lang.org/

Really appreciate this response.

Looking at your first link, there's a link to this page which currently resolves to a 404: https://supabase.com/docs/guides/platform/docs/guides/platfo...

Thank you! Yeah, at some point it would be nice to do a little library of sound effects, and there we should definitely have some filters like that.

To be clear, we're not doing anything in the browser (yet). Futhark literate takes a .fut file and generates a markdown file, optionally with some image, video or sound files. So (unlike your language) this is all "offline".

glicol looks cool, thanks for the link!

It has similarities, at least on the ultimate goals (creating efficient parallel code), but the approach is different: We start from already fully parallelized code and are just trying to recoup some of the performance loss of high-level programming language guarantees. While failing to parallelize loops in FORTRAN-like languages can be catastrophic (meaning that the code stays sequential), we at most pay the cost of the memory overhead.

That sounds like a pretty run-of-the-mill balanced binary tree? Rust has a BTreeMap: https://doc.rust-lang.org/std/collections/struct.BTreeMap.ht...

I... don't think that's true of Sourcehut? Drew has certainly argued for the fact that websites should be usable without Javascript, so it would surprise me if Sourcehut didn't follow the same standards.

I've had both shot and booster, and have since had COVID twice. Sure, that's anecdotal, but so is "How many people do you know...".

My wife, kid in a car seat, and I recently went on a two weeks vacation in our VW Polo, baby stroller, disassembled om changing table and two weeks worth of luggage included. Granted, the car was jam-packed, but it makes me think you could get the things you listed to fit in a smaller car.

SML can run in every major browser: http://www.smlserver.org/smltojs/

Interestingly, SMLtoJs predates Elm and PureScript, but never really caught on.

Looks exciting! To all readers: There are multiple parts to this post, use the numbers at the bottom of the screen to navigate.

I'm not terribly familiar with Go, but surely the comparison here must be with Rusts Reference[0]? It is a bit shorter than the Rust Book (a simple print-to-pdf says 435 pages vs. 664 pages, and 104 pages for the Go spec).

0: https://doc.rust-lang.org/reference

Rust does in fact have a story around overflows: https://doc.rust-lang.org/book/ch03-02-data-types.html#integ...