helix278

Depends on what you mean by functional language. I was considering main-stream languages that support some form of functional programming. So Rust, F#, C#, Kotlin, Swift, Typescript, etc

Superficially, I find the syntax very untuitive to read. Most languages opt to use <> for typevariables. Is there a specific reason you chose to deviate from that and use []?

I write all production code by hand, it's the only way I'm sure I know what the code does. Moreover, when the problem space or code base is more complex, it is necessary to keep in touch with reality and test your understanding by writing the code.

I see colleagues using LLMs more and more, and the number of bugs found by QA is increasing dramatically, because the LLM was not thorough enough and the developer (now reviewer I guess) missed the edge cases too because the code, tests and comments looked convincing.

> That is not a benchmark result. That is a different way of thinking about how AI models get built.

tiresome

I'm always surprised at the high frequency of major typos in titles from HN posts

Letting the bytes go by

Ligatures exist

You make it sound like reducing the big O complexity is a dumb thing to do in research, but this is really the only way to make lasting progress in computer science. Computer architectures become obsolete as hardware changes, but any theoretical advances in the problem space will remain true forever.

I have had treesitter crashes in the past editing markdown, causing helix to segfault, but the particular bug that caused my crashes has been fixed since years.

Although I'm more of a functional programmer and ADT addict, I still find this language appealing. Reading the manual, it feels like a lot of correct design decision have been made, contrary to languages like C++. Most notably for me: 1) Memory allocation and reference is restricted, leading to less problems with memory management. 2) Syntax is more flexible, allowing for higher levels of abstraction.

I'm not a compiler dev, but I know that many functional programming languages struggle with this in the same manner if the target platform does not support TCE itself, and therefore require trampolining.

But entirely definable in user code, so an effect is essentially a set of possibly impure operations you can perform (like I/O or exception throwing), and a function that exhibits that effect has access to those operations. Of course the call sites then also exhibit that effect, unless they provide implementations of the effect operations.

TCO (tail call optimization) is often confused with TCE (tail call elimination), the latter is a runtime guarantee whereas the former is a compiler's best effort attempt to statically optimize tail calls.