This one is up to date and it's definitely inconsistent, but I could not use ':' in place of '->' without creating an ambiguous grammar. Same for parenthesis in the return type since you can have a comma separated list:
It is not possible since you can create new integer types by sub-classing the primitive ones:
class UserId: Int64
...
end
var user = UserId: 42
I also plan to replace predefined Int64, Int32, ... by generic types Int(64), Int(32), ... LLVM allows any integer size and Copper allows this kind of generic types.
The parallel assignment just work mostly like it does in ruby so that doesn't look weird to me (except the need for 'var' in the first place).
Agreed on the rest, though I don't understand what the problem would be with recursion. Is it using reference passing also for primitives like integers?
> Is it using reference passing also for primitives like integers?
That's what I assumed, but honestly I might have misunderstood the docs. This passage is not very clear:
> Copper manipulates only references to objects. Simple data types such as integers must be seen as references to stateless objects (i.e. objects that have no state in memory).
Sounds like they store the integer in the reference itself in that case. Which also is how Ruby does things (though Ruby has to decide what is what at runtime and thus steal a couple of bits off every integer).
Surprisingly, the most irritating nitpick for me is the choice of the file extension — surely that should've been ".cu", not ".co"? If I were developing an e.g. Iron programming language (hypothetically — although perhaps so named a language already exists), I'd pick ".fe" in a heartbeat.
Then again, I'm the kind of person who've chosen $'.\U0001F9CC' (that is, $'.\xF0\x9F\xA7\x8C') for a file extension of my own toy language so...
It’s nice they tried with a more fleshed out exemplar. Polymorphism (“generics”) and interfaces (“OOP”) would have been even better to see, especially across any kind of visibility boundary enforced by the language (packages, and the like.)
Programming to an abstract interface — and in large codebases, enforced visibility controls — represent the middle ground everyone wants, in my experience, between “OOP” and “sir, this is C”.
The example definitely shines. Doing something barely non-trivial is great since it gives a feeling for the language. I wish other language introduction pages would take note.
It does feel like you need some shared understanding with the author about what the interesting parts of a programming language are and what can be left implicit.
Perhaps the author and I have similar intuitions? I guess I also like that isn't pure LLM output style. It was refreshing to see some human work.
What's the difference between an exemplar and an example?
between “OOP” and “sir, this is C”.
That's more templates, ownership and operator overloading.
Polymorphism is not a modern way to program because it introduces dependencies and enormous speed hits from pointer chasing, both of which are corrosive to a good program.
An example is any random instance of something that illustrates a concept. You can load up a document with examples to demonstrate a range of possibilities. An exemplar is the chosen best way to model and explain a concept.
So in a programming text for a new language, one would use examples of things that are strings, or examples of structures one might declare. You might even see examples of multiple ways to solve a problem in code. An exemplar though shows the one best - or at least most recommended - way to do something in the language.
You'd choose something that's less than ideal if you're including multiple examples, because it's unlikely every example is the best one. You might give an example labelled specifically as a bad example. The word exemplar might be more familiar to many English speakers as the form "exemplary".
It can be difficult to know if your example is the exemplar. It can be reasonably assumed that if the creator of the language provides only one example, it at least should be the best one. It is at least the best one in the docs if it's the only one.
Not mine, but I found this to be really interesting as a language created by one person for their own use.
Also really interesting are the author's blog with articles on language design (for example his thoughts on exceptions, and how he added them to his language, then decided against them), and the change log for the language, showing its evolution.
I need to put a disclaimer to say that I hate when people hijack a post about foo to talk about bar, but:
> The language is not object oriented but it provides some features to facilitate object oriented designs.
It has classes and implicit `self`. Not nothing, but I don't think it's incorrect to say has any more OOP than general purpose languages like Lua or JavaScript in that sense.
Something like Pony[1] is a more mature and feature rich entry and has a much better OOP story.
All that said:
a) I'm sorry for doing the thing I hate when other people do
b) Creating a language is a big undertaking, and it's super cool that they did it
c) I see it seems to already be written in Copper too, which is also very neat!
OOP is one of the weirdest topics in computer science in that no one can agree on what it
means. Even proponents of “OOP” have wildly different ideas about what it means. For some it’s “encapsulation”, for others it’s “inheritance”, for others it’s “message passing”. It seems the glue that binds OOP proponents together is little more than the sequence of letters: O-O-P.
I drank the Elegant Objects[1] koolaid, and recommend the two books (Elegant Objects vol 1 and 2) whole-heartedly to anyone interested in OOP. Pony lang lets you write 95% of the kind of OOP described in the books idiomatically, without any kind of crazy shenanigans.
I think most people today would say encapsulation and message passing are pretty core to the definition of OO and inheritance is largely seen as an anti-pattern.
One thing I really like about Elegant Objects is that it is very palatable to FP enjoyers. Objects must encapsulate state, but they must also be immutable. Good OOP is declarative like good FP. It looks a lot like lisp imo. You're encouraged to code against interfaces instead of using inheritance etc.
Re "c)": No, self-hosting is the biggest temptation, and the worst mistake, for any programming language. It's death to bootstrapping. However, if you do succumb to the temptation to self-host, having a C backend, as Copper does, is probably the best way to handle it.
The usual argument is that it is a distraction when you’re designing a language, and it leads to programming languages that are all excellent for writing compilers and parsers, but not particularly good for other things.
Since the majority of programs are not compilers, it might make more sense to focus on interesting things that aren’t relevant to compilers.
Some ideas from the top of my head: async I/O, a great SIMD story, effect systems, robustness systems for long-running processes (I’m only aware of Erlang/Elixir), and many others.
Compilers do exercise some things, like error handling and memory management, but they’re not particularly difficult or interesting in general.
I had a little homebrew CI system, and decided its first use case would be building itself. Seems like an extremely obvious thing to do, right?
The problem happens when you have bugs and test failures. The hoster and hostee look the same, behave the same, and emit the same error messages. So I had unknowingly opted into spending a big chunk of my debugging time being confused and wrong about A) where errors were coming from and B) what they even signified.
Basically, self-hosting too early, before the thing was stable and trustworthy, was a disaster. (It's obvious in retrospect, really, but was still pretty awful at the time.) I tried again later, after everything had stabilized and it was routinely building other projects routinely, and it was fine.
The main objection I used to have was there are infinite things to do when building a programming language, it's already enough to build 1 compiler, you probably shouldn't also build a second as your main stress test of the language.
That said if your languages is for building compilers you'd probably want to do it. Otherwise, basically no one writes compilers, and if they are they're writing them for their own languages in something much more mature than your nascent language. And if the ambient advice is to bootstrap asap, they'll only be using your language for a hot second anyway, so they're the worst users to cater towards.
These days I think all languages should try to do it with an LLM because, why not? That also means bootstrapping a compiler isn't exactly an impressive feat anymore, most new languages are doing it now.
What additional cost does it have to implement the toolchain in C? I would say there is some benefit in terms of implicit testing to have a compiler self-hosting. But having a toolchain in C also has real benefits.
C is a notoriously difficult language to work in. It has no build system, no module system, an anemic standard library with footguns like null terminated strings, loads of undefined behavior, etc. Moreover, and maybe most importantly, the people developing the language have less opportunity to dogfood it.
I’m sure there are benefits to a C toolchain, but the costs overwhelmingly favor self-hosting for many languages.
We see so much languages being invented, and many of them do active anti-C marketing. But personally, I do not find it difficult to work in and also enjoy it much more than working in many other languages. There are, of course, build systems one can use, they are just not tied to the language - which build systems should not be. I also do not find most UB a problem in practice, many of them can be fixed simply by using the right compiler flags. Some are more difficult to fix, but think the problem is massively exaggerated. One can also use C with a garbage collector, as GCC does (technically it is now C++).
I like working in C too, but if better C developers than me say they can’t use it safely then I’m not going to think that I somehow can.
And even though I like writing C, the build tooling and the lack of modules system and a bunch of other footguns remain. (And say what you will about language-specific build tools, but they work very well for 99% of cases, and the benefits of the entire ecosystem using the same tool are significant).
Moreover, I want contributors to my language, and the reality is that however much I like C, the intersection of people who want to work on my language and people who like writing C is going to be vanishingly small. If my language is C-like (e.g., Zig) then that intersection will likely be much bigger, but as the target language approaches C, the benefit of using C goes to 0.
I think the argument that it is too difficult to write safe C misleading. While it is very difficult to write perfectly safe code in C, this seems to be used as explanation for the amount of CVEs we see. But when I look at the CVEs, the code is often terrible! I recently read a study where the authors observed that most of the projects did not compile without warnings when using GCC's analyzer. At the same time, the Rust rewrite of coreutils with more than 100 CVEs does not exactly convince me that the problem is mainly the choice of language.
I agree that there exist many good reasons to make a language self-hosting. Still, I think there also many obvious benefits from using C.
> While it is very difficult to write perfectly safe code in C, this seems to be used as explanation for the amount of CVEs we see. But when I look at the CVEs, the code is often terrible!
Given the choice between a language that requires expert coding for minimal safety guarantees and one which can tolerate human error, I’ll take the latter all else equal. Also, given that experts feel they can’t write correct C reliably, I’m inclined not to think I can (never mind contributors).
> At the same time, the Rust rewrite of coreutils with more than 100 CVEs does not exactly convince me that the problem is mainly the choice of language.
I’m not a Rust fanboy, but I don’t know what I should make of this. Is 100 CVEs a lot for coreutils? If the idea is “Rust doesn’t preclude all CVEs therefore language choice doesn’t matter”, I don’t think that follows.
> Still, I think there also many obvious benefits from using C.
The only I can think of are that the toolchain—but not the compiled programs—-can run on niche hardware (minor benefit), that bootstrapping may be easier, and that the toolchain may be more performant (although Go compiles faster than most C-based toolchains I’ve seen, so I’m inclined to think the language matters less here than the compiler design itself).
> Given the choice between a language that requires expert coding for minimal safety guarantees and one which can tolerate human error, I’ll take the latter all else equal.
Again, I do not believe this is true. One gets a reasonable level of safety with only basic measures even in C. In practice, memory safety is also not even remotely the main issue to worry about, especially when writing a compiler.
> Also, given that experts feel they can’t write correct C reliably, I’m inclined not to think I can (never mind contributors).
It is not easy to write correct code in any language. See the number of CVEs in the Rust rewrite of coreutils or generally the number of issues one also sees in Rust projects (including still memory safety issues.) If at all, this means that the C experts are not naive about it.
> Again, I do not believe this is true. One gets a reasonable level of safety with only basic measures even in C.
Even if you believe this is true and the experts are wrong, other languages don’t require even these “basic levels” to provide a greater degree of safety, so presumably they’re still the better choice if only for this reason (not to mention all the others).
> In practice, memory safety is also not even remotely the main issue to worry about, especially when writing a compiler.
I agree—but those other concerns (e.g., attracting developers) are overwhelmingly reasons not to use C.
> It is not easy to write correct code in any language
Right, but “impossible” and “not easy” are different, right?
> See the number of CVEs in the Rust rewrite of coreutils
How are we supposed to derive anything from this? The 44 Rust rewrite CVEs were the result of a comprehensive professional audit that Canonical paid for and which the coreutils project has never experienced. Moreover the coreutils project predates CVE trackers. If your point is “Rust doesn’t preclude logic errors”, then who are you arguing with?
Many C experts I know would not agree with this. What experts are you quoting?
I do not understand your comment about "impossible" and "not easy". It is not impossible to write correct code but also not easy - in any language.
The audits of Rust uutils which identifies 113 issues in total confirm exactly what I said: It is not easy to write correct code in any language, and also in Rust it is very easy to make stupid errors that can compromise safety and security.
My comment about memory safety was about Rust CVEs in general, not uutils. For example, https://rustsec.org/advisories/ lists more than 20 use-after-frees for 2026.
Self-hosting is a trivial matter if you can roughly map a subset of features of an existing language to your language. Write bootstrap compiler in that language and translator in parallel (as long as you have good AST/LST), run conformance tests on both.
These days with LLM bootstrapping the compiler is a lot like using YACC for the parser. You just point the LLM at your compiler spec, tell it "bootstrap this" and then it does.
True, I’m assuming you’ve already implemented one compiler. You point the ai to that and instruct the ai machine “bootstrap the language using this reference compiler”.
Sort of. You do not have to implement full compiler before starting building the self-hosted one. With LLM it is possible now to write the spec, and at the same time build both reference compiler and translator, validating your design early. No big upfront effort.
You can, but I still feel like you'd want to solidify the behavior in one compiler before bootstrapping it, otherwise you run into the problem https://news.ycombinator.com/item?id=50342830 was talking about.
I would go so far as to say Zig even tries too hard to solve it (although they reused existing technology they already wanted, so it was almost free). You can bootstrap a self-hosted compiler to new environments by porting the source, cross-compiling it, and scp'ing or otherwise downloading it over to the target. And that's if you don't want to just use QEMU to develop it. We already do this exact thing when developing for embedded devices or often any type of aarch64 programs.
As someone who has monkeyed around with the zig compiler, having the bootstrap done made monkeying around way, way more straightforward than when it wasn't around. I will admit I don't know the details and it's possible the QOL improvements that affected me only depended on other things that got solved along the way. But I have been building the stage0 and stage1 compilers to get my first artifact when I bump to the latest.
> Not nothing, but I don't think it's incorrect to say has any more OOP than general purpose languages like Lua or JavaScript in that sense.
IMO, that text is confusing.
“Not nothing” is saying it has some OO features.
“I don't think it's incorrect to say has any more OOP than general purpose languages like Lua or JavaScript in that sense” = I think this language has more OOP than languages like Lua or JavaScript”
So, that more or less says “A, but A”. If so, what’s the “but” about?
I think it needs more negatives. "I don't think it's incorrect to say [it does not have] any more OOP than general purpose languages like Lua or JavaScript in that sense".
I had retyped it a few times trying not to come off as overly negative or a jerk.
> Not nothing, but I don't think it's incorrect to say has any more OOP than general purpose languages like Lua or JavaScript in that sense.
The comment is saying that the language has more OOP than Lua or JavaScript, but it seems like it might have been meant to say the opposite. That, and it appears to be missing a subject (which I assume to be ‘it’ or ‘the language in question’, based on context). So personally I do find it somewhat confusing.
The problem is not the double negative itself, though; it’s more how it’s being used in context here.
Lampshading that you're doing something wrong doesn't make doing the thing less wrong. Hijacking a language post, of all things, to tell people some other completely unrelated project is better is ridiculously uncouth.
How does it free memory? I don't get it. I browsed the docs a bit but didn't find a single reference to deallocation. There's alloc for heap allocation but no free?
In the standard library, there are some allocators with free, so it looks like you’re expected to call those. It is strange that none of the examples seem to cover this, though.
I wish the author has written about the motives behind the language and why someone should choose Copper. We have in fact more programming languages than we actually can use.
Author here. I have written this language for many reasons but I won't detail here, I'll just say it's a lot of fun for me to design a language and write a compiler.
This language is a playground where I constantly add and remove features or try various experiments, so I have no intention to promote it. The only reason I have published it is that I publish an open source text editor written with this language.
After twenty years of evolution, it starts to become stable but not yet, I had recently added some basic option types.
Is anyone doing more with assembler language lately?
I have this crazy idea to do a hail mary codex ralphing session to convert an IoT product to assembler so as to aggressively reduce the flash and ram usage. probably a pipe dream, but if my old mentor could build a diet planner on an 80-byte RAM PIC, galaxy-brained GPT should be able to fit my bloated product down from 1MB flash to 256kB, amiright?
I thought it would be because it looks so Python/Ruby-like, but in the source I don't see anything related to a GC at a glance and it has an allocator interface: https://tibleiz.net/browser.html?path=std&title=Standard%20L... (click on "memory" then "memory-allocator.co")
if every `=` is always a copy of reference, are we losing some "rvalue" optimizations? (I think Stateful Objects / Stateless Objects are basically lvalue / rvalue, respectively) For example, if a struct is small enough, even smaller than a pointer, and we know its address is never taken, wouldn't it be more profitable to just copy by values to avoid another pointer dereference? Furthermore, if only a single struct field (or attribute) is used, wouldn't it be more profitable to just pass that field value instead of passing around the reference to that struct, assuming there is no ABI issue? (the classic scalar replace of aggregate)
I want you to take a look before I add this to my benchmark as it's a fair bit slower than golang. The elf64 backend is not very optimized. Here's the PR with the areas where it falls short: https://github.com/zupat/related_post_gen/pull/598
Or Pascal. Object Pascal systems that can compile to machine-native code have existed for decades, too. Delphi and FreePascal are two of them. Copper looks interesting. It competes in pretty crowded space of languages inspired by other languages that compile to native code and have an object system of some sort. Some of those others are also fairly minimalist.
The end syntax is definitely Ruby-style, but I guess I felt that way just from looking at syntax like var, func, and for x in. It does seem like a mix of the two, but maybe it’s because I’m so used to Python that I noticed the Python-like syntax first. Thanks for pointing that out.
It seems pretty tasteful, but I don't see anything about character sets. How does it support Unicode? What does a string of 16-bit characters represent?
There do seem to be some Unicode constants in the standard library:
This seems to have a lot of potential, but there are important details missing. Hopefully the feedback from this thread will result in those questions getting answered by the author soon.
I think the days of releasing new programming languages is gone, it's like releasing a new punch card format. Humans don't code anymore and so programming language is really a choice LLM's make for you.
What leads you to think that? All the engineers I know always choose the language depending on the project details, scope, their own or team preferences, etc.
They ask Claude or some other model, this is the correct thing to do though, given it has the whole internet of software engineering history trained into its model and can read thousands of articles docs in seconds.
I can supply anecdotal evidence - of all the people I stay in touch with only one person occasionally opens IDE to write code. This transcends from interactive client apps through novel database engines.
AI is undergoing cosmic inflation, we get further apart faster.
This feels like a photographer telling a painter that they're at a massive disadvantage and that no human paints by hand anymore. Meanwhile painters still exist and are probably not particularly upset by how many pictures per second a DSLR can do.
> like someone writing out machine code by hand vs using a compiler back in the day
Programming using a compiler is still the same kind of thing, just in a different language.
This is a silly take. I think you underestimate how talented some programmers can be. I think you also overestimate how far being good at coding will get you. Pre-LLM, the job was maybe 30% coding. So at worst someone who codes by hand is only disadvantaged by a manageable amount.
Quite the contrary: the barrier to rolling your own <anything> was never lower.
As others have proclaimed: what matters is taste. And (perhaps?) a deep understanding of the subject matter. Which may or may not be encoded in formal specifications. But may also include 'fuzzy' domain-specific knowledge that can't be scraped from the web.
> Humans don't code anymore
I do, and I'm far from alone. Whether 'product' gains traction, that's another matter. But you know what? It doesn't matter. If it works for [author], that's enough.
Why? Did mathematics end when pocket calculators became popular? As today, the world initially overreacted (as usual): calculator opponents did warn about dependence, loss of arithmetic skills, and erosion of mathematical understanding. Making an existing exercise easier does not establish that the underlying discipline is in jeopardy.
Even if we accept the premise that humans don’t code anymore, it doesn’t follow that programming languages are not needed - the AI machines are writing more code than humanity has ever produced. So if anything, the need for better languages is more urgent than ever.
I'd like to come up with some constructive comments, but I find everything so inconsistent and alien to me...
For example, variable declarations use the pattern <colon> <type>, as in
But literals follow the opposite syntax, as in The return type of a function is introduced by : in func definitions, but by -> in imported func declarations: Other construct that I find far from my habits: instead of the more obvious (for me): Arguments are passed by ref, not by val. Good luck with recursion!Author here. The language has still many inconsistencies but not these ones.
Import functions is done the same way:
May be the doc is outdated.The multiple declaration is consistent with assignment:
The syntax is unusual compared to many other languages because it just use a simple syntax: The type is prefixed only to resolve literals: It can be useful in generic functions: But to create uninitialized variables I had to keep the syntax:> Import functions is done the same way [...] > May be the doc is outdated.
Same for function types? The docs still list the syntax with "->":
This one is up to date and it's definitely inconsistent, but I could not use ':' in place of '->' without creating an ambiguous grammar. Same for parenthesis in the return type since you can have a comma separated list:
Have you considered the syntax crystal uses i.e. 42_i32 and 42_u8?
It is not possible since you can create new integer types by sub-classing the primitive ones:
I also plan to replace predefined Int64, Int32, ... by generic types Int(64), Int(32), ... LLVM allows any integer size and Copper allows this kind of generic types.The parallel assignment just work mostly like it does in ruby so that doesn't look weird to me (except the need for 'var' in the first place).
Agreed on the rest, though I don't understand what the problem would be with recursion. Is it using reference passing also for primitives like integers?
> Is it using reference passing also for primitives like integers?
That's what I assumed, but honestly I might have misunderstood the docs. This passage is not very clear:
> Copper manipulates only references to objects. Simple data types such as integers must be seen as references to stateless objects (i.e. objects that have no state in memory).
Sounds like they store the integer in the reference itself in that case. Which also is how Ruby does things (though Ruby has to decide what is what at runtime and thus steal a couple of bits off every integer).
Python does that too
Is this not destructuring a tuple?
Agreed.. and what is going on with the `!` syntax? The docs are not exactly clear on the purpose in all cases.
https://tibleiz.net/copper/documentation.html#basic-syntax
I think it's the opposite of & in C++, that is T! is an object, while T is a reference to an object.
Surprisingly, the most irritating nitpick for me is the choice of the file extension — surely that should've been ".cu", not ".co"? If I were developing an e.g. Iron programming language (hypothetically — although perhaps so named a language already exists), I'd pick ".fe" in a heartbeat.
Then again, I'm the kind of person who've chosen $'.\U0001F9CC' (that is, $'.\xF0\x9F\xA7\x8C') for a file extension of my own toy language so...
Unfortunately for Copper in particular, .cu is associated with CUDA (so perhaps that’s why).
And don’t ask what it means in Portuguese.
My first thought
Not a programming language, but Jane Street has (had?) a code review tool called Iron, abbreviated "fe".
https://blog.janestreet.com/code-review-that-isnt-boring/
And they’re not alone — mercurial is hg and the silver searcher is ag.
I like the way you think.
You're appreciated
It’s nice they tried with a more fleshed out exemplar. Polymorphism (“generics”) and interfaces (“OOP”) would have been even better to see, especially across any kind of visibility boundary enforced by the language (packages, and the like.)
Programming to an abstract interface — and in large codebases, enforced visibility controls — represent the middle ground everyone wants, in my experience, between “OOP” and “sir, this is C”.
Subtyping and generics raise the question of whether containers are covariant or contravariant.
Why would that be true?
> Polymorphism (“generics”) and interfaces (“OOP”) would have been even better to see
Yep. Interface-based (true) delegation between objects would be my go-to if it existed.
Yes,
The example definitely shines. Doing something barely non-trivial is great since it gives a feeling for the language. I wish other language introduction pages would take note.
I really like this language introduction.
It does feel like you need some shared understanding with the author about what the interesting parts of a programming language are and what can be left implicit.
Perhaps the author and I have similar intuitions? I guess I also like that isn't pure LLM output style. It was refreshing to see some human work.
a more fleshed out exemplar
What's the difference between an exemplar and an example?
between “OOP” and “sir, this is C”.
That's more templates, ownership and operator overloading.
Polymorphism is not a modern way to program because it introduces dependencies and enormous speed hits from pointer chasing, both of which are corrosive to a good program.
An example is any random instance of something that illustrates a concept. You can load up a document with examples to demonstrate a range of possibilities. An exemplar is the chosen best way to model and explain a concept.
So in a programming text for a new language, one would use examples of things that are strings, or examples of structures one might declare. You might even see examples of multiple ways to solve a problem in code. An exemplar though shows the one best - or at least most recommended - way to do something in the language.
An exemplar is the chosen best way to model and explain a concept.
Why would you use a worse example and how do you know the example you are looking at is the best?
You'd choose something that's less than ideal if you're including multiple examples, because it's unlikely every example is the best one. You might give an example labelled specifically as a bad example. The word exemplar might be more familiar to many English speakers as the form "exemplary".
It can be difficult to know if your example is the exemplar. It can be reasonably assumed that if the creator of the language provides only one example, it at least should be the best one. It is at least the best one in the docs if it's the only one.
They said a 'more fleshed out exemplar' which means that the current exemplar must not be an exemplar.
I suppose that depends on whether by "best example" one means "the best example presented", "the best example extant", or "the best example possible".
As a Crystal fan, really nice syntax. The documentation leaves open several questions:
What is the memory model here? What does it compile to? What makes it 'low level'? Is there a GC? Does it have ABI compatibility with C or a FFI?
Not mine, but I found this to be really interesting as a language created by one person for their own use.
Also really interesting are the author's blog with articles on language design (for example his thoughts on exceptions, and how he added them to his language, then decided against them), and the change log for the language, showing its evolution.
https://tibleiz.net/
https://tibleiz.net/copper/changes.html
I need to put a disclaimer to say that I hate when people hijack a post about foo to talk about bar, but:
> The language is not object oriented but it provides some features to facilitate object oriented designs.
It has classes and implicit `self`. Not nothing, but I don't think it's incorrect to say has any more OOP than general purpose languages like Lua or JavaScript in that sense.
Something like Pony[1] is a more mature and feature rich entry and has a much better OOP story.
All that said: a) I'm sorry for doing the thing I hate when other people do
b) Creating a language is a big undertaking, and it's super cool that they did it
c) I see it seems to already be written in Copper too, which is also very neat!
[1]: https://www.ponylang.io/
OOP is one of the weirdest topics in computer science in that no one can agree on what it means. Even proponents of “OOP” have wildly different ideas about what it means. For some it’s “encapsulation”, for others it’s “inheritance”, for others it’s “message passing”. It seems the glue that binds OOP proponents together is little more than the sequence of letters: O-O-P.
I drank the Elegant Objects[1] koolaid, and recommend the two books (Elegant Objects vol 1 and 2) whole-heartedly to anyone interested in OOP. Pony lang lets you write 95% of the kind of OOP described in the books idiomatically, without any kind of crazy shenanigans.
I think most people today would say encapsulation and message passing are pretty core to the definition of OO and inheritance is largely seen as an anti-pattern.
One thing I really like about Elegant Objects is that it is very palatable to FP enjoyers. Objects must encapsulate state, but they must also be immutable. Good OOP is declarative like good FP. It looks a lot like lisp imo. You're encouraged to code against interfaces instead of using inheritance etc.
[1]: https://www.elegantobjects.org/
Re "c)": No, self-hosting is the biggest temptation, and the worst mistake, for any programming language. It's death to bootstrapping. However, if you do succumb to the temptation to self-host, having a C backend, as Copper does, is probably the best way to handle it.
I've never really understood the opposition to self-hosting.
As long as:
* Your language is the kind of language that suits compiler development.
and
* You support compiling to C or something so that bootstrapping doesn't involve an opaque binary or compiling 30 different git commits in a row.
What are the downsides exactly?
The usual argument is that it is a distraction when you’re designing a language, and it leads to programming languages that are all excellent for writing compilers and parsers, but not particularly good for other things.
Since the majority of programs are not compilers, it might make more sense to focus on interesting things that aren’t relevant to compilers.
Some ideas from the top of my head: async I/O, a great SIMD story, effect systems, robustness systems for long-running processes (I’m only aware of Erlang/Elixir), and many others.
Compilers do exercise some things, like error handling and memory management, but they’re not particularly difficult or interesting in general.
I had a little homebrew CI system, and decided its first use case would be building itself. Seems like an extremely obvious thing to do, right?
The problem happens when you have bugs and test failures. The hoster and hostee look the same, behave the same, and emit the same error messages. So I had unknowingly opted into spending a big chunk of my debugging time being confused and wrong about A) where errors were coming from and B) what they even signified.
Basically, self-hosting too early, before the thing was stable and trustworthy, was a disaster. (It's obvious in retrospect, really, but was still pretty awful at the time.) I tried again later, after everything had stabilized and it was routinely building other projects routinely, and it was fine.
The main objection I used to have was there are infinite things to do when building a programming language, it's already enough to build 1 compiler, you probably shouldn't also build a second as your main stress test of the language.
That said if your languages is for building compilers you'd probably want to do it. Otherwise, basically no one writes compilers, and if they are they're writing them for their own languages in something much more mature than your nascent language. And if the ambient advice is to bootstrap asap, they'll only be using your language for a hot second anyway, so they're the worst users to cater towards.
These days I think all languages should try to do it with an LLM because, why not? That also means bootstrapping a compiler isn't exactly an impressive feat anymore, most new languages are doing it now.
As long as one of the backends is something widely available, I don't see a problem. C is a decent option. LLVM IR is another.
What's the problem with self-hosting? I do imagine it's easier to write a compiler in something like Haskell.
The problems with bootstrapping a self hosted compiler are often greatly overstated.
It's not a "problem", it's just the juice isn't worth the squeeze.
Why is it harder to bootstrap a self-hosted language than it is to bootstrap a language implemented in C, which itself must be bootstrapped?
Bootstrapping is a one-time cost, but implementing the toolchain in C is a cost everyone has to pay every single time they touch the toolchain source.
What additional cost does it have to implement the toolchain in C? I would say there is some benefit in terms of implicit testing to have a compiler self-hosting. But having a toolchain in C also has real benefits.
C is a notoriously difficult language to work in. It has no build system, no module system, an anemic standard library with footguns like null terminated strings, loads of undefined behavior, etc. Moreover, and maybe most importantly, the people developing the language have less opportunity to dogfood it.
I’m sure there are benefits to a C toolchain, but the costs overwhelmingly favor self-hosting for many languages.
We see so much languages being invented, and many of them do active anti-C marketing. But personally, I do not find it difficult to work in and also enjoy it much more than working in many other languages. There are, of course, build systems one can use, they are just not tied to the language - which build systems should not be. I also do not find most UB a problem in practice, many of them can be fixed simply by using the right compiler flags. Some are more difficult to fix, but think the problem is massively exaggerated. One can also use C with a garbage collector, as GCC does (technically it is now C++).
I agree about your dogfooding comment though.
I like working in C too, but if better C developers than me say they can’t use it safely then I’m not going to think that I somehow can.
And even though I like writing C, the build tooling and the lack of modules system and a bunch of other footguns remain. (And say what you will about language-specific build tools, but they work very well for 99% of cases, and the benefits of the entire ecosystem using the same tool are significant).
Moreover, I want contributors to my language, and the reality is that however much I like C, the intersection of people who want to work on my language and people who like writing C is going to be vanishingly small. If my language is C-like (e.g., Zig) then that intersection will likely be much bigger, but as the target language approaches C, the benefit of using C goes to 0.
I think the argument that it is too difficult to write safe C misleading. While it is very difficult to write perfectly safe code in C, this seems to be used as explanation for the amount of CVEs we see. But when I look at the CVEs, the code is often terrible! I recently read a study where the authors observed that most of the projects did not compile without warnings when using GCC's analyzer. At the same time, the Rust rewrite of coreutils with more than 100 CVEs does not exactly convince me that the problem is mainly the choice of language.
I agree that there exist many good reasons to make a language self-hosting. Still, I think there also many obvious benefits from using C.
> While it is very difficult to write perfectly safe code in C, this seems to be used as explanation for the amount of CVEs we see. But when I look at the CVEs, the code is often terrible!
Given the choice between a language that requires expert coding for minimal safety guarantees and one which can tolerate human error, I’ll take the latter all else equal. Also, given that experts feel they can’t write correct C reliably, I’m inclined not to think I can (never mind contributors).
> At the same time, the Rust rewrite of coreutils with more than 100 CVEs does not exactly convince me that the problem is mainly the choice of language.
I’m not a Rust fanboy, but I don’t know what I should make of this. Is 100 CVEs a lot for coreutils? If the idea is “Rust doesn’t preclude all CVEs therefore language choice doesn’t matter”, I don’t think that follows.
> Still, I think there also many obvious benefits from using C.
The only I can think of are that the toolchain—but not the compiled programs—-can run on niche hardware (minor benefit), that bootstrapping may be easier, and that the toolchain may be more performant (although Go compiles faster than most C-based toolchains I’ve seen, so I’m inclined to think the language matters less here than the compiler design itself).
> Given the choice between a language that requires expert coding for minimal safety guarantees and one which can tolerate human error, I’ll take the latter all else equal.
Again, I do not believe this is true. One gets a reasonable level of safety with only basic measures even in C. In practice, memory safety is also not even remotely the main issue to worry about, especially when writing a compiler.
> Also, given that experts feel they can’t write correct C reliably, I’m inclined not to think I can (never mind contributors).
It is not easy to write correct code in any language. See the number of CVEs in the Rust rewrite of coreutils or generally the number of issues one also sees in Rust projects (including still memory safety issues.) If at all, this means that the C experts are not naive about it.
> Again, I do not believe this is true. One gets a reasonable level of safety with only basic measures even in C.
Even if you believe this is true and the experts are wrong, other languages don’t require even these “basic levels” to provide a greater degree of safety, so presumably they’re still the better choice if only for this reason (not to mention all the others).
> In practice, memory safety is also not even remotely the main issue to worry about, especially when writing a compiler.
I agree—but those other concerns (e.g., attracting developers) are overwhelmingly reasons not to use C.
> It is not easy to write correct code in any language
Right, but “impossible” and “not easy” are different, right?
> See the number of CVEs in the Rust rewrite of coreutils
How are we supposed to derive anything from this? The 44 Rust rewrite CVEs were the result of a comprehensive professional audit that Canonical paid for and which the coreutils project has never experienced. Moreover the coreutils project predates CVE trackers. If your point is “Rust doesn’t preclude logic errors”, then who are you arguing with?
> including still memory safety issues
Which of the 45 or so CVEs were memory safety?
Many C experts I know would not agree with this. What experts are you quoting?
I do not understand your comment about "impossible" and "not easy". It is not impossible to write correct code but also not easy - in any language.
The audits of Rust uutils which identifies 113 issues in total confirm exactly what I said: It is not easy to write correct code in any language, and also in Rust it is very easy to make stupid errors that can compromise safety and security.
My comment about memory safety was about Rust CVEs in general, not uutils. For example, https://rustsec.org/advisories/ lists more than 20 use-after-frees for 2026.
Self-hosting is a trivial matter if you can roughly map a subset of features of an existing language to your language. Write bootstrap compiler in that language and translator in parallel (as long as you have good AST/LST), run conformance tests on both.
These days with LLM bootstrapping the compiler is a lot like using YACC for the parser. You just point the LLM at your compiler spec, tell it "bootstrap this" and then it does.
Sort of. Although the process may not look exactly like that unless you have a really good spec.
True, I’m assuming you’ve already implemented one compiler. You point the ai to that and instruct the ai machine “bootstrap the language using this reference compiler”.
Sort of. You do not have to implement full compiler before starting building the self-hosted one. With LLM it is possible now to write the spec, and at the same time build both reference compiler and translator, validating your design early. No big upfront effort.
You can, but I still feel like you'd want to solidify the behavior in one compiler before bootstrapping it, otherwise you run into the problem https://news.ycombinator.com/item?id=50342830 was talking about.
This isn't at all true, as proven especially by Zig.
I would go so far as to say Zig even tries too hard to solve it (although they reused existing technology they already wanted, so it was almost free). You can bootstrap a self-hosted compiler to new environments by porting the source, cross-compiling it, and scp'ing or otherwise downloading it over to the target. And that's if you don't want to just use QEMU to develop it. We already do this exact thing when developing for embedded devices or often any type of aarch64 programs.
As someone who has monkeyed around with the zig compiler, having the bootstrap done made monkeying around way, way more straightforward than when it wasn't around. I will admit I don't know the details and it's possible the QOL improvements that affected me only depended on other things that got solved along the way. But I have been building the stage0 and stage1 compilers to get my first artifact when I bump to the latest.
Since we’re nitpicking: you used a double negative, which is a confusing way of communicating an idea.
The bike shedders have entered the chat.
There's a difference between nitpicking the topic of the article and nitpicking someone's grammar.
To be fair, it really is a confusing way of communicating, and it’s useful feedback when taken to heart.
It's not confusing.
> Not nothing, but I don't think it's incorrect to say has any more OOP than general purpose languages like Lua or JavaScript in that sense.
IMO, that text is confusing.
“Not nothing” is saying it has some OO features.
“I don't think it's incorrect to say has any more OOP than general purpose languages like Lua or JavaScript in that sense” = I think this language has more OOP than languages like Lua or JavaScript”
So, that more or less says “A, but A”. If so, what’s the “but” about?
I think it needs more negatives. "I don't think it's incorrect to say [it does not have] any more OOP than general purpose languages like Lua or JavaScript in that sense".
I had retyped it a few times trying not to come off as overly negative or a jerk.
> Not nothing, but I don't think it's incorrect to say has any more OOP than general purpose languages like Lua or JavaScript in that sense.
The comment is saying that the language has more OOP than Lua or JavaScript, but it seems like it might have been meant to say the opposite. That, and it appears to be missing a subject (which I assume to be ‘it’ or ‘the language in question’, based on context). So personally I do find it somewhat confusing.
The problem is not the double negative itself, though; it’s more how it’s being used in context here.
It was also to me. I also prefer simple clear language, so much for my feedback. Can we now move on?
Lampshading that you're doing something wrong doesn't make doing the thing less wrong. Hijacking a language post, of all things, to tell people some other completely unrelated project is better is ridiculously uncouth.
How does it free memory? I don't get it. I browsed the docs a bit but didn't find a single reference to deallocation. There's alloc for heap allocation but no free?
In the standard library, there are some allocators with free, so it looks like you’re expected to call those. It is strange that none of the examples seem to cover this, though.
I wish the author has written about the motives behind the language and why someone should choose Copper. We have in fact more programming languages than we actually can use.
Author here. I have written this language for many reasons but I won't detail here, I'll just say it's a lot of fun for me to design a language and write a compiler.
This language is a playground where I constantly add and remove features or try various experiments, so I have no intention to promote it. The only reason I have published it is that I publish an open source text editor written with this language.
After twenty years of evolution, it starts to become stable but not yet, I had recently added some basic option types.
It is a personal project, which the author uses for some other personal projects.
Clade - a programming editor with elastic tabstobs and Smalltalk like navigation
Maybe, there is more. Looks to me like an illustration of the "It is a quiet life" meme
Is anyone doing more with assembler language lately?
I have this crazy idea to do a hail mary codex ralphing session to convert an IoT product to assembler so as to aggressively reduce the flash and ram usage. probably a pipe dream, but if my old mentor could build a diet planner on an 80-byte RAM PIC, galaxy-brained GPT should be able to fit my bloated product down from 1MB flash to 256kB, amiright?
Why not have an AI agent super-optimize with a Lean proof of equivalence to your baseline as the "specification"?
So nice to see a low-level language without those pesky semicolons
Really hard to make opinion based on few small examples but I can say I like what I see, Ruby like syntax definitely doesn't hurt language.
Multiple return values are kind of weird, but maybe it is just me. Overall this is something I will give a try.
Garbage collected? Couldn’t tell from the docs.
I thought it would be because it looks so Python/Ruby-like, but in the source I don't see anything related to a GC at a glance and it has an allocator interface: https://tibleiz.net/browser.html?path=std&title=Standard%20L... (click on "memory" then "memory-allocator.co")
if every `=` is always a copy of reference, are we losing some "rvalue" optimizations? (I think Stateful Objects / Stateless Objects are basically lvalue / rvalue, respectively) For example, if a struct is small enough, even smaller than a pointer, and we know its address is never taken, wouldn't it be more profitable to just copy by values to avoid another pointer dereference? Furthermore, if only a single struct field (or attribute) is used, wouldn't it be more profitable to just pass that field value instead of passing around the reference to that struct, assuming there is no ABI issue? (the classic scalar replace of aggregate)
Looks like Crystal to me. But with stronger typing.
https://crystal-lang.org
Neat little language...
Stronger how?
Definitely more explicit by default though.
But yes, very neat. I'd miss Enumerable though, if they manage to get that to play with manual allocation that would be even neater.
I loved Ruby. I've since settled on Kotlin as a good enough "typed Ruby", and a "sufficiently better Java" + the JVM as "good enough for me".
Compiling to native is neat. But productivity (LLM-ability, lib ecosystem, will-still-be-maintained-in-20y) is key for me :)
I want you to take a look before I add this to my benchmark as it's a fair bit slower than golang. The elf64 backend is not very optimized. Here's the PR with the areas where it falls short: https://github.com/zupat/related_post_gen/pull/598
What about binding to external C ABI? I can haz Vulkan?
Seems like Dart with indentation instead of braces.
It doesn’t look like it cares about indentation. It’s more like Basic or Ruby.
Or Pascal. Object Pascal systems that can compile to machine-native code have existed for decades, too. Delphi and FreePascal are two of them. Copper looks interesting. It competes in pretty crowded space of languages inspired by other languages that compile to native code and have an object system of some sort. Some of those others are also fairly minimalist.
Looks nice and small. Too bad it doesn't quite actually build (on Linux). Also, no string interpolation (AFAIC) and no kebab-case.
Here's my current stab at a small compiled language: <https://codeberg.org/stevefolta/lx-2025>.
This might be my new favorite language. Deeply sane.
Exactly
It's a bit like temple os :/
The simplicity is appreciated.
It’s similar to Python syntax.
From the website itself:
> Ruby-style syntax
Also, Python has significant whitespace, which this language does not appear to have.
The end syntax is definitely Ruby-style, but I guess I felt that way just from looking at syntax like var, func, and for x in. It does seem like a mix of the two, but maybe it’s because I’m so used to Python that I noticed the Python-like syntax first. Thanks for pointing that out.
Glad they chose the more sane way of Ruby, regarding whitespace.
"Copper is a programming language that I use as a replacement to C."
That's used... to make what?
Seems for the other public project they've https://tibleiz.net/clade/ and its predecessor https://tibleiz.net/code-browser/.
Seems really interesting
Hmm... Copper, I guess it must be great for representing lists. :-)
I'm excited to see this language. The author has a good track record with Codebrowser/Clade. What I would like to see is the C interoperability story.
polluted the namespace. rust was perfectly named.
oop in 2027 haha
Is it memory safe? Or is it yet another "better C"?
[dead]
[dead]
AI slop
It seems pretty tasteful, but I don't see anything about character sets. How does it support Unicode? What does a string of 16-bit characters represent?
There do seem to be some Unicode constants in the standard library:
https://tibleiz.net/browser.html?path=std&title=Standard%20L...
This seems to have a lot of potential, but there are important details missing. Hopefully the feedback from this thread will result in those questions getting answered by the author soon.
I think the days of releasing new programming languages is gone, it's like releasing a new punch card format. Humans don't code anymore and so programming language is really a choice LLM's make for you.
What leads you to think that? All the engineers I know always choose the language depending on the project details, scope, their own or team preferences, etc.
They ask Claude or some other model, this is the correct thing to do though, given it has the whole internet of software engineering history trained into its model and can read thousands of articles docs in seconds.
> Humans don't code anymore
I find that difficult to believe. Is there some objective evidence?
I can supply anecdotal evidence - of all the people I stay in touch with only one person occasionally opens IDE to write code. This transcends from interactive client apps through novel database engines.
AI is undergoing cosmic inflation, we get further apart faster.
I guess I’m not human
The ones that do are at a massive disadvantage, like someone writing out machine code by hand vs using a compiler back in the day.
Someone who can write assembly will always be at an advantage over someone who can’t. Yes even in the agentic era.
This feels like a photographer telling a painter that they're at a massive disadvantage and that no human paints by hand anymore. Meanwhile painters still exist and are probably not particularly upset by how many pictures per second a DSLR can do.
> like someone writing out machine code by hand vs using a compiler back in the day
Programming using a compiler is still the same kind of thing, just in a different language.
I was a programmer back in the day. That statement is simply misinformed.
This is a silly take. I think you underestimate how talented some programmers can be. I think you also overestimate how far being good at coding will get you. Pre-LLM, the job was maybe 30% coding. So at worst someone who codes by hand is only disadvantaged by a manageable amount.
Quite the contrary: the barrier to rolling your own <anything> was never lower.
As others have proclaimed: what matters is taste. And (perhaps?) a deep understanding of the subject matter. Which may or may not be encoded in formal specifications. But may also include 'fuzzy' domain-specific knowledge that can't be scraped from the web.
> Humans don't code anymore
I do, and I'm far from alone. Whether 'product' gains traction, that's another matter. But you know what? It doesn't matter. If it works for [author], that's enough.
Why? Did mathematics end when pocket calculators became popular? As today, the world initially overreacted (as usual): calculator opponents did warn about dependence, loss of arithmetic skills, and erosion of mathematical understanding. Making an existing exercise easier does not establish that the underlying discipline is in jeopardy.
Even if we accept the premise that humans don’t code anymore, it doesn’t follow that programming languages are not needed - the AI machines are writing more code than humanity has ever produced. So if anything, the need for better languages is more urgent than ever.
"The days of the very thing happening here are gone."
Uh, no.