The Axiom language is heavily opinionated, so a lot of these features may seem like downsides in other languages. However, each of these features is deliberate. In general, Axiom offers one way to do things rather than giving options. This helps enforce best practices, reduces cognitive load on the programmer, and helps maintain consistency when sharing code.

No unnecessary syntax

There is no unnecessary syntax like semicolons in C++/Java/Javascript or colons in Python. Unnecessary syntax is a frequent source of errors for programmers of all levels, and even though such errors are easy to fix, they represent a persistent productivity drain. You might say that unnecessary syntax is a feature, in that it lets you put multiple statements in one line or minify code, but because Axiom is focused on code clarity, those things are considered detriments.

Significant whitespace

Like Python, whitespace is used for indicating blocks. This reduces the need for braces (like C++/Javascript) or "end" (like Ruby). Unlike Python, only tabs are allowed. This finally ends the tabs vs spaces debate.

Weak/duck typing

Like other high-level languages (Python/Javascript), Axiom supports weak/duck typing. Like Python (but unlike Javascript), no type/scope specifiers are required. Like Javascript (but unlike Python), types are automatically converted as needed, instead of erring out.

Objects are maps

Like Javascript, all instances of classes (objects) are also associative arrays (maps). However, unlike Javascript, Axiom has proper classes. In addition, unlike Javascript, functions, arrays, and strings are not objects. This avoids all the hacks needed in Javascript like hasOwnProperty() and prototype chains.

Specifically, objects are simply maps with with the "_class" attribute set, which allows the engine to find the proper context when calling methods.

Having a limited set of types (null, number, boolean, string, array, object) simplifies the language and reduces nuances, which makes the language easier to learn and use.

No advanced/esoteric syntax

There are no annotations, decorators, spreads, comprehensions, lambdas, closures, generators, iterators, promises, observables, effects, etc. If you don't know what those are, you don't need to. They are just programmer constructs that are designed to hide/compress code, and often make code much more mysterious, complex, and harder to debug. Because Axiom is designed for simplicity and clarity, it will never support those things. At their worst, advanced/esoteric syntax is often used to cover poor design, which only exacerbates the problem and leads to technical debt.

No convoluting syntax

Axiom does not have exceptions, inheritance, or gotos. I consider all of these to be "convoluting", meaning that they are able to escape traditional block syntax and jump to un-obvious places in the code. Gotos are a way to escape multiple blocks without using break, exceptions are a way to escape multiple blocks without using return, and inheritance is a way to invisibly call/reference code from any other block in the hierarchy (not just outer blocks). All these features lead to spaghetti code, because they cause the flow of execution to jump around without any obvious indicators as to where it will go.

Again, Axiom is designed to be simple and clear, and convoluting syntax is the opposite of that. Exceptions are often confusing for beginners and often lead to extraneous code such as writing "throws Exception" everywhere in Java or "try/catch/except" everywhere in Python/Javascript.

Inheritance is problematic and is implemented differently in every language. For example, C++ allows multiple inheritance, Java allows only single inheritance but multiple interfaces, and Javascript uses prototype chains. This is an indicator, to me at least, that inheritance is not a very well-thought-out idea. It is often misused or used as a crutch in place of a missing language feature. For example, languages without duck typing use inheritance to force multiple objects into the same collection. Often times there is a better design pattern that can be used in place of inheritance:

Remote imports

Most languages use a package manager, such as pip for Python, maven for Java, or npm for NodeJS, in order to download code from the Internet and store it to a local cache, because the language itself does not support such code sharing. However, Axiom lets you import code from anywhere on the web simply by passing a url to import(), similar to Deno. This removes the need for a separate package manager or centralized hosting service owned by one entity. Remote imports are cached locally in the folder ".axiom".

Native threads

For some reason, many high-level programming languages have trouble supporting native threads. Python famously has a "global interpreter lock" that effectively prevents Python code from executing in parallel, NodeJS is just starting to have web workers, and it took years for Java to switch from green to native threads. However, Axiom supports native threads out of the box. Like C++, it is the programmer's responsibility to lock code properly in order to prevent crashes.

Native function calls

Also called a native interface or "foreign function interface" (although kind of a weird name, because the foreign function to a foreign language is often just a native function), this is similar to ffi in MJS, ctypes in Python, and is famously missing from NodeJS as one of the creator's biggest regrets. This allows you to link with external libraries very easily and call native functions without having to do anything special (like write your native code in a certain way or recompile anything).

Mutable strings

This is kind of minor but many high-level languages (Python, Java, Javascript) do not support mutable strings for some reason. This means that to change a single character in a string, a new string needs to be created. However, Axiom supports mutable strings so, changing a single character is as simple as "s[1] = 'a'", for example (just like C++).