[6700417]

This is pretty much the first question I ask every time I see a new language pop up.

The fact is the “language” part of a programming language is the easy part. The hard part is the ecosystem, tooling, mindshare, etc.

If your differentiation is “it’s 35% easier to do task A with my new language vs the next best alternative” then I am afraid you’ve lost me and I suspect most potential users.

The effort involved in learning your new system isn’t going to be amortized out by the benefits unless the benefits are very substantial.

This is coming from someone who really lives to learn new languages and is spending time most everyday working through new problems in new languages out of personal interest. For your average “just wanna get the job done” type you have an even more uphill battle.

Having said all that, it can be a great learning experience to build a new language and it’s always possible you’ll influence changes in preexisting systems that do have an existing user base, so I don’t mean to sound too discouraging to aspiring language designers.

[Silhouette]

The fact is the “language” part of a programming language is the easy part. The hard part is the ecosystem, tooling, mindshare, etc.

This is certainly true, but on the other hand, any new language that will one day be successful needs to start somewhere, or we're going to be writing systems code in bug-ridden C and line-of-business applications in verbose Java forever.

A language where doing day-to-day things would be 35% easier than what I use right now is certainly significantly better, IMHO. It seems to me that to move our industry forward by adopting newer and significantly better languages then a new language probably needs some or all of:

1. easy compatibility with a major existing library ecosystem (a simple FFI to any library with a C interface, for example) or a very comprehensive set of standard libraries out of the box and some tolerable way to integrate with more specialised ones

2. compatibility with existing tools or a decent version of the essential tools of its own (where "essential" today probably means something like build system, package manager, debugger, and maybe profiler, plus usable support in editors and things like version control and diff tools)

3. a compelling use case where it is much better than anything out there today, to act as a starting point for everything else to attach to

4. a core group of initial developers who are interested enough to do things with the language and help develop the above.

[6700417]

Yes, any new language needs to start somewhere, but it’s interesting to think we need new languages for existing domains and that they have any chance of success to begin with.

Consider that by many accounts JavaScript, Java, and Python basically dominate in terms of number of developers and mindshare. These languages all arrived 25-30 years ago. I know some rankings claim C/C++ are far more popular than JavaScript but I just haven’t seen evidence of that in recent years.

Other widely used languages include C, Objective-C, C++, C# and Ruby. The first three are older than the aforementioned languages, and Ruby is from the same era as Java/JavaScript, and C# isn’t far behind that.

In terms of newer languages, the only ones I can think of offhand that seem to have serious traction are Swift and to a lesser extent Go. Some people might throw Kotlin in there, but I’m not sure how much actual traction it’s getting. Rust has been gaining traction slowly for ~8+ years and I’m hopeful it has a bright future but I don’t see a lot of actual projects using it today.

The point is that it’s really hard to succeed if your primary reason to exist is to make existing practice slightly better. It’s very hard to displace any of the existing languages in the space of general purpose programming.

You need to have libraries. You need to have at least syntax coloring support for several editors. You need language server support for VS Code. You need to generate Dwarf. You probably need a repl or website that allows interactively playing around with the language to get people started. You need enough mindshare that teams can actually hire from a pool of candidates once they get a project underway. You need a compiler with good diagnostics, books, StackOverflow answers for the top N questions people will run into, bloggers who are enthusiastic, etc.

Someone posted this on HN recently and I think the speaker does a good job of breaking down the challenges and examining why some languages have found success while others (notably functional languages) have languished on the sidelines:

Why isn’t functional programming the norm? https://www.youtube.com/watch?v=QyJZzq0v7Z4

[greggirwin]

Another way to look at it is that you need a reason for people to use your language, not features. C didn't have tooling to start, JS didn't have an ecosystem, VSCode is only a few years old, so there is the short view, and the long view. It's nice if you live long enough to see your work appreciated, and perhaps even benefit from it. Think true artist versus imitator. Engineers would say "Design for what people think they want, based on what they've seen before, or design for what people need, but they don't know it yet."

Familiarity helps, which is why so many langs follow historical syntactic and semantic rules; and what makes it hard on languages that are either different themselves, or target a niche domain. This includes languages whose paradigm is harder for mere mortals (the vast majority of us) to grasp.

There is also luck and timing. Backing from a big company doesn't hurt, but those langs (Swift and Go) were designed for their owners needs, not everybody else's.

There is a great irony here, which is that many lessons from the past have been forgotten, and ideas which would have help us as developers, and therefore the world, aren't widely used.

Clio doesn't look like my particular cup of tea, but they're trying to solve important problems, and I support them in that.

[Silhouette]

The point is that it’s really hard to succeed if your primary reason to exist is to make existing practice slightly better. It’s very hard to displace any of the existing languages in the space of general purpose programming.

I don't disagree (though FWIW I do disagree with some of the points you mentioned afterwards as "needs").

This is a real problem, though. If we can't manage to adopt a tool that would make us 50% more productive than what we use today, which was the example scenario under discussion, just because of momentum, then our entire industry is going to languish in substandard results forever. We'll continue churning out code that isn't as reliable as it could be and that doesn't perform as well as it could, at vast cost to our ever more technology-dependent society, all because we couldn't get our act together and learn something new.

I am somewhat more optimistic than you seem to be about the viability of doing this. New languages don't magically become popular overnight, but within the past decade or so, we've seen the likes of Go, Rust and Swift become somewhat established, certainly enough to use for real work and build a significant community and ecosystem. In the world of web development, we've seen incremental but very significant changes in JavaScript, but also serious traction for derivatives like TypeScript and significant interest in more specialised tools like Elm.

It's worth noting that in almost all of these cases, there was a "killer application" for the language that did set it apart from what had gone before. Some of them might have become general purpose languages with time, but usually there was some more specific focus at first while they were building up a critical mass of support.

[galfarragem]

Stackoverflow jobs (2019-12-30) tagged as requiring:

kotlin: 161/5224 | go: 148/5224 | swift: 97/5224 | rust: 6/5224

[garritfra]

We discussed the problems with the ecosystems and I think you are right. Clio compiles to JavaScript, so it only makes sense to be 100% interoperable with the npm modules out there. We are currently working on that.