> I'm curious why there is a need for new programming language

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.

I don't agree. Mostly new languages are developed for the sake of creating a "new" language.

> I'm curious why there is a need for new programming languages

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.

> Anything we do, somebody have done before.

I strongly disapprove of this thinking, it's simply a fallacy. There are constantly new problems created by technical advances, new tools and the evolving nature of everyday life and software.

Basic algorithmic solutions and libs like http in a specific language were "always there" and they're being redone forever. Things like controlling your light strip from your Switch are not, and there is always a need for such.

I fail to make it more obvious but this was the idea:

>Exist a kind of self-defeating idea .. (programing langs)

So

> Is pretty weird. Specially from programmers: Why are we building new software (other than programming langs)? Anything we do, "somebody have done before" (I must have put this in quotes!).

Crystal lang. Web transported applications, as it was apparently intended. (HTTP requests being part of the std-lib and all...)

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?)

Crystal, to power simple cli applications that are easy to write (it is basically Ruby), fast (it is statically typed, and compiled), and easy to distribute (static binaries are supported, and Windows builds are possible.

Windows builds are possible? Can you tell me more?

I skipped Crystal because I absolutely need windows binaries.

You can't cross-compile yet, and it depends on WSL. I think proper windows support is one of the v1 (or soon after v1) targets.

Same. Pretty sure the Windows support isn’t there yet. Last I checked anyway....

I will use Crystal for the exact same purpose and reasoning. I don't like Go :).

Go and Rust are two of my favorite examples. Go has a focus on minimalism and concurrency that makes backend engineering enjoyable. Rust is C without the memory problems and a decent package manager. Cool stuff for sure. I've recently built a Go-in-the-browser course for those who want to dip their toes in https://qvault.io/go-mastery/

It looks good, I’m getting my feet wet but find the modules and importing my own code and correct project set up rather obscure, but the code writing is pretty straight forward. Looks like your course speaks to the latter but not the former: any advice about where to read up on the former?

I would say read this: https://golang.org/doc/code.html

What’s the concurrency story for Rust? I thought it had a good solution too.

It does. The language design leads to very clear ownership semantics between threads. It also recently added async await.

Nim

To practice coding interview algorithms and data structures problems. It is basically like Python but statically typed and compiled.

If you enjoy Nim, I encourage you to try Cython, which is more mature and enables much more practical applicability in most job settings. It’s virtually never worthwhile for an employer to switch to supporting Nim if they already use Python and can just use Cython for targeted use of static typing in the small set of cases where it’s useful.

I've tried it but I like the other features in Nim as well such as algebraic data types. As well, Cython isn't usually available in online coding environments while Nim is, at least sometimes.

I just meant despite the nice features, Nim is deeply impractical to use in situations with business problems, because the cost to adopt a new ecosystem without mature libraries is too high.

In other words I meant: if you like Nim’s features but find you need to do more than toy coding, checkout Cython. While your mere preferences may favor Nim, Cython can be used to solve problems without requiring companies to make a seismic change.

Are algebraic data types supported? Can you do compiler checked exhaustive pattern matching on a sum type?

Yes, they are supported.

There are a few libraries for that, e.g. Patty, which IIRC supports exhaustive pattern matching.

Nim macros are as-powerful-as-Lisp-sans-reader-macros, and usually easier to write and use. A lot of things that require language revisions in most languages (e.g. async/await and pattern matching in Python/C#/JavaScript) are user-level constructs in Nim.

Just because something is announced doesn’t mean that everyone is using it, or even that it should be used. Many projects are created by people interested in the idea of writing languages, so they go off and do it then tell some people. They may be trying to solve a specific problem or just exploring some ideas, and other people might also join in to go along for the ride. It does not mean that they solved all programming language problems, or that it should be used as a general purpose language, and especially should not be pushed into production.

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.

Learning Julia for doing scientific machine learning & numerical optimization. Faster to run than other interactive languages like Python or IDL, faster to write/iterate than compiled languages C/Fortran.

At the time I started using Kotlin, I was a freelancer. My selling point was that I got things done 4x faster and at similar quality, but charged 2x the hourly rate as your average full-time programmer. It was a win-win for both me and my clients, but I had to keep doing better.

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.

Crystal has completely taken over my personal work. I have three projects in the pipeline (none public yet) that are mostly written in it: a 2D pixel art adventure game (desktop), a heavily scriptable email client (web service), and a sheet music reader/manager (largely a hardware project as well, targets a raspi hooked up to an e-paper display). The language has been such a breeze to use for all three.

Cuelang is an example. It's for configuration where we really need a dedicated and common language, because Yaml is being abused at this point.

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.

Rust. Embedded. Firmware from Scratch. Satellites/cubesat/space related.

How did you approach this in your workspace and successfully steer people away from C and C++?

I have successfully avoided C and C++ my entire career, for good reasons, but I am getting more and more interested in doing more true embedded system type of work. Rust is certainly the leading candidate for me.

Awesome, considered KubOS?

Hi, right now I'm learning Go (to write an access control system for our makerspace). For me this is a pretty new language but currently at the point where I see quite large community and available libraries (wait, it is called a module, isn't it?).

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 :)

> you can shoot yourself in a leg == you can do almost anything

That doesn't really follow. A language with plenty of undefined behaviour => shooting yourself in a leg. A language with plenty of defined behaviour => you can do almost anything. C falls somewhere in between.

To learn, have some fun, and think differently and more optimally. Most of the older and more mainstream programming languages like Python, Java, C, C++, etc. are simply uninspired. They have very mainstream and convoluted ways of thinking that bind you in ways that I personally can't take.

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.

Programming languages, being engineered constructs, take a multitude of shapes.

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.

Dart

For building rapid GUI applications in Flutter

Noticed the other day Canonical and Google teaming up:

https://ubuntu.com/blog/canonical-enables-linux-desktop-app-...

I have many cli tools that could use front ends ;)

Lean [1] [2] [3]

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...

[3]: https://www.youtube.com/watch?v=Dp-mQ3HxgDE

We are using Go for all of our backend services and business logic. We needed something that is statically compiled, easiliy deployable and sufficiently fast.

We’re using Go for writing a kubernetes operator to deploy our product.

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.