It seems like a new language is being announced on HN every month or so.
I'm curious why there is a need for new programming languages, and what purposes they serve that existing languages aren't well suited for. Do you have any experience you can share?
Companies I have worked for will always use technologies that have a large ecosystem and are battle hardened. What is driving the need for new languages, and who are the early adopters?
In a way, this question is answered by your follow up question.
> and what purposes they serve that existing languages aren't well suited for
New languages are made because existing languages are not well suited for a given purpose. But, I don't think there needs to be a reason at all. The exercise of creating one is its own motivation and reward.
For me, I find a lot of the very popular languages to be mundane and boring to work with at best, and painful at worst. I would much prefer to work with Clojure instead of Java. Likewise, I would rather work with ClojureScript over JavaScript.
If I still want to work with a Lisp but I need something with a smaller footprint than Clojure I can reach for Janet or Guile Scheme. Currently I am using Janet for writing command line tools and I am exploring building webapps with Janet as well. I like the fact that it can produce statically linked binaries for the major operating systems and it is possible to port to others as well.
Although all of those are new languages they are all based on a very old concept (as far as computers are concerned), Lisp. Forth is another old concept that probably seems new simply because it isn't popular. However, I would rather use Forth than C or C++ to program my Arduino because it is interactive and I can program directly on the microprocessor.
Overall, I think a lot of companies and individuals choose what is popular because it is viewed as a safe choice. I prefer to explore the fringes because it is more interesting.
Exist a kind of self-defeating idea where "programming languages", "shell", "os", "editor" are in this "special" category of software that "must not be changed".
Is pretty weird. Specially from programmers: Why are we building new software? Anything we do, somebody have done before.
Somehow, is important to make the connection that our tools are alike any other software, and we are like any other user.
If the regular user want/need/deserve new software, so as we.
---
> I'm curious why there is a need for new programming languages
Because all of them sucks. For different reasons. Some have nulls, some have bad errors, some are crash-prone, some have dangling else, some are too obfuscate, some are too complex, or too simple, or slow, or take too much resources, or bad for imperative code, or bad for functional code, or bad for concurrency, or parallelism, or data transformation, or querying, or manage decencies, or scale....
Some are bad at many things at once (cough c cough). Few are good at many things. None, so far, is good at all.
Maybe is like the "theory of everything" and not exist "the perfect" lang. If that is the case, then we must chose "the best tool for the job".
Some langs, are picked NOT because are "the best tool for the job", but because are "the best tool for the job recruiters" or something like that.
Despite that langs cause millions of dollars of losses.
You know how in certain niches exist that incredible, pathetic, terrible, software that also is the number 1?
And that thing is the bedrock of a billon dolar industry?
And you think, how is possible that humans allow them to use THAT?
And you think, how is possible that industries with $$$$$ "just not use something better?"
Yep?
That is our industry.
The syntax is like Ruby, but it's statically typed and compiled and the executable uses very little RAM.
It appears to be the sweet-spot (a GC'ed but typed/compiled lang) as I've yet to achieve high productivity on web apps with C or C++
FWIW it's worth, I gave Rust and Rocket a whirl. It seems nice. I didn't quite understand the borrow-checker... I'm familiar with RAII, ARC, pool-based approaches, trying to implement a malloc myself once (very badly) on an mcu... didn't get Rust yet...
One occasionally has to deal with Go, and it's getting rather widespread. Luckily, it's rather easy to transpose concepts to from your general algol family style stuff. I wasn't excited by Go, but it's not been frustrating either, and there's a LOT of stuff out there that has been getting it's "generational rewrite" in Go during the last few years... (wkhtmltopdf will be rewritten in trending languages every decade or so, right?)
To practice coding interview algorithms and data structures problems. It is basically like Python but statically typed and compiled.
Don’t mistake the number of announcements with people actually using these things. Many will last only a short time and then go away.
There are many other considerations you need to account for before you use a language for real work. The people constantly jumping from one fad to the next are not the ones you should be concerned with following.
There were two bottlenecks to coding better. One was how much code I could "keep in my head". That translated pretty quickly to how much code I could keep within one laptop screen, or rather shortening method sizes to be no longer than my monitor screen.
The other bottleneck was Java boilerplate. We spent a lot of time fixing this. With Android, there were bulky solutions like ActionBarSherlock. To put it one way, it was like writing articles in HTML, and we'd find Markdown-style hacks.
Default code would be for example, CodeView X = (CodeView) findElementById(R.id.codeview), when it could just be CodeView X = codeview. Multiply this by every single element on the page. Imagine doing enterprise forms for a city council (which was my job at the time). I was happy to spend non-billed time looking for solutions to this so that I can do better during by billed hours.
It was made worse that Android advancements drastically increased the length of code, with new things like RecyclerView/Adapters and Fragments.
Kotlin solved all these problems and very elegantly. It was simply part of the code, no special hacks needed. It did everything you'd need from Java. And there were things like functional programming and null safety which was a nice bonus.
Similar reasoning applies to Swift.
Golang is an interesting example as a language which decided to be minimal, opinionated, leave out fancy language features. It was built to be "in the service of software engineering."
Largely, the world evolves, tech evolves, and so will out languages for translation between the two.
Why? I love C language (static typing, you can shoot yourself in a leg == you can do almost anything, etc..), but C is not suited to write this kind of application. I also like PHP - large community, libraries, large OS systems written in it... But I miss some C features and getting bored by having dozens of dependencies for a simple project. Python - is slow (yes, can be tuned somehow, but brings more work to do) and I do not like the syntax and I miss brackets. For me, Go seems like a way to go from now on.
So, to sum it up - for me a new language is a way to solve some set of problems much easier (and sometimes more efficient and/or secure) than with an existing language. I wouldn't be happy if I had to write anything larger than hello world in assembly :)
When I program, I try and think of the problem and possible solutions in the same way that I would if working with a human colleague. That is, I design systems in a human way. I try to program in such a way that maps to how I would explain the domain to someone else and not how the computer thinks of it.
Thus, I primarily think in terms of data, transformations on that data, interactivity, and concurrent or parallel operations. This approach almost chooses languages for me. My primary languages I am learning and using at home right now are F#, Racket, and Elixir. These are new (-ish) languages with new ideas based upon the strong foundation of old languages that had revolutionary ideas, so it's not surprising I landed on these, for me personally. Also, although each one is a complex language, they each have a simple core, which is another plus. Then there are visual languages like TouchDesigner and LabVIEW.
However, the curse is finding a place that uses the road less traveled because it requires the company and its employees to have made the non-standard choice and to consider the tools as important as whatever else they're working on. There are few places that use newer languages, but I am trying to become more agressive in just using them at my work. If they solve problems in an efficient way, you shouldn't necessarily need to ask for permission. People can be trained. Nobody asks for permission when they use Python or C or whatever else. They use it because that's all they know. The other way is to merge your personal interests with work by creating your own company, but that is an obvious high hurdle.
When using new languages, there is the problem of ecosystem, particularly in libraries. However, I am of the opinion that this isn't as big of a problem as often reported. It's a problem but not the no-go problem it is usually presented as.
It's not different in that respect from any other popular mode of software exploration like graphics programming or small webapps.
The more relevant question is with what makes a language "industry ready", and the answer there is mostly libraries, tooling and positioning. C is crude for many tasks, but its conjoinment with Unix gave it a leg up. JavaScript is the same way with the Web. More recently we have had some waves of corporate-backed languages in Java, C#, Swift, and Go.
New languages fall out of just about anything that has a data structure with control flow constructs, though.
For building rapid GUI applications in Flutter
To try and revitalize my math life a bit... There are some things I quite miss, and learning Lean was my idea to force myself to get back in the swing of things.
[1]: https://leanprover-community.github.io/
[2]: https://wwwf.imperial.ac.uk/~buzzard/xena/natural_number_gam...
Rest of our stack is in Scala - primarily since it is very good for writing compilers - we have a few in our product.
We’re a data engineering product - think Spark IDE.