<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Ante</title>
    <link>https://antelang.org/</link>
    <description>Recent content on Ante</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 24 Oct 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://antelang.org/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>A Vision for Future Low-Level Languages</title>
      <link>https://antelang.org/blog/vision/</link>
      <pubDate>Fri, 24 Oct 2025 00:00:00 +0000</pubDate>
      
      <guid>https://antelang.org/blog/vision/</guid>
      <description>A Vision for Future Low-Level Languages I&amp;rsquo;ve had this vision in my head for quite a while now on what code written in a low-level language could look like. This vision has shaped my design of Ante and although I&amp;rsquo;ve alluded to it before, I&amp;rsquo;ve never explicitly stated it until now.
Now, what makes a language low-level is a bit contentious. I&amp;rsquo;m using it here to describe a group of languages I have no better descriptor for: C, C++, Rust, and Zig, among others.</description>
    </item>
    
    <item>
      <title>Stable, Mutable References</title>
      <link>https://antelang.org/blog/stable_mutable_refs/</link>
      <pubDate>Thu, 21 Aug 2025 00:00:00 +0000</pubDate>
      
      <guid>https://antelang.org/blog/stable_mutable_refs/</guid>
      <description>Introduction  In my first blog post I introduced &amp;amp;shared mut references as a way to achieve safe, shared mutability in a language with unboxed types. For more information on those, start with the first blog post. As a brief summary though, &amp;amp;shared mut references can be aliased freely and mutate freely with the one restriction of not being able to be projected into any &amp;ldquo;shape-unstable&amp;rdquo; types.
What is a shape-unstable type?</description>
    </item>
    
    <item>
      <title>Why Algebraic Effects?</title>
      <link>https://antelang.org/blog/why_effects/</link>
      <pubDate>Wed, 21 May 2025 00:00:00 +0000</pubDate>
      
      <guid>https://antelang.org/blog/why_effects/</guid>
      <description>Why Algebraic Effects Algebraic effects1 (a.k.a. effect handlers) are a very useful up-and-coming feature that I personally think will see a huge surge in popularity in the programming languages of tomorrow. They&amp;rsquo;re one of the core features of Ante, as well as being the focus of many research languages including Koka, Effekt, Eff, and Flix. However, while many articles or documentation snippets try to explain what effect handlers are (including Ante&amp;rsquo;s own documentation), few really go in-depth on why you would want to use them.</description>
    </item>
    
    <item>
      <title>Simplification Through Addition</title>
      <link>https://antelang.org/blog/simplification_through_addition/</link>
      <pubDate>Sun, 17 Mar 2024 00:00:00 +0000</pubDate>
      
      <guid>https://antelang.org/blog/simplification_through_addition/</guid>
      <description>Ante&amp;rsquo;s goal was always to be a slightly higher level language than Rust. I always imagined Ante to fill this gap in language design between higher-level garbage collected languages like Java, Python, and Haskell, and lower level non-garbage collected languages like C, C++, and Rust. I still think there&amp;rsquo;s room there for a language which tries to manage things by default but also allows users to manually do so if needed as an optimization.</description>
    </item>
    
    <item>
      <title>Algebraic Effects, Ownership, and Borrowing</title>
      <link>https://antelang.org/blog/effects_ownership_and_borrowing/</link>
      <pubDate>Tue, 20 Feb 2024 00:00:00 +0000</pubDate>
      
      <guid>https://antelang.org/blog/effects_ownership_and_borrowing/</guid>
      <description>Introduction Algebraic Effects are a useful abstraction for reasoning about effectful programs by letting us leave the interpretation of these effects to callers. However, most existing literature discusses these in the context of a pure functional language with pervasive sharing of values. What restrictions would we need to introduce algebraic effects into a language with ownership and borrowing - particularly Ante?1
 Ownership Consider the following program:
effect Read a with read : Unit -&amp;gt; a the_value (value: a) (f: Unit -&amp;gt; b can Read a) : b = handle f () | read () -&amp;gt; resume value This seems like it&amp;rsquo;d pass type checking at first glance, but we can easily construct a program that tries to use the same moved value twice:</description>
    </item>
    
    <item>
      <title>Achieving Safe, Aliasable Mutability with Unboxed Types</title>
      <link>https://antelang.org/blog/safe_shared_mutability/</link>
      <pubDate>Mon, 29 Jan 2024 00:00:00 +0000</pubDate>
      
      <guid>https://antelang.org/blog/safe_shared_mutability/</guid>
      <description>This is part of Ante&amp;rsquo;s goal to loosen restrictions on low-level programming while remaining fast, memory-safe, and thread-safe.
 Update: The syntax of Ante code snippets has been updated to reflect Ante&amp;rsquo;s current syntax.
  Background  When writing low-level, memory-safe, and thread-safe programs, a nice feature that lets us achieve all of these is an ownership model. Ownership models have been used by quite a few languages, but the language which popularized them was Rust.</description>
    </item>
    
    <item>
      <title>Roadmap</title>
      <link>https://antelang.org/docs/roadmap/</link>
      <pubDate>Sat, 25 Jun 2022 00:00:00 +0000</pubDate>
      
      <guid>https://antelang.org/docs/roadmap/</guid>
      <description>Ante&amp;rsquo;s compiler has recently finished a complete rewrite and is now incremental, concurrent, and fault-tolerant - although general performance still has much room for improvement.
 This page is for an in-depth roadmap of ante to show which features are currently implemented in the compiler.
All designs in the ideas page are not implemented as their design is still non-final and may not be selected at all.
Key:
 Implemented [~] Partially implemented Not implemented  Note that since the compiler is still immature, a feature marked as implemented may not be completely bug-free or may have some unimplemented corner cases.</description>
    </item>
    
    <item>
      <title>Ideas</title>
      <link>https://antelang.org/docs/ideas/</link>
      <pubDate>Tue, 02 Nov 2021 00:00:00 +0000</pubDate>
      
      <guid>https://antelang.org/docs/ideas/</guid>
      <description>This page is an incomplete list of features that are currently being considered for ante but for one reason or another are not included in the language already. These features are listed in no particular order.
 Overloading Given ante does not have true methods, some form of overloading could greatly help alleviate user frustration by allowing modules like Vec and HashMap to both be imported despite defining conflicting names like empty, of, insert, get, etc.</description>
    </item>
    
    <item>
      <title>Language Tour</title>
      <link>https://antelang.org/docs/language/</link>
      <pubDate>Mon, 01 Mar 2021 00:00:00 +0000</pubDate>
      
      <guid>https://antelang.org/docs/language/</guid>
      <description>Ante is a low-level impure functional programming language. It is low-level in the sense that types are not boxed by default and programmers can still delve down to optimize allocation/representation of memory if desired. A central goal of ante however, is to not force this upon users and provide sane defaults where possible. This can be seen in the ability to opt-out of move semantics and even temporary references much of the time by using shared types which resemble programming in a garbage-collected language with boxed values.</description>
    </item>
    
  </channel>
</rss>
