throwaway17_17

Allegedly the pre and post conditions, in varying degrees of certainty according to the evaluation semantics selected, are propagated to the optimization passes of gcc and llvm. However, I haven’t seen any detailed blog posts or summaries of the effectiveness or reliability of this feature. Sorry it’s not a lot of info, but it was what I knew off hand based on previous reading.

I agree, the only reason LSP exists as it does is for a world running on electron based applications. Plug-ins and application extensions are not new technology and they are nearly universally more efficient in the forms designed and used prior to 2005-ish. I understand why VSCode exists and why it is used so often by developers, but it is certainly a downgrade from more language specific options that could exist.

There are some arguments that do carry water in favor of using a client/server protocol transmitting JSON, in particular, the ability for a nearly complete decoupling of analysis of code and the displaying and editing of that code. Also, LSP was (to my knowledge) the first language/platform/usecase agnostic protocol intended for use in code editors.

I get why this is where a big chunk of developers have ended up, but I do bemoan the lost potential for a language to grab mindshare and popularity on the usability and performance of its tooling and developer experience via-a-vis a custom designed and hyper specific code editor. I mean, Rust and Elm received endless praise for their error messages as a massive boon to developer experience, so it is a facet of language design and implementation that can act as great advertisement. I just hate that the prevalence of LSP at this point precludes custom editors as a first choice in the current zeitgeist.

Thank you for the link to Watts’ talk. It is a great watch and is certainly a great jumping off point for anyone writing fiction in the field.

It also could be one of the most terrifying talks I’ve ever heard, but since it is eight years old, I am going to just pretend all of the research he mentions fell through and I have nothing worry about.

This being primarily generated leads me to wonder: is there a good source, written by academics or professionals, for this information?

Although I am not interested in using LLMs for much of anything, the theory and implementation (where the implementation is not just use some prepackaged library code) in a comprehensive presentation is not something I’ve seen before.

Your comment seems to imply that async/await should be or is in some setting not just sugar for promises. But, I am under the impression the async/await is (and always has been) sugar over explicit promises. Not just in JavaScript but in C#, where the sugar originates, as well.

Is there somewhere that async/await is implemented as a different concurrency mechanism?

I know it’s a late reply, but the answer is absolutely both of us are exceptionally neurotic. But in completely different ways.

After digging through a recently passed relative’s hard drive (the computer barely functioned so I pulled it) and having to search through years of garbage that where never deleted to find the photos, Word documents, and WordPerfect documents my aunt ‘knew’ where stored there somewhere, this is not an insignificant gift to leave my family with.

If you are asking in the context of Idris 2.0 (the current version), ST is not really related.

However, if you mean ST in Idris 1.0, there is a definite correlation. The mechanism that ST used for enabling local mutations was very similar to the mechanism that the typestate pattern in Rust is using. ST was a framework for formalizing State Machines in dependent types which is the mechanism TFA is analyzing.

From a language design perspective I go back and forth on named params. I think the only conclusion I’ve reached is that I am not in favor of them being optional, but I think that is more a concern for implementation of the language and less about how it effects users.

How do you find the feature useful in this instance, I can’t quite picture how that works for typestate pattern functions.

I feel so seen right now. My partner complains about me closing apps on my phone consistently. I also have to hold myself back from defragging and continually cleaning up my storage drives.

I too am nearly certain that the positive benefits are approaching nil, but I still feel it should be helpful.

I think this is a good argument for the Ticket, however, for the case where these three functions are generically useful, not just used in this specified order, I would write a specific function, just copy-paste of the bodies capturing the required ordering as an implementation detail.

Obviously if you are operating in a wide, concurrent async system then the Ticket and separate function calls is the better mechanism for the ordering.

I know this wasn’t the crux of your post, but do you find that you primarily look at types as puzzles in a majority of your code? I have a fundamentally different view and find other perspectives interesting when thinking about language design.

As a separate point, I think this is an excellent example of making invalid states unrepresentable.

Casey Muratori talk from the Better Software Conference 2026.

Has this become a ‘smell’? I tend to start my HN comments that are going be negative with versions of this, or my habitual “Genuine question, ..”; but if this is going to flag readers’ internal LLM-detector I will have to find some other way to indicate I’m actually interested in a dialogue (versus the shit posting that a more brief reply might signal).

I was talking with a junior at the office today about LLM output and mentioned em dashes, to which responded “oh, I thought that was just where formatting for hyphens was going, I guess I learned something from the AI writing instead of the other way around” and god, his acceptance of it was just deprrsssing.

I wish I could give more up votes for this comment. These made my Friday night. Thanks for the links.

I wrote the following and then realized it sounds a little pretentious, but I think it get my point across regardless. Also, I’m not a scholar of Buddhism or a practicing Buddhist, so I could be grossly generalizing or misunderstanding what I have read, but I believe I’m not to far off base.

I think the Buddhist reply would be that living without craving and without yearning leads to truly being ‘alive’ and enables one to feel, to touch, and to experience the world as it is and in the immeasurably short time a person is alive within it. An existence where the present is experienced and cherished in the moment of having it, while knowing and accepting the inevitability of this moments ending. Such a life, in the Buddhist tradition, embodies the knowing and accepting of the ultimate emptiness of reality and then proceed to live, not in spite of the emptiness, but in the full appreciation of the act of living.

The way you phrased your second block, particularly your last sentence is exceptional. I’m not sure if I agree with the substance (I’m pretty sure I’m about 90% there), but the phrasing is very emphatic.

A lot of discussions I’ve seen, and taken part in, when focusing on Camus and his cadre of fellows lead to a comparison between Buddhist thought and existentialist thought. I tend to side closer to the Buddhist outlook and acceptance of the ground truth of sunyata (often translated ‘emptiness’) versus the more modern tendency toward western Nihilism as a response to the Absurd. The depths of response in people and their dealings with these thoughts and feelings interest me, but I also like to watch people choosing between descriptions of Absurdity to try and make it a completely different concept to the Buddhist ideas.

I’m not sure I agree that ‘Camus couldn’t conceive of’ the Buddhist response to the inherent tension arising from craving ultimate meaning where none is possible; however, he and the other existentialists certainly went to great written lengths to seemingly avoid finding the Buddha’s answer.

When I decided to really learn how to program, after dabbling in very basic C++ from books and using BASIC this article and Eric S. Raymond’s ‘How to Become a Hacker’ [1] (CATB is struggling to load at all these days it seems) were two of the first articles I found. While HtBaH was probably more influential on me immediately, Teach Yourself was a great appetizer for the concept of pacing myself in my learning and in the choices I made.

With all the “AI” has made coding/learning to code a dead end and unnecessary crud being peddled currently I don’t know if people who want to actually learn to program are going to find resources that can be as motivating as this and other articles from `the before times`. It leaves me slightly bummed out, but in my less pessimistic moments I think motivated learners are going to see through the hype and find these types of resource anyway.

On a side note, the Norvig’s articles about implementing a Scheme in Python were my first foray into designing and implementing programming languages, compilers, and interpreters which really shaped my interest all the way through to today.

1) http://www.catb.org/~esr/faqs/hacker-howto.html

That depends mostly on the jurisdiction, the structure of public defense in said jurisdiction, and the quality, resourcing, and culture of the individual Public Denfender’s Office. I do understand the view from strictly statistical analysis, but there are subtleties (particularly, misdemeanors vs felonies) in how plea vs trial plays out in various parts of the US not captured by large granularity stats.

Guilty Gear and Hi-Fi Rush are both Unreal 4 games and a lot of the comments in this thread are about the Lumen+Nanite ‘grain’ that seems very present in Unreal 5.

I certainly think there is was inflection point for Unreal’s inherent complexity moving to 5 that made it exponentially more difficult to customize when compared to 4 as far as implementing highly customized renderers (in particular) and overall customization in general.

I think this is a situation where the term systems programming is too un- or ill-defined to be anything but a semantic argument in waiting. I am not particularly fond of the broader meaning systems programming has taken on but I understand it. As a term of art for developers systems programming now encompasses:

   - infrastructure development like Docker and Kubernetes
   - general utilities programming like grep, terminal emulators, compilers, etc
   - performance sensitive artifacts like OS kernels, video/audio codecs, hardware interaction layers

and more in common usage. Without some sort of communal understanding of the taxonomy of development areas discussing things like GC in systems programming becomes tedious and often prone to arguing past people due to conflicting understanding of terminology.

I do think there are genuinely ripe areas of research and development for performance and determinism sensitive memory management and subsequent outreach to make sure the potentially effected developers and language designers actually have a chance to evaluate any advancements. But it sure seems like it would take an act of ‘developer congress’ to make sure people were talking about the same things.

What are you describing as a frame update? I am trying to be as generous as possible to your comment and thereby assuming there is a disconnect between my understanding of ‘frame update’ and yours. Genuinely curious, because that term as I am familiar with it means the entire time allotted to generating and rendering a single frame for display. If that’s what you meant, you are asserting that a ‘modern game’ is typically running at 333 fps. I am typically using the term ‘modern game’ to describe newly releasing AAA games nearly all of which struggle on many hardware configurations to achieve a steady 60 fps (which is 16 ms per frame).

Do you know of any articles, tests, or implementation breakdowns that show this. I don’t have the personal experience to agree, but if that’s the case Inwould really like to know how the improvements were achieved.

If this is a joke, I actually chuckled.

But, maybe this is a terminology issue conflating an embeddable language with a language used for embedded programming. I think this is one of those CS issues prevalent for non-native English speakers (especially when those devs are relying on translations of text without LLM style semantic analysis of the source).

The first refers to the shipping of a language interpreter within the executable of a program, where that interpreter then processes “scripts”, data files, high level non-programmer editable object attributes or behaviors, etc. The most prevalent example of this is shipping a Lua interpreter inside a video game for interpreting hot reloadable asset scripts. The second usage of embedded is the implication that code is being run on a microcontroller or SoC ‘embedded’ within some other product or device.

I agree with your objection to treating goroutines as the baseline implementation of fibers. However, I would disagree with categorizing the feature as a library feature vs a language level feature. In “low-level” languages (C, Rust, Zig, C++, etc) the ability and option exists for having ‘green threads’ with most of their commonly assumed characteristics be library based constructs (although see [1] for why that’s not true for threads in general ). However, almost all managed/runtime-required/scripting/“high level” languages lack the facilities to implement almost any realistic types of fibers and any FFI based implementations are going to suffer severe syntax integration issues (I am assuming somewhat on this point).

TL;DR Green threads are on a library feature for low level languages.

1 - Threads Cannot Be Implemented as Libraries (Boehm 2005), https://dl.acm.org/doi/10.1145/1064978.1065042

Not to derail this thread on Mach, which as I stated in another comment has some pretty appealing characteristics for me, but since you’re here and the dev of another ‘low-level’ programming language:

I read through a segment of your language’s docs when it was on the front page a couple of days ago ago. Since you’re talking safety’s is there a link (or just a suggested starting point) to read about Ü’s safety mechanisms and guarantees?

I feel like I sit along a different axis in the safe versus unsafe discourse, so I don’t discount languages like Zig or Mach for not providing opt-out safety for certain areas of concern and I don’t give extra credit to languages like Rust or Ü for having those features. What I am interested in is what choices where made and why, then what do those choices mean for me as a potential user of a language.

I find the goals of explicitness and maintainability to be really pitched to my current taste. From a quick view it looks like the syntax is approaching a local maximum for conforming to expectations and not sacrificing the explicitness sought.

As the developer, where do you land on meta-programming for the language? I applaud the straight up nature of ‘the battery will never be included’ and the reminder to consider the possibility of a feature being a library instead of a syntax or language feature. I certainly don’t think meta-programming is essential, but the ability can contribute to the ease of use for library code.

And I’ll ask now since it always comes up, where does Mach stand on ‘advanced’ type theory uses for ‘low-level’ programming? I noticed the admonition that safety is the developers job which is sure to bring some ‘heat’ from the memory-safety-is-table-stakes crowd, in light of that, where does Mach stand regarding ways to ensure ‘safety’?

In the ‘Caveats’ section the author discusses that the advice only applies to types constructed via Record Syntax and that datatypes with positional arguments are exempt from the rule/preference proposed.

I wonder if the argument for the do notation’s usage being better along several metrics can stand generalization. There are sometimes discussions about the merits of named argument to functions and data constructors versus the much more common positional syntax, the arguments made in favor of more ‘broad spectrum’ named arguments reflect the more specific pro’s being argued in TFA.

It would be interesting to see what types of syntax additions, and the accompanying weight of those additions throughout an entire code base, would prove an acceptable trade off for moving away from positional arguments being the default. I almost assume the extra line noise and extra name selection would be the most negative effects, but the most positive effects are harder for me to guess at. But overall, the reaction of devs to more ‘book keeping’ in there code is hardly ever positive.

After so wrote the comment below I realized that it really is just ‘um, actually…’ about discussing using concurrency vs implementing it. It’s probably not needed, but I do like my wording so I’m posting it for personal posterity.

In the context of an article about C++’s coroutines for building concurrency I think structured concurrency is out of scope. Structured concurrency is an effective and, reasonably, efficient idiom for handling a substantial percentage of concurrent workloads (which in light of your parent’s comment is probably why you brought up structured concurrency as a solution); however, C++ coroutines are pitched several levels of abstraction below where structured concurrency is implemented.

Additionally, there is the implementation requirements to have Trio style structured concurrency function. I’m almost certain a garbage collector is not required so that probably isn’t an issue, but, the implementation of the nurseries and the associated memory management required are independent implementations that C++ will almost certainly never impose as a base requirement to have concurrency. There are also some pretty effective cancelation strategies presumed in Trio which would also have to be positioned as requirements.

Not really a critique on the idiom, but I think it’s worth mentioning that a higher level solution is not always applicable given a lower level language feature’s expected usage. Particularly where implementing concurrency, as in the C++ coroutines, versus using concurrency, as in Trio.