Programming languages that are actively developed on GitHub(github.com)
github.com
Programming languages that are actively developed on GitHub
https://github.com/showcases/programming-languages
132 comments
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.
[deleted]
The default sort order is the number of "Stars" each repo has received, which isn't a useful measurement, IMO.
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.
A lot of people seem to like Plots.jl, a unified frontend for several plotting backends.
https://github.com/tbreloff/Plots.jl
I still prefer Gadfly, which does everything I need while looking great. (Only nitpick is slow time to first plot in each session.)
http://gadflyjl.org/stable/
https://github.com/tbreloff/Plots.jl
I still prefer Gadfly, which does everything I need while looking great. (Only nitpick is slow time to first plot in each session.)
http://gadflyjl.org/stable/
"Other than a few minor nitpicks"
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...)
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?
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.
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
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
I've had a couple submitted pull requests merged into Elixir. The review process was very quick and painless.
Yes, I can confirm this. Development on Elixir (https://github.com/elixir-lang/elixir) is done in the open and on GitHub.
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.
Erlang (https://github.com/erlang/otp) accepts PRs on GitHub, although they maintain their own JIRA instance for issue tracking.
Development of Nim (https://GitHub.com/nim-lang/Nim) and its tools is done openly on GitHub.
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.
It's not on this list, but Eve is being developed in this manner: https://github.com/witheve/eve
Everything we do is through GitHub issues and PRs.
Everything we do is through GitHub issues and PRs.
Haxe is developed totally in the open.
D is open.
OCaml now uses Github as its official repo and accepts PRs.
PHP is definitely an open process.
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.
Red - Everything is open and on Github.
PureScript is open as well.
Pony is developed entirely on Github, using the issue tracker and pull requests: https://github.com/ponylang/ponyc
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?
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?
Elixir is not (fully) self-hosted either. There's interesting discussion on the mailing list about this: https://groups.google.com/d/msg/elixir-lang-core/K9i3uBSPKZI...
> 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.
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.
Pretty sure that most interpreted languages aren't self-hosted, for obvious reasons.
Rust is self-hosted in that the compiler front-end is written in Rust, but it uses LLVM in the back-end.
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.
[1] http://comealive.io/Tracing-Code-Execution-with-Alive/
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.
[1] http://comealive.io/Tracing-Code-Execution-with-Alive/
This is very interesting, thanks! Makes a lot of sense to support tooling like this.
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.
Another language not dependent on any of those is Red which is currently written in Rebol & Red/System.
NB. At some point Rebol parts will be replaced by Red so making it self hosted.
NB. At some point Rebol parts will be replaced by Red so making it self hosted.
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.
Ruby's main repository is on a subversion server at svn.ruby-lang.or and GitHub is a mirror. See https://www.ruby-lang.org/en/community/ruby-core/
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 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 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
Cool! How do you deal with the issues raised in https://news.ycombinator.com/item?id=13310271 ?
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.
Would you implement it using tags?
Would you implement it using tags?
I think we would number only the master branch. Using soft or hard tags is an option. I've created an issue https://gitlab.com/gitlab-com/marketing/issues/747
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.
[deleted]
FWIW I recently got Lua up onto github, though development does not happen on github. https://github.com/lua/lua
See http://daurnimator.com/post/153864402074/githubcomlua for more info
See http://daurnimator.com/post/153864402074/githubcomlua for more info
Also, Moonscript which compiles to Lua is developed on GitHub.
https://github.com/leafo/moonscript
https://github.com/leafo/moonscript
Go is not developed on github. It is mirrored to github.
Ditto for Perl - https://github.com/Perl/perl5
Haxe was so promising but it remains largely ignored by the community.
https://www.google.com/trends/explore?date=all&q=%2Fm%2F0dbj...
https://www.google.com/trends/explore?date=all&q=%2Fm%2F0dbj...
I'd love to know why haxe never caught on mainstream and what it's primary drawbacks are.
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...
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...
I don't really know. The language in itself is awesome.
My guess is that there are way too many moving pieces since Haxe needs many side projects to be the universal language it promises to be.
My guess is that there are way too many moving pieces since Haxe needs many side projects to be the universal language it promises to be.
When I first learned about and took a look at haxe, there was no good documentation.
Granted, this was six years ago, so it's probably better now.
Granted, this was six years ago, so it's probably better now.
It's better now:
https://haxe.org/manual/introduction.html
It can still be improved, but it's miles better than it was years ago.
It can still be improved, but it's miles better than it was years ago.
The trends chart is a little biased in German-speaking countries because Haxe translates to "ham hock" ... a popular beer garden dish :D
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.
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
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:
this is about as far from least surprise principle as you can get.
trivial example:
{ a: b
c: d }
this is about as far from least surprise principle as you can get.
It looks like an object to me: [0]
[0] http://coffeescript.org/#try:%7B%20%22a%22%3A%20%22b%22%2C%2...
[0] http://coffeescript.org/#try:%7B%20%22a%22%3A%20%22b%22%2C%2...
http://coffeescript.org/#try:%7B%20a%3A%20b%20%7D - object
http://coffeescript.org/#try:%7B%20a%3A%20b%2C%20c%3A%20d%20... - object
http://coffeescript.org/#try:%7B%20a%3A%20b%0A%20%20c%3A%20d... - bullshit
i understand why this happens, i just think it's a stupid edge case that shouldn't exist. and there are more like that in coffeescript.
http://coffeescript.org/#try:%7B%20a%3A%20b%2C%20c%3A%20d%20... - object
http://coffeescript.org/#try:%7B%20a%3A%20b%0A%20%20c%3A%20d... - bullshit
i understand why this happens, i just think it's a stupid edge case that shouldn't exist. and there are more like that in coffeescript.
Interesting. Not something that's hit me before.
But, I'd still take an edgecase over other JS quirkiness.
But, I'd still take an edgecase over other JS quirkiness.
I still prefer CoffeeScript because of its clean syntax.
They forgot to include JavaScript which is at https://github.com/tc39/ecma262
Golo [1][2] caught my eye given its French provenance -- they usually have a fresh/interesting perspective in engineering.
[1]: http://golo-lang.org/
[2]: https://www.eclipse.org/community/eclipse_newsletter/2016/oc...
[1]: http://golo-lang.org/
[2]: https://www.eclipse.org/community/eclipse_newsletter/2016/oc...
OCaml is industrial strength, but golo looks just like a fun research project. I guess OCaml started that way though.
Missing: Imba, with 1,750 stars. Can't do a PR because stuck on an iPad right now. https://github.com/somebee/imba
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.
I'm sure the craving will go away with a few more days of messing.
Rename it to "Null-conditional Operator" and you're good to go: https://msdn.microsoft.com/en-us/library/dn986595.aspx?f=255...
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.
I’ve used Crystal a bit and like it a lot. It’s a little rough around the edges, but I hope it gains more traction. It isn’t just for Rubyists either.
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.
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.
GitHub has a distinction between 'Starring' and 'Watching' a repo.
A star is a far lesser commitment than you imply - it's a glorified browser bookmark / facebook-thumbs-up.
A star is a far lesser commitment than you imply - it's a glorified browser bookmark / facebook-thumbs-up.
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.
Typical node being ninja stealth. I guess not technically a language on it's own.
https://github.com/nodejs/node
Not quite the same but nix[0] and the nix expression language [1] is also missing from the list.
[0] https://github.com/NixOS/nix [1] https://nixos.org/nix/manual/#ch-expression-language
[0] https://github.com/NixOS/nix [1] https://nixos.org/nix/manual/#ch-expression-language
Sure, why not. Give us a master list with all the things.
Also missing: Ceylon - currently with 191 stars
https://github.com/ceylon/ceylon
https://github.com/ceylon/ceylon
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.
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 should have done my research. I assumed since Kotlin has large support it has been around longer. Thanks!
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.
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.
Also soon, Python: https://www.python.org/dev/peps/pep-0512/
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.
these are curated lists, here's one for nosql: https://github.com/showcases/nosql-databases
edit: big list of lists: https://github.com/sindresorhus/awesome
edit: big list of lists: https://github.com/sindresorhus/awesome
Missing https://github.com/lucee/lucee (open source version of ColdFusion)
Missing: Reason (https://facebook.github.io/reason/)
It's kind of an ocaml wrapper though but good point.
Most of these languages are also bootstrapped!
I wonder when we'll see Swift written in Swift. And I wonder what kind of monstrosity a PHP written in PHP would look like.
I wonder when we'll see Swift written in Swift. And I wonder what kind of monstrosity a PHP written in PHP would look like.
There's a php implemented php->AST parser here: https://github.com/nikic/PHP-Parser
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.
Many Lisp interpreters are bootstrapped, have a glance over the examples of meta-circular evaluators at Wikipedia: [0]
[0] https://en.wikipedia.org/wiki/Meta-circular_evaluator#Exampl...
[0] https://en.wikipedia.org/wiki/Meta-circular_evaluator#Exampl...
PyPy is Python implemented largely in Python, and it supposedly is faster than python's C implementation.
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.
> PyPy is Python implemented largely in Python
It's actually a superset of a subset of Python and it's called RPython: http://rpython.readthedocs.io/en/latest/rpython.html
> it supposedly is faster than python's C implementation
Only if its JIT compiler gets a chance to trace and compile some code which is then executed often enough to make up for the overhead.
It's actually a superset of a subset of Python and it's called RPython: http://rpython.readthedocs.io/en/latest/rpython.html
> it supposedly is faster than python's C implementation
Only if its JIT compiler gets a chance to trace and compile some code which is then executed often enough to make up for the overhead.
On a side note, I found it more useful that the Weekly/Monthly trending repositories are finally working again.
https://github.com/trending?since=monthly
https://github.com/trending?since=weekly
https://github.com/trending?since=monthly
https://github.com/trending?since=weekly
Nim is very underrated. It's among the fastest, has a python-like syntax and can compile to C, JavaScript and other languages.
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.
I've used Pony in production. Not a language I would describe as just a prototype, when the compiler is almost as advanced as Rust's.
As to the ease of compiling it... I've always compiled it from source, to track some bleeding-edge features, and compiling ponyc is a breeze.
As to the ease of compiling it... I've always compiled it from source, to track some bleeding-edge features, and compiling ponyc is a breeze.
> 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.
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.
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.
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.
One of the missing languages is Opa, which has more than 1k stars and has been on GitHub for years.
https://github.com/mlstate/opalang
https://github.com/mlstate/opalang
C++: https://github.com/cplusplus/draft
(maybe omitted because they were only listing reference implementations?)
(maybe omitted because they were only listing reference implementations?)
[deleted]
[deleted]
Funny github doesn't recognise swift as an language, but shows it as c++. Same for PHP, that is shown as C.
Anyone know why ?
Anyone know why ?
It's showing what language most of the implementation is in.
[deleted]
No ClojureScript, seriously?
Missing Node.js which has 30k stars and 5.4k forks... Second to Swift.
https://github.com/nodejs/node
https://github.com/nodejs/node
Probably, because Node.js is a runtime environment for Javascript and not a programming language?
You probably may be right. ;-)
There must be more. They forgot mine!
https://github.com/jul/confined
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.
https://github.com/jul/confined
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.