While writing a lexer for some use-case of mine, I realized there's a much better way to handle strings. We can have a single (very simple) consistent rule that can handle strings and multi-line strings:

# Regular strings are supported.
# You can and are encouraged to terminate single-line strings (linter?).
let regular_string = "hello"

# a newline can terminate a string
let newline_terminated_string = "hello

# equivalent to:
# let newline_terminated_string = "hello\n"

# this allows consistent, simple multiline strings
print(
    "My favourite colors are:
    "  Orange
    "  Yellow
    "  Black
)

# equivalent to:
# print("My favourite colors are:\n  Orange\n  Yellow\n  Black\n")

Also, with this syntax you can eliminate an entire error code from your language. unterminated string is no longer a possible error.

Am I missing something or is this a strict improvement over previous attempts at multiline string syntax?

This is just me yapping.

I was thinking for a while about how the field of "writing" software is going through a radical disruptive transformation. Like or hate it, I don't think writing software post-LLM era is gonna be the same as pre-LLM. I'm one of the guys that like to hand craft code and put a lot of attention and intention to the coding style. But, realistically, the skill of writing code by hand, while still very important, will become more and more niche (like how writing and reading assembly is important but very niche).

What's interesting to me, is that programming language design goals were always human/developer centric. Code is not only instructions given to a machine, it is in some way a set of specifications for other human developers, as well as your future self too, that explains the expected behavior of a certain piece of software. The main priorities when designing language features was improving the developer experience, that is a very subjective metric and this is why we keep arguing and debating about programming languages, but I digress.

With the switch to LLM generated code, I feel the priorities might change. There's already a lot of studies on which programming language is best for LLMs. People argue that languages with strong typing, a functional style and good error messages are best, because you can more reliably create autonomous feedback loops that would help LLMs stay on track.

In my opinion, functional programming languages are more relevant than ever, no side effects, you can generate 10K lines of code, read a small 100 lines somewhere, and be sure that it's not affecting the behavior in an unexpected way somewhere else.

The main argument against functional programming is that working with pure functions and manually threading state is an extra burden on the developer; having a mutable state is "initially" more intuitive and simpler to reason about. The other argument is performance, I tend to disagree with this general statement (purity allows for aggressive optimization and implicit parallelization).

However, everyone agrees that functional code is easier to maintain on the long run, it might make small things harder for you first, but at the end there's this payoff. When you have the capabilities of generating thousands of lines of code a day, this becomes way more relevant.

Finally, it would be interesting to witness how the rise of LLMs will affect the design of programming languages. I feel that languages that have

• simpler grammar

• expliciteness

• one way of doing things

• strict and safe semantics

are at an advantage here.

Or do you think that it will be irrelevant. There's this trend of people not looking at the code anymore, I think it's crazy. Maybe generated languages won't be important, just get better models and spend more tokens.

Hey Devs,

I’ve just started my own programming language, and it’s been both incredibly rewarding and challenging. One of the hardest parts has been balancing simplicity with functionality—trying to decide what features to include, how to structure the syntax, and where to draw the line between power and ease of use. But I think I have finally found that balance with an incredible feature that is going to change how we write code.

I’d love to know if anyone else here has tackled building their own language, or even thought about it. What were the biggest challenges you faced? How did you handle things like parsing, compiling, or interpreting? For those who’ve done this before, what do you wish you knew when you started?

Also, I’ve been documenting my progress in a series of dev logs (happy to share in the comments if anyone’s interested), but I’m mainly here to start a discussion and learn from others who’ve ventured down this path.

Looking forward to hearing your thoughts and experiences!

At least from what I've seen. I've never tried it before, but on the surface I'm having a hard time understanding why anyone would not want Rust's safety and Go's simplicity. What are the main criticisms of it and what are the best responses to them?

Someone on Discord mentioned that a few years ago V was lacking in some features that developers wanted, and consequently received some backlash on HN. Another person mentioned that it's mainly because people have invested a lot of time and energy into Rust as being the best possible way, so when they see that V is useful and works, they feel insulted. But like, I've seen interactions on Twitter where it seemed like V was considered taboo by the participants and they (metaphorically) high-fived each other after making a snide remark about it. It's basically a 10x developer in-group marker to crap on V. Neither of the above reasons seem like they justify this, tho -- at least, not to me.

Seriously, it's one of these things that will turn me away from your language.

Files are an implementation detail, I should not care about where source is stored on the filesystem to use it.

• First of all, file-based imports mean every source file in a project will have 5-20 imports at the top which don't add absolutely nothing to the experience of writing code. When I'm writing a program, I'm obviously gonna use the functions and objects I define in some file in other files. You are not helping me by hiding these definitions unless I explicitly import them dozens and dozens of times across my project. Moreover, it promotes bad practices like naming different things the same because "you can choose which one to import".

• Second, any refactoring becomes way more tedious. I move a file from one folder to another and now every reference to it is broken and I have to manually fix it. I want to reach some file and I have to do things like "../../../some_file.terriblelang". Adding a root folder kinda solves this last part but not really, because people can (and will) do imports relative to the folder that file is in, and these imports will break when that file gets moved.

• Third, imports should be relevant. If I'm under the module "myGame" and I need to use the physics system, then I want to import "myGame.physics". Now the text editor can start suggesting me things that exist in that module. If I want to do JSON stuff I want to import "std.json" or whatever and have all the JSON tools available. By using files, you are forcing me to either write a long-ass file with thousands of lines so everything can be imported at once, or you are just transforming modules into items that contain a single item each, which is extremely pointless and not what a module is. To top this off, if I'm working inside the "myGame.physics" module, then I don't want to need imports for things that are part of that module.

• Fourth, fuck that import bullshit as bs bullshit. Bullshit is bullshit, and I want it to be called bullshit everywhere I look. I don't want to find the name sometimes, an acronym other times, its components imported directly other times... fuck it. Languages that don't let you do the same thing in different ways when you don't win nothing out of it are better.

• Fifth, you don't need imports to hide helper functions and stuff that shouldn't be seen from the outside. You can achieve that by simply adding a "local" or "file" keyword that means that function or whatever won't be available from anywhere else.

• Sixth, it's outright revolting to see a 700-character long "import {a, b, d, f, h, n, ñ, ń, o, ø, õ, ö, ò, ó, ẃ, œ, ∑, ®, 万岁毛主席 } from "../../some_file.terriblelang". For fuck's sake, what a waste of characters. What does this add? It's usually imported automatically by the IDE, and it's not like you need to read a long list of imports excruciatingly mentioning every single thing from the outside you are using to understand the rest of the code. What's even worse, you'll probably import names you end up not using and you'll end up with a bunch of unused imports.

• Seventh, if you really want to import just one function or whatever, it's not like a decent module system will stop you. Even if you use modules, nothing stops you from importing "myGame.physics.RigidBody" specifically.

Also: don't even dare to have both imports and modules as different things. ffs at that point your import system could be a new language altogether.

File-based imports are a lazy way to pass the duty of assembling the program pieces to the programmer. When I'm writing code, I want to deal with what I'm writing, I don't want to tell the compiler / interpreter how it has to do its job. When I'm using a language with file-imports, it feels like I have to spend a bunch of time and effort telling the compiler where to get each item from. The fact that most of that job is usually done by the IDE itself proves how pointless it is. If writing "RigidBody" will make the IDE find where that name is defined and import it automatically when I press enter, then that entire job adds nothing.

Finally: I find it ok if the module system resembles the file structure of the project. I'm perfectly fine with Java forcing packages to reflect folders - but please make importing work like C#, they got this part completely right.

To start, I want to clarify that I absolutely think optional types are better than NULL pointers. I'm absolutely not asserting that NULL pointers are a good thing. What I am asserting is that the level of hatred for them is unwarranted and is even pushed to absurdity sometimes.

With every other data type in nearly every language, regardless of whether the language does or does not have pointers that can be NULL, there is an explicit or implicit "zero-value" for that data type. For example, a string that hasn't been given an explicit value is usually "", or integers are usually 0 by default, etc. Even in low level languages, if you return an integer from a function that had an error, you're going to return a "zero-value" like 0 or -1 in the event of an error. This is completely normal and expected behavior. (Again, not asserting that this is "ideal" semantically, but it clearly gets the job done). But for some reason, a "zero-value" of NULL for an invalid pointer is seen as barbaric and unsafe.

For some reason, when it comes to pointers having a "zero-value" of NULL everyone loses their minds. It's been described as a billion dollar mistake. My question is why? I've written a lot of C, and I won't deny that it does come up to bite you, I still don't understand the hatred. It doesn't happen any more often than invalid inputs from any other data type.

No one complains when a python function returns "" if there's an error. No one complains if a C function returns -1. This is normal behavior when invalid inputs are given to a language that doesn't have advanced error handling like Rust. However, seeing people discuss them you'd think anyone who doesn't use Rust is a caveman for allowing NULL pointers to exist in their programming languages.

As if this post wasn't controversial enough, I'm going to assert something else even more controversial: The level Rust goes to in order to prevent NULL pointers is ridiculously over the top for the majority of cases that NULL pointers are encountered. It would be considered ridiculous to expect an entire programming language and compiler to sanitize your entire program for empty strings. Or to sanitize the entire program to prevent 0 from being returned as an integer. But for some reason people expect this level of sanitization for pointer types.

Again, I don't think it's a bad thing to not want NULL pointers. It does make sense in some contexts where safety is absolutely required, like an operating system kernel, or embedded systems, but outside of that it seems the level of hatred is extreme, and many things are blamed on NULL pointers that actually are flaws with language semantics rather than the NULL pointers themselves.

Rust is a clear winner in the AI era. However, it doesn't feel functional enough to spark joy.

Swift is slightly better, but still, is there anything like Haskell, SML or OCaml using reference counting and lifecycle management instead of a GC?

Historically, companies built custom languages to fit their exact project needs. Today, giants like Google and Apple build great general purpose languages like Go, Dart, and Swift, but for their complex internal systems, they still rely on bloated C++ workarounds. They use heavy templating, codegen and dirty macros.

Instead of wrestling with messy metaprogramming, imagine working in a codebase where domain specific needs are implemented perfectly and feel like first class features. You could write frontend code, backend code, and database queries (even write them imperatively) in a single codebase without duplicated schemas or raw HTTP strings.

Consider these three examples of what a highly tailored language could do.

First, builtin memory persistence without having to write serialization/deserialization or disk io procedures:

#persist
GameConfig config = #load "config.bin";

| later in the code
config.mouse.sens_x = 1.5;
#save config; | directly saves struct to a local binary file

Second, deep compiler aware logging:

#log config; 
| automatically pretty prints the variable in detail
| structs have each field listed, strings use repr()-style representation, etc

Third, native frontend + backend + DB imperative RPCs + DB structures + routing all in the same code shareds by all 3 actors (client, web server, db server):

import fullstack

| client code
#client_entrypoint
    | directly calls api in binary format, no interface has to be written
    webserver.get_dashboard_info()

| web server and db server merged
| handles auth via web server, fetches data via db rpc, returns to client.
#auth_api
#db_rpc
get_dashboard_info(db DbInstance, u UserID) List[Project]
    return db.users[auth].projects

| shared data models
#Root
    users Map[UserID, User]

UserID u64
User
    projects List[Project]
  
Project
    name str
    documents List[DocumentID]
    | values are validated in debug builds, zero overhead in release
    ram_usage Percentage

These features can be accomplished in two different ways.

Approach 1: Moddable Plugin Compiler You build a general purpose language (or write a custom C compiler). The compiler has to be written with an easy to use plugin system allowing developers to hook directly into lexing, parsing, semantic analysis, and code generation (or add step inbetween). You trigger these plugins simply by using custom syntax constructs like the tags shown in the examples above (#function_name(args) or @ in C since it's an unused character in the standard).

Approach 2: Domain specific language You skip the plugin system entirely. You might even skip advanced features like hygenic generics. Instead, you just hardcode your exact requirements directly into the compiler of a domain specific language (For example you have List, Array and Map as builtins + all other generic base structs you need such as BTrees).

Which way is more convenient? It depends entirely on your goals probably.

If you are building a language for a companies, the moddable plugin compiler should be the way to go. It gives the community the power to easily extend the language to fit their own unique needs like no other metaprogramming approach can; maybe even profit from it (companies may ask you to write plugins for their niche features?).

But if you are a company trying to solve a specific engineering bottleneck, building a hardcoded internal language is much more practical. It is significantly faster to develop a minimalist language that does exactly what you need without worrying about abstract architecture or supporting a generic plugin system. I would gladly trade standard features for a lean language hardcoded to perfectly support my project.

Since big tech companies have the resources and already build massive general purpose languages anyway, why do they force their developers to use ugly bolted on solutions instead of building clean internal languages?

If you had to choose, which way would you choose? And any other feedback on what I said beyong the questions i asked?

All my replies and the original contents of this OP have been withdrawn. They were a complete waste of time.

From what I can gather, everybody is happy with poor syntax in their languages, nobody is interested in 'clean'.

Someone posted, with a dozen upvotes:

Your example is optimized to your language's special capabilities.

I replied:

"No, pretty much everything in my syntax is cleaner than the C equivalent."

That got multiple downvotes for stating a fact.

There was also this:

For your own toy language by all means use your own syntax

This reinforces my original implication that simple syntax is only suited for toy languages, and not serious ones.

However too much of this was about my language, but that was only an example. There seems to be much irrational distrust of clear syntax for any language.

Maybe, clear code is associated with older languages which no one likes anymore?

(Original examples.)

0.4.1 is up https://bolinlang.com/

It's a boring release. For the most part, all we did was improve error messages, refactored code and improved inlining

TLDR:

What do you think about replacing SQL queries with WASM binaries? Something like ORM code that gets compiled and shipped to the DB for querying. It loses the declarative aspect of SQL, in exchange for more power: for example it supports multithreaded queries out of the box.

Context:

I'm building a multimodel database on top of io_uring and the NVMe API, and I'm struggling a bit with implementing a query planner. This week I tried an experiment which started as WASM UDFs (something like this) but now it's evolving in something much bigger.

About WASM:

Many people see WASM as a way to run native code in the browser, but it is very reductive. The creator of docker said that WASM could replace container technology, and at the beginning I saw it as an hyperbole but now I totally agree.

WASM is a microVM technology done right, with blazing fast execution and startup: faster than containers but with the same interfaces, safe as a VM.

Envisioned approach:

• In my database compute is decoupled from storage, so a query simply need to find a free compute slot to run

• The user sends an imperative query written in Rust/Go/C/Python/...

• The database exposes concepts like indexes and joins through a library, like an ORM

• The query can either optimized and stored as a binary, or executed on the fly

• Queries can be refactored for performance very much like a query planner can manipulate an SQL query

• Queries can be multithreaded (with a divide-et-impera approach), asynchronous or synchronous in stages

• Synchronous in stages means that the query will not run until the data is ready. For example I could fetch the data in the first stage, then transform it in a second stage. Here you can mix SQL and WASM

Bunch of crazy ideas, but it seems like a very powerful technique

To me var is more clear

https://www.youtube.com/watch?v=5XnYNEhViuc

Abstract: Two critical and interrelated questions regarding the design and study of programming languages are: 1) What does it mean to design a programming language? and 2) Why does minimal demographic diversity persist in the programming language community?

previous discussion on the paper here

https://www.reddit.com/r/ProgrammingLanguages/comments/1gaymru/a_case_for_feminism_in_programming_language/

Aria exists because writing languages is fun, and because there is still a place for a scripting language aimed at systems developers. Someone once described it as "a scripting language for people who hate JavaScript", which is not entirely wrong.

More seriously: Aria aims to feel high-level and productive without giving up the guarantees that matter:

• No implicit nulls. Eliminates the billion-dollar mistake

• *Algebraic data types + pattern matching.*Explicit, structured control flow

• Memory safety. The VM is written in Rust

• Composition over inheritance. Object-based programming without class hierarchies

If you are interested in contributing to a real, actively developed VM and compiler, Aria has already cleared the early hurdles: networking, JSON, filesystem access, modules, and more are in place.

At the same time, the project is young enough that you can still expect to find substantial problems to solve at every level: the VM, the compiler, the core language, the standard library, and the package ecosystem.

If you are curious, you can explore the website, check out the code on Github, or join the Discord.

Hey, have you ever thought that `add` and `+` are just different names for the "same" thing?

In programming...not so much. Why is that?

Why there is always `1 + 2` or `add(1, 2)`, but never `+(1,2)` or `1 add 2`. And absolutely never `1 plus 2`? Why are programming languages like this?

Why there is this "duality of identifiers"?

It's usefull to be able to play in the browser for example nodejs webcontainer has been very welcomed Introducing WebContainers: Run Node.js natively in your browser (stackblitz.com)

Setting up nodejs locally is a pain in the ass all the more for new programming language. So would be great if you think about having a wasm version for the browser.

Pls start giving languages etc. names which one can actually search for nicely 😔 rust, python, java, go, lets not talk about the worst..c, a one letter..

One can understand older ones like c perhaps because maybe people didn't think about searching the web for relevant info, but a search will also Need to be tuned to remove c++ and c# etc. Maybe fortran and cobol got it right by chance , but today I saw april being anounced.