Hacker News: Athas

New comment by Athas in "What Is in Road Flares?"

Athas — Wed, 15 Apr 2026 09:26:50 +0000

This page reads like an exasperated response to constant discussions and requests for how to extract strontium nitrate from road flares, and emphasizes that it is hard and pointless in the first place. I never noticed such discussions, but maybe it's outside of my bubble! Quite an amusing read nonetheless.

New comment by Athas in "I love the work of the ArchWiki maintainers"

Athas — Sun, 15 Feb 2026 15:58:19 +0000

As others have mentioned, such tools exist. However, I believe they do more harm than help. Good --help output does not make for good --man output. In particular, while man pages are terse, good ones are more than just lists of command line options, and the part of them that are a list of command line options will usually have more detail than --help. The writing of documentation is a place where I often see programmers employ automation inappropriately.

New comment by Athas in "Are arrays functions?"

Athas — Wed, 21 Jan 2026 08:06:25 +0000

That depends on the language. I have used (and implemented) languages where arrays are modeled as a function from an index space to some expression. During compilation, this is used to drive various optimisations. For those arrays that need a run-time representation, they may be stored in the classic way (a dense region of memory accessed with offsets computed from indexes), but also in more complicated ways, such as some kind of tree structure. These are still, semantically, arrays at the language level.

New comment by Athas in "Are arrays functions?"

Athas — Wed, 21 Jan 2026 07:34:59 +0000

The post explains that 'a[i]' can easily enough be written as 'a i'. Your suggestions do not resemble the current function application syntax in the language discussed in the post. The question is not whether a terse slice syntax can exist (clearly it can), but whether a syntactic similarity between indexing and application can also be extended to a syntactic similarity between slicing and application.

New comment by Athas in "Are arrays functions?"

Athas — Wed, 21 Jan 2026 07:18:13 +0000

Depending on how you look at things, functions can also be mutated at run-time. Most impure languages allow you to define a function that has some internal state and changes it whenever it is applied. In C you would use 'static' variables, but languages with closures allow for a more robust approach. Scheme textbooks are full of examples that use this trick to define counters or other objects via closures. You can well argue that these functions do not "mutate", they merely access some data that is mutated, but there is no observable difference from the perspective of the caller.

New comment by Athas in "Go.sum is not a lockfile"

Athas — Thu, 08 Jan 2026 12:11:40 +0000

In some sense, Go does not allow you to change the major version. Packages with the same name but different major versions are treated as different packages.

New comment by Athas in "The biggest semantic mess in Futhark"

Athas — Thu, 02 Oct 2025 06:16:22 +0000

It is basically dependent types, but there is a specific and intentional omission (no true dependent products) that interacts with another feature (the ability to hide sizes) that ultimately causes the mess. I elaborated on it here: https://futhark-lang.org/blog/2025-09-26-the-biggest-semanti...

Steering Committee Retrospective

Athas — Thu, 18 Sep 2025 07:55:16 +0000

Article URL: https://www.haskellforall.com/2025/09/steering-committee-retrospective.html

Comments URL: https://news.ycombinator.com/item?id=45286839

Points: 3

# Comments: 0

New comment by Athas in "My Foray into Vlang"

Athas — Sun, 31 Aug 2025 09:26:29 +0000

This blog post showcases V in a positive light. I suppose it is good that people can have productive experiences with it now, although I don't see from this post why it is a significant improvement on Go.

The problems discussed (performance, compiler fragility) are somewhat worrying though. My impression is still that V is not particularly robust and focuses on flashy things instead of getting the basics right. I must admit that it is however still hard to look at V objectively, given the near-fradulent presentation it had when it was first announced.

New comment by Athas in ""high level" languages are easier to optimize"

Athas — Sat, 12 Jul 2025 17:58:02 +0000

The greatest value brought by compiler optimisations is removing the overhead of convenience. Sometimes that is about avoiding the boxing that is a necessity in many high level languages, but in other cases it serves to allow a more modular programming style without overhead. Stream fusion is a good example: it lets you structure your program as small and composable units, without the cost of manifesting intermediate results. That is not merely about avoiding the inherent inefficiency of e.g. Haskell, but about permitting different styles of programming, and the argument is that a low level language simply cannot allow such a style (without overhead), because the required optimisations are not practical to implement.

New comment by Athas in "Beware of Fast-Math"

Athas — Sat, 31 May 2025 17:32:14 +0000

How does this avoid rounding error? Division and multiplication and still result in nonrepresentable numbers, right?

New comment by Athas in "Beware of Fast-Math"

Athas — Sat, 31 May 2025 17:29:53 +0000

The problem with fixed point is in its, well, fixed point. You assign a fixed number of bits to the fractional part of the number. This gives you the same absolute precision everywhere, but the relative precision (distance to the next highest or lowest number) is worse for small numbers - which is a problem, because those tend to be pretty important. It's just overall a less efficient use of the bit encoding space (not just performance-wise, but also in the accuracy of the results you get back). Remember that fixed point does not mean absence of rounding errors, and if you use binary fixed point, you still cannot represent many decimal fractions such as 0.1.

New comment by Athas in "Beware of Fast-Math"

Athas — Sat, 31 May 2025 17:27:46 +0000

Yes, but you're not going to have efficient transcendental functions implemented in hardware.

The GradBench Benchmark Suite for Automatic Differentiation

Athas — Sun, 06 Apr 2025 20:16:49 +0000

Article URL: https://sigkill.dk/blog/2025-04-03-gradbench.html

Comments URL: https://news.ycombinator.com/item?id=43604611

Points: 1

# Comments: 0

New comment by Athas in "Aiter: AI Tensor Engine for ROCm"

Athas — Mon, 24 Mar 2025 21:08:53 +0000

Who do you work for? And is packaging ROCm for Debian really a full-time job, or is it just a part of your job?

As messy as ROCm's packaging is, I can't imagine spending all day every day trying to fix it.

New comment by Athas in "Hedy: Textual programming made easy"

Athas — Tue, 28 Jan 2025 11:55:36 +0000

Most recent I remember was in 2011: https://github.com/ocaml/ocaml/issues/5419

New comment by Athas in "Hedy: Textual programming made easy"

Athas — Mon, 27 Jan 2025 10:17:53 +0000

The comments were quite often in French, however! Until relatively recently, the OCaml compiler would also sometimes emit error messages in French in some obscure cases.

Community Portal for Automatic Differentiation

Athas — Tue, 14 Jan 2025 19:22:51 +0000

Article URL: https://autodiff.org/

Comments URL: https://news.ycombinator.com/item?id=42702405

Points: 1

# Comments: 0

New comment by Athas in "Where is James Bond? Trapped in an ugly stalemate with Amazon"

Athas — Mon, 30 Dec 2024 14:22:48 +0000

What are they supposedly trying to do with Warhammer (40k)? I am aware that Amazon has the rights and are working on developing something, but apart from the Secret Level episode (which was good), has there been any details?

While some of what Amazon has made is terrible, much is good. They produce so much that the average quality is pretty close to the global average, so I find predictions challenging.

New comment by Athas in "8 months of OCaml after 8 years of Haskell in production (2023)"

Athas — Tue, 03 Dec 2024 07:44:11 +0000

This is not the case in Haskell, because let-bindings can be self-referential, while lambdas cannot (without using a fixed point combinator). Also, in most functional languages, a let-binding causes type generalisation, which is not the case for a lambda.