Hacker News new | ask | show | jobs
Top 100 Most Popular Scala Libraries – Based on 10,000 GitHub Projects (takipiblog.com)
60 points by rubygnome 4564 days ago
10 comments

What surprises me is that there _are_ 10,000 Scala projects on GitHub, to start with. https://github.com/search?q=scala&ref=cmdform shows 12,757, of which 9,062 for the language.

I won't nitpick about that 10%, but even 9,000? GitHub definitely has changed the meaning of 'project'. I think there must be quite a few almost clones in there or very small projects. For comparison, the BSD ports tree (http://www.freebsd.org/ports/index.html) claims 24,330 ports. I don't believe there's a third of that amount of Scala code available (corrections welcome)

> GitHub definitely has changed the meaning of 'project'

How so? The search results page you linked says:

> We've found 12,757 repository results

Yes, GitHub calls them repositories, but, even on its home page, also calls them projects (https://github.com: "Powerful collaboration, code review, and code management for open source and private projects.")

Looking at http://www.googlefight.com/index.php?lang=en_GB&word1=GitHub..., that also seems to be common terminology.

Also, both URL and title of the article (http://www.takipiblog.com/2013/12/26/the-top-100-most-popula...) do talk of projects.

Before GitHub (and, to a lesser extent, SourceForge), you would not find stuff such as https://github.com/Dub4ek/Scala_Ex (one 20 line file, called Week1ExerSizes.sc (sic)) in the same places as, say, the gcc or NCSA Telnet sources.

I'm glad to see that Spring, which features heavily in the Java top 100, doesn't even make the top 100 for Scala. In my experience many Scala developers were previously Java developers. It's rather telling that they are choosing to ditch the needless complexity of Spring.
Or maybe Java has more huge projects then Scala or simply different kind of projects. Springs fits some projects better then other projects - duh - and they have to be big enough to make it really useful.

I have no beef with spring, found it useful and not that much complicated in the past. That does not mean I'm going to use it in every new project I'm about to start.

I've seen Spring projects with more xml than actual source code. When you ask why it's being used you hear 'to do dependency injection'. There was an excellent talk recently with a quote along the lines of: what Java programmers call dependency injections is just called passing variables in other languages.
Seriously. Using even a relatively crummy PHP framework like CodeIgniter feels like heaven compared to the burdensomeness and complexity of spring/hibernate. Need a new controller, a few new models, and a couple new views? You can get that done in a snap in any reasonable MVC framework but with spring you'll be pulling teeth and it'll feel like a good day's work if you can get the skeleton working.
It really depends on the size of the project. Having used CodeIgniter for a few projects, and Spring extensively for 2-3 years, there were projects where I really appreciated CodeIgniter - basically self-contained CRUD apps with a bit of originality layered on top - but other times where the CI approach would have led to a lot of pain, as in multi-layered applications that relied on legacy integrations.

I don't think it's unreasonable to prefer the simpler projects that the smaller frameworks are a good fit for, of course! Sometimes though the project is big enough that something like Spring is going to save you time and headaches in the medium and long run.

Are you using an especially old version of Spring? I work with Spring MVC on a pretty regular basis and I've never had that much trouble with defining a new controller/model/view.

Controller: Add an @Controller annotation and some @RequestMappings and you're done.

Model: Usually these have no Spring dependency at all, though there are annotations you could put on some of the fields for various tasks if you'd like.

View: Also mostly unrelated to Spring. Write a Thymeleaf template or JSP and return the name of it from the appropriate controller method.

It's quite fashionable these days to hate xml configuration, and abandoning xml seems to be the way even Spring development is going (Java Config, spring-boot, etc). However, I've found some good points with it too. When you have less java code and more xml, it is often faster to come up to speed on a new spring project because the xml more quickly describes how the project is integrated - maintenance and tweaks can often be more straightforward. In contrast, Java code and annotations often feel friendlier for the actual process of developing.

I do think I prefer the java way more, because it's a bit easier to debug. But once I have some solid java code, I can be tempted to lift out 30 lines of code if it has an analogous 5 lines of xml config.

Usually 10 lines of java, which is already quite verbose turns into 30 lines of xml.
Your last statement about the quote is half true half "but other prog. lang. devs rarely write unit tests and even if they do they write integration tests that requires DB"

I found Spring libraries to be useful. I don't doubt there are people who abused it as well.

Guava usage seems less common compared to Java. This is probably due to much of that type of functionality being included by default with Scala's impressive, if somewhat daunting, collections framework.
I think the database section is going to be a little off. I know that my default stack for applications is Scala + Play + Mongo + AngularJS, however I don't publish many of those to a public github repo. Its going to be the same for MySQL and Postgres as well.
The h2 prominence is certainly a consequence of it being the default choice in Play! applications
yeah i was wondering about that too. is it just because the lib is left in even if it's not being used you think? i haven't heard of anyone using H2 for production, if they are i'd like to know more about how/why
There are probably a lot of lets-try-this-play-and-scala-thing afternoon projects up on github, many of which will just keep the default configuration and never be worked on again.
It's interesting to me that sbt-idea and sbteclipse are in the top projects, when I would think IDEs should just be able to directly import SBT projects. I don't need a Python package to use PyCharm, after all. To me, one big friction point in using Scala in the Coursera course has been the inevitable hiccups in getting projects going in my IDEs (not to mention bugginess and slowness of the IDEs).
Most popular with Scala projects on Github is likely only partially relevant to Scala in actual production use. Sadly we can't really know the usage outside of Github to assess how meaningful this analysis really is.
The Scala projects I've seen are not open-source, but some very interesting work being done in Scala in systems that might surprise you...
Twitter has some nice Scala libraries too: https://engineering.twitter.com/opensource/projects?tags%5B%...
I understand wanting to also track popular SBT plugins, but the title of the post says its about "Libraries" yet includes things like sbt-idea.
Why do I have to sign in with Google to get to the top 100 list?
It's a standard public google drive spreadsheet. you should be able to see it without signing in.