BAbad_user·Oct 31, 2014
Thanks for the feedback, will do :-)
https://github.com/alexandru/scala-best-practices/issues/14
In Scala Best Practicesalexandru
scala-best-practices
Learning & Reference2014–2017
alexandru / scala-best-practices
scala-best-practices
A collection of Scala best practices
4Distinct people
10Mentions
0Explicit recommenders
4.3KGitHub stars
What to know before exploring
What it is
A collection of Scala best practices
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 6:59:22 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month10 dated mentions
Observed mentions: 2014-10-22 22:13:41 UTC to 2017-01-25 14:04:02 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Oct 2014 | 2014-10-01 00:00:00 UTC | 2014-11-01 00:00:00 UTC | 6 | 2 | 4 |
| Nov 2014 | 2014-11-01 00:00:00 UTC | 2014-12-01 00:00:00 UTC | 2 | 0 | 2 |
| Dec 2014 | 2014-12-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2015 | 2015-01-01 00:00:00 UTC | 2015-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2015 | 2015-02-01 00:00:00 UTC | 2015-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2015 | 2015-03-01 00:00:00 UTC | 2015-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2015 | 2015-04-01 00:00:00 UTC | 2015-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2015 | 2015-05-01 00:00:00 UTC | 2015-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2015 | 2015-06-01 00:00:00 UTC | 2015-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2015 | 2015-07-01 00:00:00 UTC | 2015-08-01 00:00:00 UTC | 0 | 0 | 0 |
| Aug 2015 | 2015-08-01 00:00:00 UTC | 2015-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2015 | 2015-09-01 00:00:00 UTC | 2015-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2015 | 2015-10-01 00:00:00 UTC | 2015-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2015 | 2015-11-01 00:00:00 UTC | 2015-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2015 | 2015-12-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2016 | 2016-01-01 00:00:00 UTC | 2016-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2016 | 2016-02-01 00:00:00 UTC | 2016-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2016 | 2016-03-01 00:00:00 UTC | 2016-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2016 | 2016-04-01 00:00:00 UTC | 2016-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2016 | 2016-05-01 00:00:00 UTC | 2016-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2016 | 2016-06-01 00:00:00 UTC | 2016-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2016 | 2016-07-01 00:00:00 UTC | 2016-08-01 00:00:00 UTC | 0 | 0 | 0 |
| Aug 2016 | 2016-08-01 00:00:00 UTC | 2016-09-01 00:00:00 UTC | 1 | 1 | 0 |
| Sep 2016 | 2016-09-01 00:00:00 UTC | 2016-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2016 | 2016-10-01 00:00:00 UTC | 2016-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2016 | 2016-11-01 00:00:00 UTC | 2016-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2016 | 2016-12-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2017 | 2017-01-01 00:00:00 UTC | 2017-02-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
6 sourcesUseful resource, but as often happens with lists of best practices, I do not agree with some things Twitter is giving advice on.
For example - https://twitter.github.io/effectivescala/#Control structures-Returns
They are saying that "return" can be used for "reducing nesting". First of all, that's a lie - if a return exists in that code, doesn't mean that the branch no longer exists, it only means that it isn't explicit and far more effective for reducing nesting would be to break those functions in smaller ones. I happen to believe that usage of "return" in Scala is never appropriate and it was a design mistake; at the very least they abstained from adding "break" or "continue". Scala is an expression oriented language and really, if you're going to write Scala as if you'd write Java, then just pick Java because Scala, contrary to other
Read the rest
people's opinions, is not a better Java in the sense that it actively works against you if you're doing things like that.
I tried outlining the rationale in this rule, which I consider to be non-optional (hence the usage of MUST, instead of SHOULD :)) - https://github.com/alexandru/scala-best-practices/blob/maste...
> In the absence of destructive updates, you either need to copy matrices or use a data structure that typically incurs a log(n) overhead with a fairly large constant.
That is not true - first of all, log(n) in our industry means log2(n). Scala's Vector for example is a log32(n), which given that the max size is Int.MaxValue, can be treated as constant access as far as algorithmic complexity is concerned. Persistent HashMaps are also implemented (instead of self-balancing binary trees), which again means less than log2(n). And Scala's Queue for example is O(1) for both enqueue() and dequeue() - it's just that every "n" operations it has to invert a list of pending items, which takes "O(n)" but given that it happens every "n" operations it is amortized.
It's not algorithmic complexity that bites you, algorithmic complexity is totally fine.
Read the rest
The real problem is more low level, with the indirections happening due to usage of pointers. Depending on memory usage patterns, persistent data-structures could stress the GC enough to increase the number of stop-the-world pauses. Also in a multi-threading context, when you keep the pounding on the same reference holding an immutable data-structure, you drive the contention to the root of that tree and that is less efficient than a specialized mutable data-structure that can distribute those locks in multiple buckets ... but still far better than synchronizing on a standard mutable data-structure.
Actually, which is better in terms of performance depends on context. For example if you have shared reads, then an immutable data-structure is better because you do not need to synchronize those reads.
Also - I did work on a web service that was hit with tens of thousands of requests per second and because of the architecture we've built (asynchronous single producers, multi consumers), usage of immutable data-structures wasn't an issue and it was much saner. AND most people working on most project never end up with such hard optimization issues.
Therefore fear-mongering about something that in practice really is not an issue is not helpful, especially given the sanity that usage of immutable data-structures brings. See this other rule I added - https://github.com/alexandru/scala-best-practices/blob/maste...
Hello @brudgers,
The intent of this list isn't to scare people or to make them follow my conventions.
When working within larger teams, regardless of language, you need a list of do's and don'ts. And powerful or unfamiliar languages are especially problematic for rookies - because they need to make choices (e.g. what abstraction should I use to model this or that and before anybody mentions Python's philosophy - as an ex-Python developer I must say that it has led to horrible non-orthogonal choices).
I do not believe in imposed choices - mimicking what other people's are doing without understanding the reasoning behind it can lead to really awful hairballs, as anybody that worked within an enterprise-ish team can attest to. For example in this rule I'm trying to undo the damage done by another "best practice" that people are mindlessly fo
Read the rest
llowing - https://github.com/alexandru/scala-best-practices/blob/maste...
Also many rules in that list are not necessarily related to Scala - does a language protect you from horrible, convoluted and big functions that do too many things? Of course not. Does a language keep from storing dates without timezone info? Of course not.
It's a work in progress though, feedback appreciated.