I truly believe you can make cool things in any programming language. If that were the only criteria for language selection, why have any languages at all? Why not simply write programs directly in the machine language of the computer that will run them?
I imagine if you ask ten programmers this question you'll get ten different answers that contain similar rationales in different orders of priority. My answer has certainly changed over time; here's what it is today.
I need a programming language that I can compose in, something that I can learn to use with muscle memory so I don't have to think about the language when I'm making something. For me this rules-out programming in assembly for the most part because in my experience most of the time spent writing assembly is spent with machine documentation, and of course the code is completely machine specific which gets into the second reason I don't simply program in assembly.
My programs need to be portable. With enough practice on a single machine I could probably, eventually, get to the point where I could compose in assembly language, but the programs I create could only be used on the same machine I created them for. This alone makes pure assembly a non-starter for me, but even more damning is the inverse: it makes me non-portable as well. Becoming so proficient in programming one machine in assembly makes my programming ability less portable as well, meaning that when it's time to program a different machine (and it's almost always time to program a different machine) I am for the most part starting over from scratch. I do find this to be fun, but it does make it hard to get things done.
This makes it clear that I need a programming language other than the native assembly/machine language of the computer I'm programming, but many languages meet the basic requirements of composability and portability. So how do I choose?
I used to choose a specific language based on it's technical merits, specifically the merits that are beneficial to the aspects of programming that I find most interesting. Performance, directness, control, parallelism and other features that let me make the most out of the hardware. I also prefer a small language, small enough that I can keep it in my head and build out of those small number of simple parts exactly what I need to make the things I'm working on without a vast number of external dependencies. I don't like a lot of extra features or conveniences and ideally there is one best way to do something. This is what draws me to languages like C and Go and drives me away from languages like C++ and Java.
As an aside, I should mention that I prefer compiled languages over interpreted ones when it comes to building things that last, but I prefer interpreted languages for writing things ad-hoc. I often will experiment with something in a language like Python to see if the idea has legs and if it does will port it to Go if I decide to keep it around.
I've built a lot of things using languages I've selected this way but in the last decade or so the motives behind my language choice have shifted. I now have a better understanding of the relationship between the tools I use and the work I create with them. There is value in the time I invest learning to work with a tool, and thanks to open source it's possible for me to return some value to those who invested in making the tools I depend on. This two-way relationship reveals something important about what tools I chose to invest my time in and how they impact the thing I make with them.
Once I start using a tool (in this case a programming language) to make something durable that durable thing has a fixed relationship to the tool. If the tool has flaws, my work inherits those flaws. I used to think these flaws were simply technical things that could be evaluated mechanically but what I've learned over the years is that those types of flaws are nothing compared to another kind that I don't quite have a word for.
Humans leave their mark on the things we create, and those marks propagate through to whatever we make with those things. It is akin to DNA, and it can traverse generations. "Engineers" will often dispute this, saying things like "it's just a tool", but a real engineer knows that a hammer with a dent in it's face will leave a mark on the steel worked by that hammer, and a hammer that has internal metal fatigue because the CEO of the company that made that hammer valued profit over Quality will break and likely hurt someone. The hammers flaw isn't a technical one, not a limit of the potential of the material or the process it is a choice made by a human that made the tool inferior and in turn makes the things made by the tool inferior or even harmful.
I'm not going to belabor this, others have covered this better than I have. The part that is relevant to language selection is that now one of the first things I consider (maybe the very first thing) when deciding what programming language I'm going to make things with is the people behind the language, because anything of consequence, anything that is going to last, anything that is going to be used by other people is going to inherit the nature of the people who created the language in the first place.
The next thing I look into is where the language is going. The creators might be good people but what about the contributors or the maintainers? Is there anything that prevents a good language from going bad? If the core language is protected what about it's dependencies?
One reason I prefer to write using the fundamental built-in components of a language is to prevent my work from becoming dependent on something I don't trust. Some languages are more prone to dependency explosion than others, and finding a balance between a language with enough built-in functionality to avoid needing external dependencies while at the same time being simple and concise enough to commit to memory is a challenge and I've found very few languages that pull it off.
At this point in my life I want to invest the time I have left working with tools that are made by good people who care about other people and understand how the things they make affect others. I feel so strongly about this that I will simply do everything myself, from scratch when I can't find such a tool to do the job. When it comes to programming languages, I was getting pretty desperate because all of the languages that I've depended on over the course of my life have either become unsupported by the computers I need to work with or ethically compromised. Because of this I've written a lot less software over the last year or so while I try to find a solution to this problem.
I've experimented with doing it all myself, and created a few interesting little projects in the process but what I've learned from doing this isn't that the limitation is my skill or ability but that working in complete isolation is dehumanizing. It makes me feel bad, and it destroys my gumption, and when you're trying to build the entire world from scratch, you need all the gumption you can muster.
But there's something more sinister about doing everything yourself as well. There's no shortage of examples of "lone wolves" in open source, and the result are a lot of things that carry systemic diseases that would have been flushed-out through collaboration. When these creations become essential to others, it creates the exact same sort of problems I tried to explain using the bad hammer analogy above. Humans didn't evolve to live and work alone, and as much as I often feel uncomfortable with other people and collaboration in general, I have to acknowledge this fact. I've gotten slightly better at this lately, and I'm learning that my negative feelings toward collaboration don't come from some essential part of my being but simply from problems I've had with trust and the betrayal of trust in the past. Now that I know this I have something to work on and I'm happy to report that I'm making progress (slow as that may be).
So what does all this have to do with Hare?
Hare came to my attention not because of it's technical merits or because of the composibility of the language. It didn't draw me in because of portability. The first thing I learned about Hare was reading the (human language) writing of one of the project's maintainers about the social problems facing open source communities. The second thing I learned about it was it's LLM policy. After reading this I dug deeper into the contributors to the project, the types of things being written in Hare and the ambitions of both the creators and the people using the language. Only after all of this was my interest piqued enough to make me want to invest the time to try it out. Coincidentally, I also like programming in the language as well.
Nothing about the future is certain, but based on all of this I feel confident that investing my time in learning and making things using the Hare programming language is worthwhile. It feels incredibly good to be able to use something without moral or ethical reservations and I'm excited about the potential of participating in the community that is forming around the language. It's hard to convey this excitement, and I imagine for a lot of people it probably doesn't make a lot of sense (few people I talk to in tech understand why I care about these things in the first place), but knowing that I'm not alone in caring about these things and understanding the harm that comes from not caring has invigorated my passion for programming in a way that has been missing for a long time.
Jason J. Gullickson, 2026