Discussion on: If you were designing a programming language what would your favourite features be?

[Austin S. Hemmelgarn]

I'd probably include generics and extension methods as native functionality, along with:

Decorators

Functions that take another function or class as input, mutate it, and then return the result, together with concise syntax for invoking this as part of the definition of a function or class. Typical syntax in languages that implement them looks like:

@decorator2
@decorator1
function doSomething():
    return 4

They're a remarkably useful meta-programming tool (for example, you can implement the concept of mixins as decorators), and having a clear syntax similar to what's used in Python 9and recently added to JavaScript) means that they're easier to work with in version-control than just calling the relevant functions as part of the declaration.

Exception type matching as an implicit part of try/catch clauses.

In essence, I despise languages that make you write code that looks like this:

try {
    doSomething()
} catch (error) {
    if (error instanceof SomeErrorType) {
        handleError(error)
    } else {
        throw error
    }
}

I much prefer the Python approach to this type of thing:

try:
    doSomething()
except SomeErrorType as error:
    handleError(error)

No need to re-throw the error if you can't handle it, and no extraneous conditionals to clutter the code.

Object property accessors as a native language feature

Not many OOP languages lack this feature these days, but I feel it's just too important to not mention as something a language should have. Put simply, sometimes you just need to make it opaque to the outside world that some attribute of some object in your API isn't just a value, but gets computed when you read from it or does extra stuff when you write to it.

Native concurrency support

Probably done similar to how Go handles things (native coroutine support, but it automatically spreads things out across multiple threads at runtime, with the number of threads chosen by default based on the numer of thread's of execution on the system it's running on). I would likely add regular multi-process and multi-thread support as well, but as part of the standard library instead of a native language feature.

Coupled with sane messaging primitives as a native language feature, this could trivially replace any need for Promises and async/await type functionality (in the places where having Promises be used even makes sense that is, some things they get used for in JS and the Web API's are just ridiculous, and could just as easily be synchronous if it weren't for the stupid execution model used in JS).

List/Set/Mapping comprehensions

Quick Wikipedia link.

Essentially, a concise syntax to perform some of the same type of things that map, reduce, and filter do, without needing even a lambda/anonymous function to do it.

A native Set type

I don't often need to make use of set theory constructs in programming, but there are just some things where it makes life so much easier. Having a native Set type makes handling those cases much simpler from the programmer's perspective.

---

As far as the other stuff you mentioned:

• Arrow Functions: The shorthand is nice, but the big reason they exist is the insanity that is this in JavaScript. No sane language should have bindings work like that. Without that, you can just use whatever lambda expression syntax you like (and I feel that there are better syntaxes than an arrow operator that might be confused for comparison).
• Async/await: Covered above. I really just don't like the way it works in JavaScript (it really just says "I'm not dealing with async crap here, whoever called me can deal with it.").
• LINQ: The concept is nice, but isn't something I think needs to be native to the language itself. I would probably do something equivalent in the standard library, but not in the core language.
• Attributes: Trivially covered by decorators.
• Database migrations: Should be part of whatever specific database library you're interacting with. Short of possibly providing native ODBC-type functionality, I would not be including database support as a core language feature (though I'd probably have some form of it in the standard library), and thus would not need schema migration support to be a core language feature.

[Dan Silcox]

Ah how could I miss decorators! First came across these in typescript, writing angular. Thanks for the well thought out and balanced input!