My dream feature would be for an interpreted language: when you start the program the interpreter would randomly choose one of the keywords in the language to be considered "hot lava", meaning when the program encounters that keyword the computer running the program would be shut down permanently. If this language were universally adopted it would only be a matter of time before all computers were rendered inoperable.

And for society.

I would take SML, freshen it up with some conveniences inspired by Haskell and OCaml, and add a mode with region-based memory management only, so it can be used without a GC. This so there is a simple but principled language targeting low-level programming. Rust is nice, but it has so many features and a syntax aimed at C++/Java folks.

I'm convinced that in 50 years all "general purpose" programming languages will be some sort of ML derivatives. Just looking at the feature sets they keep adding on to existing languages (like for example C# where the language is slowly but surely becoming F#) and that seems to be the direction everything is heading.

At some point everyone realizes that if you want to do things "generally" then you want an ML. And after that we slowly get the surface area of general languages hardening until we don't really see that many new features popping up all the time. Afterwards all the innovation shifts to niche programming languages and DSLs.

I would give your idea a try. I think it's good.

SuccessorML[1], 1ML[2], etc. are pretty close to this in spirit. I've been trying to keep up with the publications around the future of ML, but academic research moves kinda slowly. I'm hopeful we'll see a new definition of Standard ML this decade. I'd tend to agree SML is a great choice -- SML-1997 is still ahead of many languages that came well after it in both features and usability.

[1] https://github.com/SMLFamily/Successor-ML

[2] https://people.mpi-sws.org/~rossberg/1ml/

I'd love a SML with explicit effects system (and yes, I know we can implement a monad system in SML, but there needs to be ecosystem support or I might as well do the same thing in JavaScript or whatever)

Because we can't make people agree whether punctuation or meaningful whitespace is better: I'd like something that you can view and edit in your preferred syntax style. It would be stored in SCM and run/compiled in some intermediate format that losslessly transforms to the "work mode" and back.

It's been a while i'm thinking about one:

A Relational General Purpose Language.

Not table oriented like SQL, but more OOP/Type oriented, I'm not sure exactly how I want it to be, but surely not table oriented.

No concurrency or async to worry about, you write the relations (exactly like you dont worry about SQL on concurrency while writing an SQL query).

Like a JIT/DB Engine, it has a runtime that analyze the data processed, and optimize further the queries. I believe it even could dynamically figure out of embarrassingly parallel problems and sent it to process on the GPU.

But all of this require a lot of work ^^'.

Isn't that LINQ ?

https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

I'm a C# dev, I know well LINQ.

LINQ has multiples issues compared to what I want to do.

It's slow (at leat 1000x slower than a for loop)

There is no query optimizer by default, and even less a runtime query optimiser.

It's directly translated to procedural code, it doesn't get compiled and translated like a query engine will do in an SQL DB.

I’m far from a C# expert, I just happen to write some at work but that’s not my predilection language so you probably know better than me but, implementation appart, as a querying language, it feels pretty good.

Also, I understood that it was translated to IEnumerable queries, so, wouldn’t EF optimize the query ?

EF translate will translate your LINQ into SQL. I'm speaking about LINQ that you may write anywhere, not on a DB call in particular, there EF is not the right tool, there may be some things thats may make LINQ faster, but it's nowhere as good (it cant do much as most of the queries are little isolated queries) as a DB engine.

Not being familiar with LINQ, does it solve SQL's composability problems?

I love SQL for what it can do, but I am constantly annoyed at how inconsistent it is and how terrible it is for generating queries via software. It feels ripe for a replacement that is semantically similar but syntactically different.

LINQ is a library & C# language syntax that call this library thats allow to write SQLish like query on your C# objects.

I'm familiar with what it does (conceptually), but what I want to know is: Is it composable? Eg if I have a query and I want to add an additional filter to it, or I have a select that I want to turn into an update, is it straightforward? SQL syntax tends to make this kind of query generation difficult (though obviously not impossible).

The query is composable, not the object it process (it's still a C# object). A LINQ method return an IEnemurable(this interface allow simply to read the object one per one.)

You can add filters, groups, order, as much as you want, because each will return an IEnumerable (some methods return a child interface, like Order, which return an IOrderedEnumerable).

Then, you consume this this enumerable, most of the time with a foreach (procedural, or LINQ style, and will consume the enumerable), where you can update the values.

In the end, it's still C#: you can add side effects, where you want, even in the select, even if you shouldn't.

Most of the times, "when it tends to make this kind of query difficult" you can just consume your query with a foreach, and do the rest with the procedural style.

D (the Date And Darwen one, not the Walter Bright one)?

https://en.m.wikipedia.org/wiki/D_(data_language_specificati...

Thanks, I didn't knew about D (I did little to no research on other languages yet).

I will read it, but mind that, I said "general purpose" I don't want this to be a language used to be only used as a Database. The whole app should be written in it.

> I will read it, but mind that, I said "general purpose" I don't want this to be a language used to be only used as a Database.

A major point of D is to eliminate the object-relational impedance mismatch and the app language/SQL boundary by providing one language for app and database that is truly relational.

That said, I think most of the implementations (other than as libraries for existing languages, which is kind of a different thing) have ecosystem problems from not being popular, so even if they are “general purpose” languages, there's probably a heavy loft for lots of common tasks compared to languages with richer ecosystems.

Yeah, it still looks too much like SQL to me.

My idea is to make procedural looking code, but is relational all the way. I believe it's possible and would limit the issue a lot of people has with SQL/relational.

Programming Languages initially were called "Higher-Level Programming Languages" to contrast them with the "Low Level Machine Languages" / Assembly. Back then there was an understanding that you can increase productivity by using higher-level languages over low-level languages.

The next leap was LISP Machines and Smalltalk Single Image Systems, where the developer was given a unified vertically-integrated environment further increasing their productivity. Some even called it a "human–computer symbiosis". But unfortunately this approach has not become mainstream, though I worked with some proprietary database systems based on a Single Image System.

Next we had an era of "Application Generators" or "Fourth Generation Programming Languages". They made application developer's job easier and were closer to modern LowCode/NoCode tools.

Modern SDLC is a chaotic collection of different methodologies, practices, techniques, patterns, and tools (the PLs are just one of these tools). They were created in evolutionary way by optimizing for local maximas, and they might missed the global one.

To summarize, IMO what we need is a higher level application development environment supporting all stages of the modern SDLC, not just a new programming language which will solve only the coding part.

4GL - Fourth Generation Languages

also CASE (Computer-Aided Software Engineering) tools

good luck, theaeolist

I'd like a language that, as much as possible, insulated me from async worries. I'm thinking of how garbage collection helps me forget about memory allocations. I don't want to have to pepper my code with 'async' and 'await' hints everywhere. I'd prefer to not have to figure out the syntax incantation for marshaling data across threads. If I'm not mistaken Go is the closest to this?

Couple suggestions:

* Ponylang. Pure Actor model. Static typing to enforce safe concurrent semantics in almost all respects. Plus ORCA GC. Upshot: high performance, and type theory grounded guarantees of no deadlocks, no livelocks, and no data races. Chief downsides are that MS Research has hired its founder, and it's a fledgling language/community.

* Elixir. Kinda Actor modelish. Dynamic typing, solid community. Someone else has posted about it.

* Raku. Someone else has posted about it. Chief downsides are that it's got slow single core performance and small community. Upsides include ease of use for multi core code. `start` schedules a lambda or function or statement on a virtual thread. cf Go's `go`. No `async`.

A small, but growing community, I'd say :-)

Go quite literally has a syntax incantation for marshaling data across threads (channels). The novelty of Go is that it's language-level as opposed to library-level. It's nice, but in practice I don't think it makes a huge amount of difference.

Java also has some basic thread synchronization primitives built into the language. It's way easier than you probably think. And it gets even more interesting with the upcoming project loom, which gives you the same programming model for lightweight and real threads.

Async programming is a pox on the industry. It's very useful in rare situations that require extremely high performance, but for general business processing, function coloring adds a ton of accidental complexity.

You might want to have a look at the Raku Programming Language (https://raku.org). It doesn't parallelize automatically, but only if you hint at it being ok, or if you are explicit (in this case using the `.hyper` method):

The millionth prime number using 1 CPU:

    $ raku -e 'say (1..Inf).grep(*.is-prime).skip(999999).head'
    15485863
    real 0m5.515s

Using whatever CPU cores are available (using `.hyper`):

    $ raku -e 'say (1..Inf).hyper(batch => 10000).grep(*.is-prime).skip(999999).head'
    15485863
    real 0m2.036s

In my experience, Elixir (I haven't used Erlang much, so can't comment on that too) is the first language that removed async concerns. With the lightweight thread approach and message passing, things can get "embarrassingly parallel" very easily.

Raku is closer.

This is a myth, it does not do it automatically.

Everyone will have a laundry list of things they need, depending on their use case. I'd like a general purpose language that fits somewhere near C#, Swift, and go. Similar to, but simpler and higher level than rust. Basically, take rust and sacrifice some of the lower level power for slower, but simpler more concise programs.

- A strong static type system, but not as in-your-face as Rusts. Abstractions must be cheap in runtime, but not so cheap as to come at the price of more complex programs OR SYNTAX. Strong support for things like sum times with exhaustive matching. Generics. No Nulls. Annotations. All the things you expect from a modern language.

- Struct-oriented imperative programming, like Rust. That is: not a functional language, not an OO language, but a focus on imperative and immutable.

- A runtime with a garbage collector, to enable the above.

- Utf8 strings

- A rust like error handling system with catchable panics for "actually exceptional" things, and forced Result/Option types for everything normal.

A programming language that is based on values including values where the components can have references to other components. Such a programming language should also have cursors that point to parts of a value and can be used to modify a part of the value that they belong to. Preferable there should also be transactions on values and values with a (undo/redo) history.

Having a lot of experience with programming in C++. C# and JavaScript, I have found that many 'creepy' bugs are related to the confusion arising from assigning an object to some member, where a copy is intended, or the otherway around, that a copy is made where a reference is intended. I have not yet come across a language where this is solved and have started working on such a language myself: https://github.com/FransFaase/DataLang

I just did. I did not find anything on compound values where the components can have references to other components with in the compound value. Maybe I did not look good enough. I also would like to have integrity requirements on references such as FOREING KEY constraints with cascaded delete in Relational databases. I also would like to have transactions like those in databases.

I am surprised that there are still no software development platforms where you use one language for all levels and do not have to translate between different ways of representing data and interacting with services.

The interesting applications are where multiple agents (people and/or other systems) are working on the same data. The methods to define such forms of cooperation are rather primitive. On one hand you have the databases with their transactions and pessimistic locking approaches. On the other hand you have git repositories with optimistic locking and manual merging. Sometimes you would like to have something in the middle, where you can define which operations conflict (do not commute) and how to deal with them.

>> I am surprised that there are still no software development platforms where you use one language for all levels and do not have to translate between different ways of representing data and interacting with services.

You've spotted a problem that I think many people are blind to. I agree 100%.

If you'd like to explore more about Clojure, I highly recommend this talk https://www.youtube.com/watch?v=ScEPu1cs4l0

Don't support "truthy" or "falsey" values. Any if/while/etc conditions must only have boolean type, causing an error if the value is any other type.

I would like to see an experiment where modules, their properties, and their dependencies are written down in a separate file.

For example, it would tell module main depends on ui, utils and json, ui on graphics (a third party library) utils on encrypt and IO (which are part of the standard library of the language), json on Streams (another part of the standard library).

It also could say graphics doesn’t use reflection, json is thread-safe and O(input size), utils is pure, encrypt is constant-time, and main isn’t restricted in any way.

The compiler would have to enforce both the dependencies (main couldn’t directly call functions in IO, for example) and the properties (if json uses shared state, it somehow must be properly protected with locks/atomics) (this may, in cases, be a research project. Some properties might be better served with a different or more limited language (that’s what dtrace does for its language, to guarantee it won’t loop forever)

That file would serve as documentation. Tools would exist to render it to svg; users would expect their IDE to do that, maybe even in editable form.

Advantage of separating that from the source files would be that it is harder to accidentally change that information. Spotting them in reviews would be trivial, history could be tracked, etc.

Maybe, the compiler could error when compiling a module where the documentation doesn’t say it’s thread-safe, but it still is, but I can see problems with that, too, where implementers don’t want to commit to something, but still do it. Maybe, we need 3-valued properties: “is thread safe”, ”is not thread-safe”, and “doesn’t want to commit to thread-safety”

Advantage of the compiler enforcing the properties is that they would remain true.

Yes, you can bolt a lot of that on top of about any existing language, but the language needs a culture of doing that. I think golang has shown that the design of a language can influence its culture.

As I said: “I would like to see an experiment”. I’m not sure I would really be happy with the results though. What if there’s that one function that logically belongs in encrypt, but can’t be made constant time? Do you really want to create a sister module for that one function?

Compiler-enforced computational complexity would be an interesting part of that experiment. Could be part of the function declaration, for example:

    void constanttime doStuff(vector<whatever> v)

However, it would likely require extensive dedicated support and would necessarily be limited (hello, halting problem!). I could see that working and be useful for common complexity values, e.g. O(n^k), O(log n) etc.

I would love some formal methods baked in, so you can prove your shit works when you want to. Ideally like python and mypy, where you write your code as normal and optionally annotate.

That, or if we assume a few more years of speech recognition gets us to rock solid ASR, then a language designed from the ground up with speech as the input in mind, not the keyboard. I lost my ability to type temporarily, a while ago, and this idea has fascinated me since. I think new kinds of graphical “languages” could become more viable with ASR in mind.

Those, or a language that lets you express pipelines better. My typical pipelines at work involve many programs run on different machines. ETL some data with a spark cluster, save it to “memory” aka S3, train a model on a GPU, save it too, then deploy a service. Imagine if five line ‘main’ function in any program had to be split into five files plus a DAG declaration, and to access the state you had to refer to memory addresses by name. And you had no solid linting/type checking/etc across it. That’s the state of pipelines today.

1. Placing language interop as a high priority via extendible interop framework. Right now if you look for interop chances are you’re only gonna get A—>B bindings (eg Python->Rust), not even A<->B. I’d want something where, for all A,B in the set of supported languages, A<->B interop exists. This ideal language could then have like some glue module to allow that.

2. Extensible reflection system like in Python

3. 1 official package manager only, with virtualenvs, and 1 official language version manager

4. Compilable and transpilable, like Futhark

5. Algebraic algorithm compiler hints: eg string length is a monoid homomorphism, so if I wanted to label ‘len(str)’ as such the compiler would be smart enough give me a parallelized, async version of string length

6. Higher order functions + partial application + lenses as built-ins

7. Really solid debugging tools, including at minimum time travel features and automatic data structure visualization

8. Jupyter notebook support

9. Can compile to wasm

10. Codegen as a first class feature, to go along w the reflection capabilities. Eg if I want to copy one region of code to another location, be able to do so. But also much more sophisticated operations than copy.

11. String diagram editor for composable module diagrams

12. IDE has built in natural language interface but in a non-interfering way. By which I mean, rather than writing the code for me at my cursor in my code editor, let me write the code on the left, and have the computer make a list of the ‘todos’ and function implementations that will need to be tackled next. Keep me in my flow, while helping me prefetch the next task to do.

What exactly virtualenv adds to table that justifies it?

I have used c#, and javascript. And not felt any issues by lack of virtualenv.

I know python need it because otherwise it does not support project level modules. But that is a python only problem

Sure, just for managing the project-level language versions + project-level library dependencies. Doesn’t need to be exactly venv, but venv has proven simple enough to use that it tends to reduce headaches, rather than add more, in my experience.

The reason is that pip/most package managers have a default to install a package globally. Which can be annoying especially for noobs.

This really isn't what you asked for, but I discovered a "programming language" recently, named Enso, that seems like something you'd like. (https://enso.org/)

Looks groovy! Thanks for the heads up

GraalVM/Truffle aims to make high performance multi language interop a reality.

Some ideas...

Language that represent numbers as rationals and always gives you precise calculations (unless you explicitly want to round them up).

Language that can tell apart 1 meter from 1 second (units like in Frink lang).

Language that has various data structures with consistent interface (like Scala) up to and including relational tables and graphs.

That has structural composable declarative query language that can reach into arbitrary nesting of those data structures with features that allow to build indexes to perform those queries efficiently.

That has features for serializing those structures and indexes into files and using them live from disk instead of ram. (why not have 1TB set in my program?).

Language that can pick a data structure or combination of them that provide capabilities you specify. For example if I want a structure that is fast at inserting elements, checking their presence and taking smallest element (with respect to some measure) I should get sorted linked list combined with a set.

  >> Language that represent numbers as rationals

so π would be represented as π/1 or τ/2?

Also wouldn't it make comparisons quite expensive?

I don't mind having option of purely symbolic computation but by default I don't want them.

Instead od Pi I'd prefer to have Pi(3) equal exactly 3.14, or Pi(2) equal exactly 3.1 and so on.

Since numbers would be kept as smallest numerator, denominator pair comparison would be just compaing those.

Haskell has the first four of those features, although it can't directly use the disk or figure out what data structure you'd need.

For the first, Mathematica

1. Match by type name:

Merge the concept of type and variable (name) in simple functions:

To assign a photo to a contact: contact.image = photo

Here both photo and contact act as matching types and as variable identifiers.

2. 'that' lambda filter

files that exist =>

files.each.filter(it.exist) or

files.each.filter(file=>{file.exist})

3. of keyword : reverse properties title of book => book.title

4. indexing with '#'

Colors = [red, green, blue] Color#1 is red

(zero based indexing can still be done via [] if desired

5. universal in-place assignment

Each operator automatically works with assignment: x ⊛= b is always a shorthand for x = x ⊛ b.

6. universal broadcasting

All functions are automatically broadcasting on lists and pair values:

square number := number * number square [1 2 3] == [1 4 9]

https://github.com/pannous/wasp/wiki/inventions

Here's my totally unstructured thoughts on it.

Most programming being done is either DB backed CRUD APIs & UIs.

For the first part, having to write a REST API is mostly repetititve, not same but similar logic.

Some well designed ORMs & automatic wrapper generators get you quite far (compared to hand writing SQL), but the mismatch is still there.

The best backend language will natively work with database. I haven't worked with many technologies in this, but spring data jpa looks like a good initial step to look at.

Second one is UI. Reactivity is the norm but languages are still mostly procedural. Look at all the state management confusion in eg. Flutter.

Svelte is a quite big step here. I think UI language of future should have reactivity built in.

I'd like a systems programming lisp with first-class functions, lexical scoping, and tail recursion optimization: lisps are beautiful and there don't seem to be any well suited for handling binary data.

Javascript under Safari?

Javascript supports first class functions, lexical scoping, and tail recursion.

AFAICT from stackoverflow, the Safari JS engine optimizes tail recursion, while Firefox is apparently working on it.

I think scsh checks all your boxes.

https://scsh.net/

I want a FOSS PL with bloated higher level primitives and APIs, like Wolfram. Think about how having a data frame class (+meta-programming) makes such a big impact in R. I want the same for images, sound, etc.

Racket (https://racket-lang.org) has quite a lot of mathematics support (rationals as ratios, imaginary numbers, exponentiation, implicit integer->float coercion), and comes with a dedicated IDE, although it's a lisp, and I don't know if you'd like that (I certainly do).

This might be out of scope, but I dream of a general purpose programming language to develop web based applications.

I think overall web dev is kind of broken caused by the fact, that we still let web technologies evolve instead of reinventing them. To write a web based application you need several languages, which are furthermore separated in front- and backend.

NodeJs kind of tries to fill the gap, but it’s still just a technology which refers web languages.

I think of a different kind of technology that might not be based on html/css/js + backend-language.

My wish list is a little more pedestrian:

1. High level like python, but strongly typed

2. "normal" c style syntax

3. First class support for "green thread" style concurrency, like erlang

4. First class support for dataframes and the best of python's various ML/data packages.

5. A really great ORM well integrated into the language, that can handle elastic and nosql as well as sql.

6. A batteries included web solution like laravel that handled the common web use cases like auth, a db admin, etc. Bonus points if it's write once for frontend and backend a la svelte.

7. Pretty much just steal cargo for package management.

<clears throat> umm, Go?

Now that Go has generics, it just needs operator overloading to be usable for matrices and ND arrays. :-)

I've always been interested in what programming might look like if it evolved from a non-linguistic base. We tend to assume that having programming using a text-representation is the obvious move but what if a different set of historical/technological priors had led us to build programming abstractions upon something completely different?

Programming languages are abstract syntax trees, not text. They are rendered as text because text is by far the most convenient way to edit, store and cross-reference information.

I don't think there exists any timeline where we don't end up with something we would recognizably call a programming language.

A modern replacement to SQL that doesn't require banging your head against a wall to write anything non-trivial.

If someone would combine the syntax of Ruby (it's fun to read and write) with the performance and static binaries of Go, I think it would be very popular.

I would like to enjoy writing Go as much as I enjoy writing Ruby. But Ruby apps are slow and hard to deploy. Combining their strengths would be great IMHO.

I believe this is what Crystal [0] is trying to achieve. Though I’ve hardly used Ruby or Crystal, so can’t say how well it’s fairing on that goal.

[0] https://github.com/crystal-lang/crystal

Have you heard of https://crystal-lang.org/ ? I've never used it personally, but it seems to be "statically compiled Ruby syntax"

Thanks for the links everyone. I wasn't aware of Crystal. I'll check it out.

Are you talking about Crystal? (Minus the binary part)

Basically q/kdb with types and first class support for stuff like pattern matching and monads (and maybe marginally less terse).

It would need interop with a large subset of existing Python/C libs to ensure adoption.

I would create Ada++ - so that people could use the power of Ada in a syntax more familar to them.

http://adapplang.com/

I want a programming language that can do a lot, from web, game and IoT, with type system like Haskell/TypeScript/Rust/Ocaml and simplicity of Go

To run with part of this: I want a language that can truly do almost everything, everywhere. Start with a FORTH-like base of primitives that can have different implementations (usually assembly, but also, say, JVM bytecode), and then aggressively build a rich language and standard library out from that so most users just see "enable the full standard library and get all the batteries included", embedded folks see "enable the minimal subset of the standard library and it's still a nice language", and porting consists of "implement these 10 functions and the language works, implement these 25 functions and the whole stdlib works". Also, enough community/commercial support that it actually has those parts implemented for everything from ESP32 to AMD64 OpenBSD to aarch64 Linux to Haiku to....

> I want a programming language that can do a lot, from web, game and IoT,

So far, Rust...

> with type system like Haskell/TypeScript/Rust/Ocaml

Still Rust...

> and simplicity of Go

As long as that's ”for similar tasks” and anywhere outside of Go’s particular sweet spots, AFAICT, that's still Rust...

In terms of the languages you listed there, sounds like V to me:

https://vlang.io/

This sounds amazing, why there is no more traction for the language? What are the downsides?

It's not actually a standalone executable (for example, on Linux, it has a dynamic dependency on libc), but everything else about it seems accurate.

This is what Ada does.

A very strong type system, makes native binaries, has low level control, but it writes and reads super simply. Generics are at the module ("package") and function level, not at the type level, and can take other packages as parameters.

I'm curious, how would a language have a type system as complicated as those but also be as simple as go?

Specifically, what does "simplicity of go" mean to you

I'm testing that and Sorbet is very far from being a nice experience right now. Tooling is somewhat broken. srb rbi gems often marks gems as typed ignore, which in turns makes constants unavailable.

My biggest problem is that it's not possible to represent "duck typing" (structural typing), which is core to ruby. So an object that is "callable" (a lambda with no args, a block with no args or an object with call and no args) cannot be represented, since the expectation is that the object includes some interface (module), not that it has a method #call

A statically typed scripting language. TypeScript is probably the best we have here but still brings a lot of baggage over from being based on JavaScript.

I would want a language I can run natively on every platform with the syntax of Swift/Kotlyn.

I'm not sure what you mean - Swift and Kotlin can both do exactly that. Swift works best on macOS, obviously, but it can run fine on Windows and Linux. Kotlin runs on the JVM, so it gets cross-platform support for free.

There is one area that is pretty large when it comes to engineering effort, and that's on the web (currently dominated by JavaScript).

Combine the speed benefits of C++ with the freedom of lisp. I don't think it's possible.

I'm out of date, but compiled LISP doesn't have to be vastly slower than C++. Here they got 2x to 3x: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

"Nim was created to be a language as fast as C, as expressive as Python, and as extensible as Lisp."

https://en.wikipedia.org/wiki/Nim_(programming_language)#Des...

Compiled Common Lisp is fast enough for me.

Faster Python with static types and type inference.

Gods no. No more. We already have hundreds (if not thousands) of programming languages for pretty much every niche out there (not to mention languages so flexible they can be adapted to meet any new niche).

What this kind of question tells me is that folks are tired of solving business cases, and long for technical challenges. There's nothing inherently wrong with this longing, but we have enough programming languages. Pick something else to solve. Please.

> I hope you can humour me and not challenge the assumptions baked into the question. That's a separate, if interesting, exercise.

Challenging and questioning the assumptions behind a question makes for much more interesting fodder than a dozen lists of context-free requirements.

I imagine if this question was asked in 2010 then there would've been a similar answer from someone. And if no new programming languages were created at that point then we wouldn't have gotten Rust.

A sacrifice I'm willing to make if it meant we hadn’t gotten the partially supported pile of dung that is Dart. For every potential gem, there are piles of ossified crap.

EDIT: Plus, Rust’s initial debut was mid-2010, so it would have been a coin flip chance at worst.