With so many programming languages around looking very similar, and realising the enourmous tough challenge to get adoption: why do programmers pursue writing a general purpose language and trying to have it adopted?
A huge problem with this approach is that very few general purpose languages reach the point where they have big standard libraries, great external libraries and tools on top of them. Every time someone invents a new language it wipes away the decades of progress of the general purpose language that could be used instead, so it needs to have a massive advantage or be completely necessary.
Yes, I believe it is folly to try to build a "general purpose" language these days. It's just too much work to clear the bar for adoption (i.e. what do you offer that C/C++/Java/C#/Python/Ruby/JS don't). A language could be great in many ways, but as you say, you have to be able to solve problems you can't solve otherwise with it.
It seems like most newer languages that see some adoption have a solid niche, like Erlang/Elixir, Julia, or Elm.
Why not make the language at least very similar to an existing language? Sure, even if it isnt EXACTLY the same, it at least has a number of people that already write in it, editors that deal with it correctly, etc. Plus you can use general purpose code snippits from such a language, which will help greatly decrease the amount of libraries you will need to make directly before this becomes useful to people.
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.
It points out that we don't need more and more computer languages that no one uses. If you can come up with a language that really makes new contributions or really works better than the existing ones, great, but instead it seems we just have a bunch of me-too languages doing almost the same thing. Languages aren't useful unless there's a critical mass of people developing them, making libraries for them, making good compilers for them, and providing mindshare for them, so that there's enough people competent in them to use them. This is why languages like C and C++ are still used even though there are many valid criticisms of them and supposedly superior alternatives have been developed: the alternatives just haven't been good enough, in many/most cases, to justify switching. C++ may have its warts, for instance, but with all the libraries that exist for it and all the existing code and all the workers familiar with it, it usually makes sense to stick with it rather than switch to something like D or Rust or Swift or Go unless you have a really good reason (like you're developing on iOS where Swift is really well-supported).
These days, Python is the de-facto standard for general-purpose type-optional programming, and has a huge amount of libraries and mindshare, and is growing. So why do we need a clone?
Because implementing a new language and getting it to wide adoption is an enormously challenging task, with a much lower success rate than e.g. SV startups.
Languages that try to implement one new bright idea don't go anywhere, because that's not enough to cause people to switch. At best they serve as examples for feature adoption in other languages.
Look at Rust for example: it seems to be succeeding and gaining adoption, but right now it's still relatively niche (check the number of Rust job postings), and it's taken 17 years to get to this point, with sponsorship from major organizations like Mozilla.
Given this, the idea that there's much low-hanging fruit that's being ignored, that could easily be exploited, seems dubious. What's an example of what you have in mind?
Bespoke languages are always a hard sell for this reason. You really have to support SDKs in the main languages people use.
I will never understand why something like this cannot be just a library. They'll make their claims and pleas, but general purpose languages are general purpose languages and can do anything
So, i'm the closest thing to Chris's counterpart in language land (I own all of Google's production and cloud programming languages, including Go). We also go way back to nearly the beginning of llvm days.
Chris and I certainly talked about this.
I guess i don't really understand why anyone would think this is surprising. Like, i understand the knee jerk reaction, but I guess i don't understand why i would try to force him to do something else.
Chris is a high level engineer who decided he wanted to prototype and build a system in a language he's familiar with and feels is a good match for his problem space. People generally agree it's a good match for his problem space and his familiarity/etc makes him more effective in getting things done there. This doesn't mean anything else is a bad match (general purpose languages are often good at multiple use cases, hence the reason they are considered general purpose)
Why would I try to stop him and force him to use another language?
What tangible benefit would such a thing bring Google?
It's not like Google is a bunch of language zealots who think everything must be written in language X - it already supports a number of production languages, because different languages tend to have different tradeoffs for different use cases.
Outside of that framing, i have trouble thinking of a sane goal that would be served by trying to force him to do it in a different language.
Well, kind of. But in practice, you have to agree that even theoretically "general purpose languages" either fall or get pushed into niches.
For example, Ruby. In real life, mass usage, Ruby is at this point a 1-trick pony, web apps with Rails. While Rails was the rage, it tried and did break out into DevOps, but all those efforts have kind of fallen by the wayside (Chef - a shame, really, Puppet, etc).
Another example, Rust is a general programming language, but few people will actually use it for Line of Business GUI apps, for example. It's just too hard to get started with it and there's no point, you gain too little from its advantages to work so hard through that learning curve.
Same thing for Java and C#. Most companies that will hire you to write something in those languages will probably do it for backend services, plus Java Android apps because Google chose it for that (and then chose Kotlin) and C# Windows apps (but how many people are really writing those these days?). For Go almost everything I've seen is also for backend services.
So in day-to-day life they are direct competitors. Kudos to Go that it got this far and we're putting it into the same league with Java and C#, it's quite an achievement!
I do agree with your principle but in practice most projects are brownfield and your tools have already been chosen by someone else :-)
1. Might happen occasionally but rarely would anyone adopt a vanity language
2. Nope
3. Lol this is just a rehash of 1.
4. Languages can’t be licensed, compilers can. And that’s why we often have multiple different compilers.
5. Now you’re getting close.
The actual reason is:
Trying to solve a different problem
Believe it or not, problems can vary massively from one field of IT to another. Some require low level hardware access, some need mathematical compatibility, others might be optimised for text parsing, and sometimes you just care about developer throughput. There’s macro scripting, web development, games development, server side software, OS development, and firmware. And entire industries using their own specialist tools that most people don’t even know about unless you happen to already work in it.
Some languages are designed to be bullet proof and used in aviation or other domains where failure isn’t an option, some are the electronic equivalent of duct tape designed to allow people to quickly stick operations together.
Programming is such a massive industry that you need different languages for different problems.
I could think of two possibilities off the top of my head:
1. It’s easier to find developers who are skilled in the more popular languages.
2. Using a language is more than just its syntax and semantics; the ecosystem of tools and libraries for the language matters a lot, especially for commercial development. Interoperability between the language’s infrastructure and the desired platform the system needs to run on or interact with is also key.
I work in machine learning. I’d love to use Common Lisp or a statically-typed functional programming language like OCaml or Haskell, but I work with colleagues who know Python, and we rely heavily on Python’s extensive numerical computing and machine learning libraries. Promoting functional programming languages in this environment is like promoting Plan 9 to those who need Microsoft Office or the Adobe Creative Suite.
Language adoption is pushed by platforms. New languages get adopted when there's a new platform that people wish to develop for, and existing languages aren't suitable for it.
That's behind Swift's rapid rise (it's being pushed as the "new official" language for iOS) and a lot of historically successful languages. BASIC was the language of the early microcomputer era. C was the language of the UNIX & Win32 era. PHP and Perl were languages of the Web 1.0 era, and Javascript, Ruby, and Python of the Web 2.0 era. Objective-C is for Mac and iOS development, and Swift is soon to replace it. C# is for .NET development. Java was pushed as the language for the web, but ultimately found adoption within the enterprise, and I think Go is headed toward a similar position.
The reason we've seen all the major languages of the past 10 years backed by large corporations is because all the major platforms are controlled by large corporations. The web was the last totally-open computing platform to see widespread adoption, and there was a large renaissance of single-developer programming languages for it. We've been in a similar position in the late 80s and early 90s, when C was completely dominant along with Windows & commercial UNIXes, and it turned out that pattern reversed itself in a few short years.
It has the same fundamental problem, though: you have to rewrite most existing code, which hinders adoption. In this case, it might actually hinder it more than also improving the language itself, since people would be more willing to take that leap if there are more benefits to be had from it.
Firstly, I disagree with your argument about language adoption being irrelevant. When a language is picked up by a serious player, it helps signal to other users and companies that there might be practical benefits to using the language. Two good examples that come to mind are Erlang/WhatsApp and OCaml/Jane Street.
Secondly, there is a huge difference between a language being used in general and a language being used for serious, visible projects within a company. Think: writing a small utility in Zig at company X vs. rewriting the backend of a core product in Zig and pointing to measurable gains in performance and reliability.
> It is ridiculous to believe in a Google conspiracy to outcompete Linux by getting it to incorporate Rust [..]
Great, but you should be telling that to the user I was replying to.
Honestly if you're going to take a step back and consider those things, why not also consider that we already have so many programming languages that it's almost impossible to get to a deep level of understanding of all of them.
Obviously if you enjoy making languages then you should do so - and in that case, noticing that your dynamic un-toolable language won't get wide scale adoption shouldn't matter. It's already a guarantee it won't get that wide scale adoption. Either make your un-toolable language because you enjoy making them, or contribute your efforts to an already popular language that you enjoy. There are tons of interesting problems and huge areas for improvements in every single language.
Don't make a new language for the goal of gaining widescale adoption.
reply