Scala vs Go

<i>&gt; Scala code can be very dense and hard to grok at the early stages of learning.</i><p>This seems to be the crux of his argument, and I think it&#x27;s a rather poor one. I have used both Go &amp; Scala professionally. Yes, it took less time for me to start writing real code in Go. However, I found Go&#x27;s &quot;simplicity&quot; to be limiting and frustrating when it came to building production applications. Things like the weird split between functions returning errors but occasionally panicking, lack of inheritance, and poor dependency management through github links make Go a poor choice for applications within a business setting. Scala does allow for more variance in individual coding styles, but not so much that an experienced Scala programmer can&#x27;t read &amp; understand other peoples&#x27; code with relative ease. It&#x27;s a non-issue during development as long as the team agrees to follow the same set of conventions, just like any other language.

The language complexity comparison based on the number of pages in the spec is incredibly not useful and disingenuous.<p>The Java specification is actually a fairly good specification and also covers a great deal of the runtime (of which Scala gets a free ride).<p>The C specification is 500 or so pages.<p>IMO the Go specification is sorely lacking in details (albeit I must confess written in a much more modern and pithy way). It also doesn&#x27;t have legacy baggage. This isn&#x27;t to say Go is bad or good but you shouldn&#x27;t base your decision on the length of the spec (particularly when formatting also plays a large part).<p>BTW if you are looking for close to the best of both Go and Scala (an in between) take a serious hard look at OCaml. Yes OCaml multicore is not done but it is coming. And in ref to the authors mention of being explicit IMO OCaml is the most <i>explicit</i> language I know (ironic given it has incredibly good type inference).... Oh and for completeness its specification is 657 pages. I actually learned most of the language by reading the spec.

Very similar to the c++ vs c debate.<p>C++ has tons of arguably useful features. But these features also in a way distract from the task at hand - solving a problem. You risk ending up discussing the meta problem too much - how to write and organize code.<p>C on the other hand is very basic, requires a lot of boilerplate and encourages re-implementation. But you are (subjectively) more likely to produce pragmatic code which will solve your problem.<p>Scala is the kitchen zink of languages, i could elaborate but I don&#x27;t even know where to begin.<p>Go is very simplistic and architected to solve some recent problems. It&#x27;s easy to write high concurrency, low latency apps with minimal startup costs. Perfect for microservices. And it explicitly avoids certain complicating features such as generics, while still catering for its use cases by supporting code generation and compile-time constant computation.<p>Go is the rise of New Jersey Style. All developers tormented by c++,ORMs,Java EE,Soap et al join ranks to show the world that &quot;Worse Is Better&quot;.<p>A funny thing is that go is very similar in style to early Java, and I believe that Gosling et al did have the same mindset as Thompson and Pike. But somehow Java got overrun by the enterprise guys, and I don&#x27;t know where they came from. Does anybody here know maybe?

One thing that I like about Scala is that we can use Java Mission Control to analyze how our code (to the &#x27;method&#x27; level,) perform in production. Not just deploy and pray that our code will hold strong enough to handle the load. I only see this feature in Scala and Java --not that we wanna compare in this case,

I&#x27;m learning Scala at my new job (previously worked in Ruby, Python, and long ago, Java and enjoy learning about functional programming). It&#x27;s a fine language with a lot of great things about it...that get tossed the second you touch Java. It&#x27;s wonderful to not have null. Except that you do anyway! My biggest complaint is that it is so multi-paradigm that different systems in our codebase have completely different styles.

Would be interesting to get a gauge on how many bugs are typical in code in each language.<p>From what I&#x27;ve heard Go code features a comparable number of bugs to Python per line of code. But far more lines of code. I don&#x27;t know how that compares to Scala but would be very interested to know.

The analysis is done from the perspective of an imperative programmer.<p>It&#x27;s like someone writing Java-like Python code. When you write in Scala you completely change the way you write code, the whole paradigm.<p>This question could be asked Haskell vs Go, it would be the same IMO.<p>If you have chosen Scala, you don&#x27;t choose it as a Java replacement, you choose it as a programming philosophy replacement<p>Edit: Picking on Scala for lack of network libs is like picking on Go for lack of Category theory libs

Scala is half a decade older than Go and has lead in big data infrastructure projects. Go has lead in container management infrastructure. May be that&#x27;s their niche areas.<p>I would be interested in seeing when they are applied in other&#x27;s domain and how good&#x2F;bad they really are.

As a fan of Scala and a developer who has been distancing himself from anything C-like for a decade, I found this post to be pretty fair. Go seems to force explicitness; Scala can be explicit or implicit depending on who uses it. In general, I find explicit to be preferential to implicit when I&#x27;m trying to learn a code base. BUT, some cases I hate handling explicitly, such as NULL. For those cases, you can limit the need to handle them using Scala.

I&#x27;m curious about the claim (er, &quot;observation&quot;) that<p><i>At scale, the skill level of developers reading&#x2F;writing&#x2F;maintaining&#x2F;testing code is going to be a normal distribution around the mean of &quot;not expert.&quot;</i><p>Has this been researched or shown in any formal way? Or have similar observations been formulated elsewhere?

Worth the read if only for the meme of the dog at the end.

Does it have to be one or the other? They are suitable for different things.<p>You will find it hard to write an enterprise level application with complex domain logic in Go. Go is low level. Scalas type system on the other hand is very well suited for that.<p>Go&#x27;s standard library around networking and crypto makes it the best language of choice for pretty much anything network related. Scala doesn&#x27;t even come close.<p>My opinion in 2017 is Scala and Go (or Go and Scala) _are_ the two best programming languages out there. Learning both is worthwhile and _together_ they cover a very large set of use-cases.

The scala example is plain wrong.<p>import play.api.mvc.RequestHeader<p>def getUserId()(implicit request: RequestHeader) = { request.cookies.get(&quot;uid&quot;).map(_.value.toLong).filter(_ &gt; 0) }<p>Return type is missing, it will throw exception (toLong).

Scala is a very complex languages, allowing tons of construct. And multiple ways to code anything. In any serious, bigger team project, you don&#x27;t wanna use Scala imho. Not forgetting the super ugly stack traces.<p>If you really need functional programming, use a more functional language.<p>If you need speed, consistent code, and lots of developers. Use golang. Its simplifies software engineering.<p>Also if forced to use the JVM, i would chose Kotlin over Scala.

Transportability is an oft under-valued quality when comparing languages. Yes you could write something highly performant&#x2F;compact&#x2F;domain-specialized in perl,scala,lisp etc but when the time comes that your product is successful and your team needs to scale or you want to transfer ownership to another team how easy is that transition going to be?

I don&#x27;t care much about the comparison of these two languages (there&#x27;s some interesting points though), but the &quot;general observations&quot; intro explains very precisely things that I always struggle to communicate.<p>Read it, it&#x27;s a few lines, you&#x27;ve already heard it but it never hurts to be reminded it.

I wanted to like the post and then I read this:<p>&gt; As a developer, the only performance that I care about is my development cycle

You can find a similar comparison here: <a href="http:&#x2F;&#x2F;jimplush.com&#x2F;talk&#x2F;2015&#x2F;12&#x2F;19&#x2F;moving-a-team-from-scala-to-golang&#x2F;" rel="nofollow">http:&#x2F;&#x2F;jimplush.com&#x2F;talk&#x2F;2015&#x2F;12&#x2F;19&#x2F;moving-a-team-from-scala...</a>

I just personally hate seeing a giant method chains in a code block.<p>How do i know how this call chain behaves in production? Where&#x27;s all the logical exit branches from this for error recovery? Is this properly null checking if required?<p>I see this in python and javascript all the time. This style of programming is what i call &#x27;happy path&#x27; programming. It only works properly with valid input.<p>Go forces the developer to explore non-happy path cases during development. This leads to java&#x27;s &#x27;check for null&#x27; boilerplate everywhere. The syntax is ugly however, personally believe that it leads to higher quality systems.

I like Clojure for the same reasons. The simplicity and consistency of the language can&#x27;t be overstated when it comes to writing maintainable code.

In this sort of comparison Clojure looks quite good I think. It gets the full power of the JVM and ecosystem plus the full power of Lisp macros if you really need it.<p>Normally, it&#x27;s a small orthogonal language with a highly typical &#x27;Clojure&#x27; style of writing programs.<p>For people who like Go, they can easily switch to Clojure without relearning Concurrency stuff. They can use core.async just as Go-blocks. To make it even easier you don&#x27;t have to pass around pointers ever, you can just pass around to references to immutable data or safe reference type.

vacuous article.

FIGHT!