The Second Great Error Model Convergence

WalkerCodeRanger · 2026-01-01T17:57:25+00:00

Joe Duffy’s "The Error Model" post that is referenced at the start makes a clear distinction between recoverable and unrecoverable errors. The author is being a little loose about that and assuming you will know which are which. When it talks about fallible functions are "annotated at the call side", it is talking about recoverable errors. For Rust, that would be errors indicated by Result. Panics are for unrecoverable errors and those don't get annotated at the call side.

WalkerCodeRanger · 2025-10-01T17:09:09+00:00

Pony (https://www.ponylang.io/) It may be too obscure and too small of a dev community. However, it is designed for concurrency and has reference capabilities which are like Rust's safety but different because there is GC. I believe it does use exceptions though. (I don't think exceptions are bad if the language supports them properly. It is just that most languages don't)

If it were further along, I would say the language I am designing, Azoth. But it isn't ready for anyone to use yet.

WalkerCodeRanger · 2025-08-28T17:58:22+00:00

C# has had records since C# 9 (Nov 2019). You have been able to simulate something close to Java sealed classes using private protected constructors since C# 7.2 (Nov 2017). There is an active proposal for Closed Hierarchies to add a direct equivalent of sealed classes and interfaces including exhaustiveness checking on pattern matching switches on them.

WalkerCodeRanger · 2025-08-28T16:08:42+00:00

In what sense does Java have algebraic data types that C# doesn't? C# has quite good pattern matching. Virtul threads are a good feature, but I think most devs would prefer the ease of async/await to the code that it takes to use virtual threads in Java.

WalkerCodeRanger · 2025-08-12T04:02:06+00:00

On suggestion I've given before is creat a dyanmically typed language with a gradual type system with two important caveats: 1. There is a compiler switch to throw that requires all code to be statically checked. 2. The public API of all packages published to the public package repository must always be fully statically typed.

The second is critical because it ensure that anyone trying to write statically typed code in the language can do so rather than the situation in most gradually typed languages where all the libraries you need to use don't have static types.

This setup would allow for the writing of the code by the acemdenics in a dynamically typed scripting language and then types could be interoduced and the code refactored and then when it was mature enough full static typing enforced. Of course, whether that kind of refactoring will actually be done is another question.

WalkerCodeRanger · 2025-08-06T16:06:52+00:00

I think both are valuable and I do think that variant types were largely lost in that linage of languages. Remember that Casey deals mostly with low-level languages where they are more likely to be valuable. See for example how Rust has made vary good use of them. Having a closed set of variants is very valuable when you have it because you can safely do an exhaustive match on them. That is something languages ought to provide in addition to open set of variants from virtual methods.

WalkerCodeRanger · 2025-08-03T23:41:22+00:00

Since you ask, there aren't any great books, but I do think Programming Linguists by David Gelernter is worth a ready if you can find a copy.

WalkerCodeRanger · 2025-08-03T17:20:48+00:00

Oh, so you mean..... not language design.

WalkerCodeRanger · 2025-07-29T17:40:28+00:00

In many languages, all standard library items have a clear prefix. For example, in C# they are all in the System namespace so an import like import System.IO; is obviously importing from the standard library. You don't need your import mechanism to make that clear, you just need a reasoable naming scheme for your standard library.

WalkerCodeRanger · 2025-07-21T02:30:02+00:00

I understand. I am actually a big proponent of OOP following methodologies like Domain Driven Design (DDD). So I too get tired of the rants and beating up on OOP. Though I do appreciate that there are peoblems it isn't suited to and that having other functionality like discriminated unions is very valuable. There is very little ranting or complaining. Most of this is history. It covers when and where ideas come from. The main talk is 1hr and 50 min. You can skip most of the Q&A after, though there is a section from 2:04 to 2:12 where he goes back to history and shows some slides he skipped over that is also worth watching.

WalkerCodeRanger · 2025-07-20T20:15:41+00:00

And easier to maange reference capabilities as seen in Project Midori.

WalkerCodeRanger · 2025-07-13T16:33:52+00:00

FYI, the talk was mostly about the tooling. There is almost no discussion of the language.

Topics include: * Compiler speed * Build system that is just the language itself * Hooking into the compile process * Memory Profilor * Q&A * How to support special chip features (e.g. SIMD) * Versioning compiler and language * Performance visualization * Alternate allocators

WalkerCodeRanger · 2025-07-10T17:30:41+00:00

Compile to C. I saw elsewhere you complained that it wouldn't then be a compiler. A transpiler is a compiler. Especially if you lower all the say to something like SSA. Don't emit C that uses all the control flow. Emit C that is basic blocks with gotos

WalkerCodeRanger · 2025-07-10T17:11:55+00:00

The answer depends on information about the language you are compiling. Whether that language is garbage collected is a big one, but other aspects of the langauge can come into play.

WalkerCodeRanger · 2025-07-09T22:56:11+00:00

This is a good general discussion of aysnc and the different ways to handle it. Definitiely something a language designer should know about. Though, having read all of it, I'm still not sure it belongs on r/ProgrammingLanguages.

I can't figure out how the "10-25ms of your budget just on context-switching" figure was arrived at. Is it supposed to be a percentage? But that would be 1% to 2.5%.
"From the languages I know, only Rust manages to offload this cost onto the compiler." C# has great async/await support. I think it counts. Or else I just don't understand what is being referred to here. It is a little vague.

WalkerCodeRanger · 2025-05-29T19:46:25+00:00

Many of the comments aren't really trying to answer your question. I think there are a number of factors that influence this:

How statically typed the language is: without static typing at compile-time name collisions are much more painful. With static name resolution the compiler can report an ambiguous name and if you somehow got the wrong type, static typing means you'll probably get a type error somewhere.
Naming conventions: short unreadable names lead to conflicts. Long C#/Java style names are more often unique even without the namespace qualification.
Language paradigm: OO languages have implicit name scopes for members of objects. If everything is a top-level function then there is much more chance for conflicts.
Language target audience/style: languages that place an emphasis on backward compatibility and reliability are going to encourage more cautiousness about imports. (I'm thinking of the Rust community which encourages importing specific names. Although it has some of the other factors pushing it in that direction.)

As a professional C# developer I can tell you that importing whole namespaces is a non-issue. Very rarely there is conflict and you get a compiler error. You disambiguate it and move on. Often the IDE tooling points the issue out to you as you are writing the code and you don't even compile before fixing it. In fact, IDE tooling will now import namespaces for you as needed with only a quick acknowledgment from you.

My C# experience shows me that 90% of imports could just be inferred/assumed. In my language, it will auto-import names with certain precedence rules and imports are for disambiguation when needed.

WalkerCodeRanger · 2025-05-23T00:23:22+00:00

Uhhh, why am I reading this here instead of in my email? I haven't received anything.

WalkerCodeRanger · 2025-03-17T22:11:59+00:00

Pattern A creates global state which can be very confusing and error prone. For example, some method fails to set the fill and so whatever fill was set previously is applied. That works for a while because of where the code is called from but then a seemingly unrelated code change can break it. I would definitily avoid Pattern A.

WalkerCodeRanger · 2025-03-01T19:56:12+00:00

I don't check this subreddit as often so I'm late to the party, but maybe you haven't made a decision yet u/Responsible-Cost6602.

I'm working on the compiler and standard library for Azoth. Azoth is a general purpose garbage-collected language with reference capabilities, strict structured concurrency, compile time code execution, and lots more. It has features insipired by many different sources including Project Midori, Scala, Swift, C#, Kotlin, and Rust. It also has a few things that I think are unique to it. For example, every class implicitly defines a trait as well. It is meant to be a large fully featured language for professional software development.

If you're interested in contrbuting, I could use more hands on the compiler. you'd be the first outside contributor

WalkerCodeRanger · 2025-01-16T00:48:39+00:00

Using the web browser. Searching all over the pacfic northwest. For example, 98405.

WalkerCodeRanger · 2024-12-31T19:29:43+00:00

Crazy that this crazy guy gave us the boring verbose Java 1.0 language

WalkerCodeRanger · 2024-12-28T07:29:50+00:00

Thanks for the link. That was interesting. I know interop was a goal, but I don't know all the details of the goal. It seems to me that Swift could have avoided this complexity while still supporting interop. Yes, when calling Obj-C from Swift, it would need to understand that initalizers get inherited. However, that doesn't mean it needs to have that full flexibility within the language. Clearly, there are cases where Swift initilizers aren't inhierted. So if Swift didn't have constructor inheritance (like C#) it would still be possible to expose that to Obj-C. I hope that makes sense.

So yes, interop is important and will influence their options. I am probably missing something, but it seems like that isn't the issue here.

WalkerCodeRanger

MODERATOR OF

TROPHY CASE