Interesting to note that Julia comes in at #9 on the list, ahead of Scala, Clojure, and Erlang. I still think it's the most underrated programming language of the decade and hope that its usage continues to grow. I know it's touted as a language for numerical computing and scientific research, but I believe it would make a great general purpose language, perhaps even better than Python.
Other than a few minor nitpicks, Julia is genuinely a joy to program in, and the depth of its feature goes very far (multiple dispatch, homoiconicity, genuine macros, sophisticated type system, runtime compilation via LLVM, clean interfacing with C code). I can't say the same for other languages. You can tell the language was designed and not cobbled together in an ad hoc fashion.
I'm not sure number of stars on gihub is a good measure of popularity of a language, especially when we're talking about number around 10k. I'm pretty sure Rust has more than 20K users, and Ruby and PHP have both more that 10K. Vast majority of these users though don't look through the C code of their engine and don't star it on github.
Does it still not have a decent charting library in the stdlib? I look at it every now and then (always looking for a good successor language for Python) and last I recall you had to use MatPlotLib? Is that accurate? This is stupidly simple in Matlab and should be here as well.
That would be a nope. Gadfly doesn't meet my needs and seems to have stalled in development, so I use Matplotlib via PyPlot, but Matplotlib is a bit maddening to work with. I heavily considered attempting my own plotting library during grad school but couldn't find the time for it :/
(Although I will say that Convex.jl makes up for all the pain of not having a good plotting library...)
Thanks for the reply. I agree that Matplotlib is too complex. I'd abandon Python today if Julia had simple charting in stdlib, but practically nothing does outside .NET (sadly, I'm not a fan).
It's worth noting that convex.jl is developed by the same folks as cvx (matlab) and cvxpy (python). They all provide access to the same solvers with similar abstraction and usability.
Which of these projects has a truly open development process that takes place in public and on Github?
Are most (or some) of these developed internally by whichever enterprise is behind the language where developers at those companies "bake" commits and then push them up after going through an internal code review process?
Rust is one that's developed in the open. Commits to Rust's master branch must be done through pull requests on Github. All PRs must be approved and reviewed before being merged, and the approver cannot be the same person who submitted the PR. Furthermore, major changes to the language must undergo an RFC process, which is also coordinated via a Github repo: https://github.com/rust-lang/rfcs/ .
>Commits to Rust's master branch must be done through pull requests on Github. All PRs must be approved and reviewed before being merged, and the approver cannot be the same person who submitted the PR.
Any company that puts half an effort into open washing will follow these same procedures, so they aren't safe indicators that the real decisions aren't made behind closed doors ahead of time.
Paying close attention to things like the rfc process and approval process for commit rights and whatnot usually tell the real story.
Scala (https://github.com/scala/scala) is completely developed on GitHub with Pull Requests requiring reviews being the only way commits can enter master. Issues are in a separate JIRA instance, although there is currently some experiments about migrating that to GitHub as well. A lot of other processes about the language, such as discussions about language features and their design, also are open on GitHub.
Its little brother Scala.js is entirely developed on GitHub too, complete with language proposals and issue tracking. https://github.com/scala-js/scala-js
D is developed on GitHub and is open. Albeit there is no enterprise funding the development, it's small community is pushing the language forward. PR are reviewed and merged. But honestly sad to see it at the bottom of the list.
The three Microsoft ones (C#, VB.NET, TypeScript – PowerShell is curiously missing from the list, though) are openly developed as well. I'm not sure there are many popular open-source languages these days where the developers work behind closed doors and only throw code dumps out every now and then.
clojure is close, but not done on Github. All work must be through jira/bitbucket but anyone can sign up for free with the only requirement is of a CA.
In the Top 10 there are only two languages which are not self-hosted. Swift with C++ and PHP with C.
I know the reasoning for Swift being that it's just not practical at this point reimplementing everything in Swift, but looking at the others it seems to be the norm to self-host your language at some point at least. Is there a reason for this? Is it just a rite of passage or do the maintainers obviously enjoy using the language itself as well?
Some languages chose to go this route right from the start (see Crystal for example), others might (hopefully) pick this up later (I'd love for Swift to be). Does anyone have any insight on this?
> In the Top 10 there are only two languages which are not self-hosted.
I don't think that is true. Ruby is written in C, Elixir is built on Erlang and Clojure is built-on Java. In fact the only two I know for sure that are fully self-hosted are Crystal and Julia.
Elixir has a little bit of Erlang in the compiler but at this point it would be fairly trivial to replace it with pure elixir, and most of the compiler is elixir already. However, Elixir does compile down to the EVM/BEAM (Erlang Virtual Machine) without using Erlang as a go-through. I'd argue that Elixir is 'mostly self-hosted'.
Actually the Elixir compiler does NOT compile directly down to the BEAM, it generates Erlang AST which is then passed into the Erlang compiler which then generates the BEAM code. So most of the compiler is in Erlang. It also uses a significant amount of the Erlang libraries as a base for its own libraries. So calling it 'mostly self-hosted' is stretching a bit.
In the case of C#, their previous compiler was built in C/C++ and was apparently very hard to work with. Since rewriting in C# itself, named 'Roslyn', they were able to build it with immutable structures, as well as expose the whole API as a regular C# library. Now they are adding new features all the time and the IDE integration is even better.
It's also really powerful for users to just add the lib, and be able to immediately parse any C# solution with the official tools, get semantic info, errors, autocomplete info etc as well as compile scripts. You can get a mini visual studio up and running in a day.
I can even get the source off github, and continue working in my favourite language. I even did this and changed the parser round (removed need for semicolons, make the language whitespace sensitive) just as a learning exercise. It also gave me a bigger appreciation of functional programming, and how one can use immutable data structures when writing a compiler.
Edit: one of the devs even used it to make real time C# [1] ala Bret Victor style.
I think many of the languages either depend on LLVM, C, C++ or JVM/Java. The only language I think not dependent on either of those is Go where compiler, runtime, GC, crypto etc are all written Go and some assembly.
I guess some languages are not meant to be used to write compilers. I a certain way it would make sense to not try to self-host your language at all prices. If you do, you may end up adding features that are outside the original philosophy. I feel that we already have enough universal, system languages. Thus, languages that try to tackle very specific problems seem more useful to me.
The wiki and the issues are also lacking from GitHub because they are on a Redmine server at https://bugs.ruby-lang.org/
GitHub was written in Ruby (and Rails) so the issue tracker already existed and they felt it wasn't worth migrating it. I can understand why they don't feel like hosting all of their knowledge base on an external server when their one works well and their main repository uses a different technology.
I don't understand why they're still on subversion. Maybe some custom build tools they don't want to migrate to git?
The core team indicated they quite like the sequential numbering that SVN gives them. I'm considering building it into GitLab as an option if they would use it to host ruby :)
Inspired by Mercurial, we built such functionality for GIT backend in RhodeCode.
So the numeric identifiers are used now for all 3 backends we support. Kallithea has it also implemented for GIT.
I personally never like the meaningless hashes. Those numbers act as good identifier of project size and progress. It quickly shows what kind of ranges we're taking when doing a compare, or simply looking at files and seeing those numbers.
It gives a lot of context. Just look how much more useful information a compare shows
r1808:39334bf35fdf...r1819:3e8df3a82397
vs
39334bf35fdf...3e8df3a82397
I'd like to understand how it could work. For the simple case with a master branch and one feature branche we could number commits as they are merged into master. What about two branches worked on at the same time, with multiple commits and merged to master? If the numbering has to reflect the timestamps of the commits it should be recomputed at every merge which is probably not desirable. However every branch has its own numbering and I don't know if it's desirable to have two numbers for the same commit.
Mercurial and bzr have those sequential numbers. They really aren't the awful apocalyptic problem that git users seem to think they are. bzr tries harder to make them sequential and meaningful, but even hg's more lax approach to revision numbers is still useful: they are still approximately semantic, much more than node hashes.
My anecdotal experience - not so much about the language itself but the ecosystem:
I was making a short evaluation of platforms for light 2d game/graphic development/prototyping. This being in the context of a fun project with very limited time - having kids and a C++/embedded day job and no intent to analyze core dumps in my spare time.
Haxe was on that list (together with e.g. lua/LÖVE and phaser.io/typescript) and I had high hopes for it. The number of target platforms would make it very attractive to transition from prototype to "publishable" game.
But what turned me down was the documentation and confusing state of competing libraries and target platforms.
E.g samples of a recommended tutorial were not working due to library changes (in very basic initialization functions). I found a solution but there was just too much friction .
So in the end, haxe lost in my evaluation because ... too much choice? I really wanted to have a predefined simple platform and just focus on gameplay.
If somebody has a recommendation for a haxe "starter kit" (compile target, libraries, docs, debugger/IDE/vim plugins ...) that allows to publish to all of desktop / html5 / mobile app then I'd be happy to hear about it. Maybe the next project...
Is CoffeScript still used much? I used it a bit a few years back when I was more interested in webdev and I liked it a lot, but I haven't really heard anything about it for a while. The only CoffeScript code I've seen lately is when I looked into finding the cause of a bug in a package for Atom several months backend back; I don't think I know of anything besides the Atom ecosystem that uses it nowadays, although I might just not be aware of other projects using it.
I think that CoffeeScript may have been a victim of its own success, now that ES6 is here and seems to have included many of its best features (e.g. arrow functions). We can also consider CoffeeScript to be the one to prove that "compile-to-JS" languages could succeed, so in that sense it sparked the modern surge of such languages (and, obliquely, perhaps helped justify WASM as well).
It remains very popular amongst Ruby/Rails users, presumably due to less switching overhead between Ruby and CoffeeScript vs JavaScript.
ES6 has provided a lot of the features that people were hoping for in JS, and CoffeeScript doesn't seem to be worth the effort transpiling from anymore. It used to be the game in town for "better" JS, but TypeScript seems to have taken that position firmly.
CoffeScript is endorsed by DHH and so it's more of a first class citizen than JavaScript in Rails. However it's not something you have to use. I never really liked using it and I easily managed to keep using JavaScript in all these years since Rails 3.1. I hope it's going to the deprecation bin soon but I believe that Basecamp is using it a lot. DHH won't have added it to Rails if that was not the case.
It is definitely less popular than it was pre-ES6, but it is still used.
I personally use it at work every day, plus I notice there are quite a few libraries (both open source and closed source) that are obviously compiled from coffeescript.
There is also work being done on a new version, CoffeeScript6, which will compile to ES6 and future ES standards. Check out the discussion at https://github.com/coffeescript6/discuss
ES6 has killed much of CoffeeScript's momentum, because of parity on a lot of language features, but I still find those that don't work with JS everyday still prefer it due to cleaner syntax, and fewer surprises.
i would contest the fewer surprises point. it may be convenient when it's your main language and you deal with it every day, but for somebody that only touches it once in a while it is riddled with quirks and warts. one has to constantly keep mental model of both languages in his head when developing to be productive.
trivial example:
{ a: b
c: d }
guess what this transpiles to (hint: not an object)
this is about as far from least surprise principle as you can get.
I'm surprised that Coffeescript is still actively developed. Either there are still lots of legacy code out there to work on or some people just really love the language.
My last full time job was coffeescript. I could take or leave most of it, but returning to C# for a hobby project has made me really miss the null soak ? operator.
I'm sure the craving will go away with a few more days of messing.
Hey that's awesome! Thank you. I normally shield my eyes from the fancy new C# things like PLINQ and others because my hobby projects tend to sit in the Unity3d ghetto. Really cool to know they adopted that though.
No offense, but this list is stupid in its current ordering if the order is meant to imply anything. I heavily use rust, python, and go and have not starred any of the repos because I have faith the current contributors and don't need to helicopter over current issues/PRs.
Stars are for following a project because you need to pay attention to breaking changes, bugs, and major feature releases. If you need to do that for a programming language, the language is immature, garbage, or both IMO.
Also, stars!=contributors, so an entire team of 1000 devs (!) could use github to fully develop a language and look worse off than many of these other examples that hardly use github at all.
Don't forget that languages with high stars could be the result of marketing. The "project manager" for one of these programming languages held a campaign on its mailing lists 2 years ago to increase the number of Github stars from 300 to the 1500 it has today.
It has a nice homepage and good examples but what would a language like this provide over something like Kotlin? Also, I had to dig down into the homepage to find out that it compiled down to JVM byte code.
Well, you could turn it around since Ceylon is older than Kotlin ;)
There's not a huge difference between the syntaxes, but IMHO Ceylon integrates better with the general JVM ecosystem. It has an excellent module system and works well with OSGi too. Ceylon + Vert.x is a powerful combo.
I think Ceylon is about a year older, so it's not much. Both arose out of dissatisfaction with Java 7 and below. Whether Java 8 has done enough to stem that, idk. IMHO, nice though they are, there's not enough in the other languages to justify changing ... yet. Javac must be one of the most battle-hardened, mission-critical bits of code in existence.
Wow Go has really gained traction. Coming from a Python, PHP, JavaScript background I have been contemplating learning Go or Elixir this year. I am drawn to Elixir because of the functional approach which is different than what I am used to.
I've been learning both this year. Go at work and Elixir in my spare time. Both have a lot of similarities and the differences largely boil down to some root design decisions.
They are both great languages. I find Elixir to be more applicable to most of the work that I do (web work), personally. Phoenix is so much more polished than any of the web options in Go, I'd tend to make it my default. Go is where I'd reach when I needed to performance tune a very specific piece of a system generally. Can be a bit tedious for high level things.
Missing Scheme Requests for Implementation (SRFI). We do standards work for the many Scheme implementations in public using 151 Github repos and counting. The home page is at srfi.schemers.org.
Idea for gh: It will be a nice feature categories or even tags for repos. I would like to see a similar list for databases for example, or even relational database, blog engines, etc.
You can't practically bootstrap an interpreted language. That being said, I'd be intrigued to see PHP run using multiple nested interpreters from different language versions.
Depends on what you define as interpreter, as RPython, the language that PyPy uses, actually has a VirtualMachine, turning PyPy more into a bytecode interpreted language... Which some people argue isn't a straight interpreted language.
Some of these languages (ponyc) are still...prototypes. Yeah you can get them working for a limited set of "working" and with very specific setup->configurations. If every language included a Docker or VM with it already set up for some level of demo, I think a rate for adoption/learning them would uptick.
> If every language included a Docker or VM with it already set up for some level of demo, I think a rate for adoption/learning them would uptick.
Programming languages are for programmers - the kind of people that run programmer-friendly OSs/distros and figure out how to make their own packages when needed.
You don't need containers and virtual machines when you can simply "emerge dev-lang/pony" and be on your merry way.
Anyway, Pony is not the right example for the point you're trying to make because it already provides Gentoo, Arch, Debian, RedHat, macOS and Windows packages plus a Docker image.
Swift gets a lot of traction, good to see that. I hope they manage to get the ABI and core language features stable in the next release. Updating a large project always makes me a bit nervous and I'm tempted to blame problems on the migration even when it often turns out they don't.
The benefit of first class platform languages is that it doesn't matter how well devs like them.
Anyone that wishes to use the platform needs to either cope with it, or face the extra level of pain of development effort by not using tools supported by the OS vendor.
So with time at least Apple platforms will be a bit more safer, and enjoy an ML inspired language.
I program in a lot of languages that also have different styles (JavaScript, F#, C#, Objective-C, Python and PHP) and I find Swift pretty much ticking all the boxes that make it a nice language to me for the majority of tasks I like to do. I would probably use it also if I could pick other languages outside of Apple's choices.
So far from what I've tried F#, Swift and Python are my favorites depending on the task at hand. C# and F# are valid options for iOS and macOS development but I wouldn't take the extra complexity of another layer just to use a different language.
Intended use?
A safe PHP and a safe container for remote execution of code.
Leaving your computer used by customers arbitrarily within bounded predictable resources making you less stressed and able to do capacity planning.
Lol. I am playing out of my league I hadn't spent much time on it and havent much perspective for valuing it :)
Much more a POC. But if I found a sponsor, I can finish it in 1 month :)
I still need to document the syntax of the FORTH I made, and create storage (~ vars and functions). But after that, my roadmap is handling the concept of integrity/units that will prove more efficient than typing.
Ex : if c is $/unit then comparing/adding it with something in €/l will abort.
Other than a few minor nitpicks, Julia is genuinely a joy to program in, and the depth of its feature goes very far (multiple dispatch, homoiconicity, genuine macros, sophisticated type system, runtime compilation via LLVM, clean interfacing with C code). I can't say the same for other languages. You can tell the language was designed and not cobbled together in an ad hoc fashion.