9 ms·

Scala vs Go

• danpalmer 10y ago
  Would be interesting to get a gauge on how many bugs are typical in code in each language. From what I've heard Go code features a comparable number of bugs to Python per line of code. But far more lines of code. I don't know how that compares to Scala but would be very interested to know.
  • willvarfar 10y ago
    Complete tangent, but I must say that since I recently started using pycharm it has really caught most of the obvious typo and uninitialized bugs and my python code is really crashing surprisingly rarely as I prototype to death. Just saying in case there are others who haven't been trying modern python tooling and don't know that you can get real close to a compiled language type safety certainty these days before you run a line of code.
    • mi100hael 10y ago
      I get where you're coming from, but relying on an IDE for safety is a recipe for disaster. What happens when you just quickly pop open that file in on a shell to make a small change and fat-finger something? What happens when a different developer decides to use vim for everything? I used Python extensively for years and it's still my scripting language of choice, but to use it to build something safe in a business-critical situation requires an obnoxious number of tests, half of which are basically just type checks.
      • lowmagnet 10y ago
        1) you get an error, and since it's a small change I'd assume you could guess where you caused it. 2) they get errors but they may have more difficulty finding them. (or they use a vim plugin for that, or pylint, etc. on save) I'd guess your ability to suss out an error's cause without an IDE is a matter of comfort with a language, and your lack of ability isn't an IDE's fault.
    • dude01 10y ago
      Speaking of tangents... I use pycharm too. Do you ever use type annotations in Python? I'm really digging it in Typescript for Javascript.
      • willvarfar 10y ago
        (I have my own, and I'm probably the only user ;) https://pypi.python.org/pypi/obiwan/ https://pypi.python.org/pypi/obiwan/ )
        • dude01 10y ago
          Oh wow, thanks for the link. Looks like you discovered typescript way before I did. It looks like Mypy is pretty popular these days. Cheers!
• agentgt 10y ago
  The language complexity comparison based on the number of pages in the spec is incredibly not useful and disingenuous. 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). The C specification is 500 or so pages. 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't have legacy baggage. This isn't to say Go is bad or good but you shouldn't base your decision on the length of the spec (particularly when formatting also plays a large part). 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 explicit 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.
  • lanna 10y ago
    > 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). but isn't the java spec split in two: the java language specification and the java virtual machine specification? (honest question)
    • agentgt 10y ago
      There is overlap and there sort of has to be because of the memory model and reflection if I recall correctly. Certainly the documentation could be more pithy though.
  • bpyne 10y ago
    As I read the author's comparison, OCaml came to my mind as well. Reading Minsky's posts and the Real World OCaml book got me really interested in its capabilities for modern software development. I've heard mixed reviews about the object-oriented features, but the functional ones are solid, expressive, and easy to understand. At home, I started using it as my primary language just a few weeks ago.
• anentropic 10y ago
  FIGHT!
• dandermotj 10y ago
  Worth the read if only for the meme of the dog at the end.
• chipz 10y ago
  One thing that I like about Scala is that we can use Java Mission Control to analyze how our code (to the 'method' 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,
  • MrBuddyCasino 10y ago
    Ops support and transparency is superb on the JVM. That some languages don't even have something remotely comparable is something that didn't even occur to me before expanding my horizon beyond Java.
    • was_boring 10y ago
      Yep, the tooling around Java is absolutely fantastic.
    • pjmlp 10y ago
      .NET is the only serious rival regarding such tooling.
  • pyrale 10y ago
    Is it available only on Java/Scala, or any language on the JVM ? If Java/Scala, do you have an idea of how much work would be needed to exploit the informations from flight recorder in e.g. Clojure ?
    • chipz 10y ago
      it should be available in any language on JVM although I've never tried it myself. It's simple enough, I don't think it would take too much work to get the information from flight recorder.
• geodel 10y ago
  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's their niche areas. I would be interested in seeing when they are applied in other's domain and how good/bad they really are.
  • ebola1717 10y ago
    And that divide is meaningful too. Writing Spark jobs in scala works pretty nicely, thanks to some complicated language features. I have difficulty imagining the equivalent go version being as nice. Meanwhile, go's simplicity is great for low-level performance-critical code.
  • mi100hael 10y ago
    > Go has lead in container management infrastructure. That's a yardstick I didn't realize anyone was using.
  • LOLOLOLO1 10y ago
    Spark is a poor joke.
    • sctb 10y ago
      Please no empty snark like this here.
• pweissbrod 10y ago
  Transportability is an oft under-valued quality when comparing languages. Yes you could write something highly performant/compact/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?
  • alextheparrot 10y ago
    A lot of Scala is written to be that scaling code, see Spark. I know your point was the possible hand-off between teams, just wanted to indicate it is often used as that scaling language in data-processing.
    • LOLOLOLO1 10y ago
      Spark is not just written in Scala, they shared the same philosophy of underthought design. Luckily, there's a little reason of using Spark after Yandex released their Clickhouse: it better compresses data, it is much faster, it doesn't need crazy infrastructure of low quality Apache's code, it can be used in a realtime which is really huge.
  • MichaelGG 10y ago
    Unless your app is so trivial that syntax and APIs are the dominating factor, I'd wager the team transition will have so much other stuff to deal with. Hopefully, not least of all, the actual program logic. And team transitions are rather rare compared to the day to day dev that goes on. Optimising for them seems misplaced.
    • pweissbrod 10y ago
      As a consultant, transitioning your work to maintainers remains a constant concern
• williamdclt 10y ago
  I don't care much about the comparison of these two languages (there's some interesting points though), but the "general observations" intro explains very precisely things that I always struggle to communicate. Read it, it's a few lines, you've already heard it but it never hurts to be reminded it.
• mi100hael 10y ago
  > Scala code can be very dense and hard to grok at the early stages of learning. This seems to be the crux of his argument, and I think it's a rather poor one. I have used both Go & Scala professionally. Yes, it took less time for me to start writing real code in Go. However, I found Go's "simplicity" 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't read & understand other peoples' code with relative ease. It's a non-issue during development as long as the team agrees to follow the same set of conventions, just like any other language.
  • matt_wulfeck 10y ago
    That's part of the authors point and one that's I heartily agree with: Go is not necessarily very nice to program in, but other people who have to read and maintain your code find it very nice indeed that you were forced to be frustratingly simple. This was a design choice by engineers who did constant maintenance and reviews no doubt and I appreciate it every day.
    • yummyfajitas 10y ago
      I don't find Go simple at all, actually. Any individual line of Go might be simpler than many individual lines of Scala. But understanding how the whole system works can actually get complicated, particularly in code where the lack of generics forces type information to be lost. Consider a pipeline: source ~> retryQueue.firstInput ~> requestAttempter requestAttempter.successOutput ~> finalizeResult requestAttempter.failureOutput ~> retryQueue.failureInput This is basically logic to process a stream of messages, successes get finalized, and failures go into a retry queue until they succeed. I've got a large system doing this right now with Akka streams. In Scala, type signatures ensure that everything lines up or else you've got a compile error. In a similar Go system, I lacked stream abstraction (I think Cloudflare has a beta library that does this now) and the lack of generics mean that streams are untyped. For example, what if I pass a `Message` object to `retryQueue.failureInput` rather than a `MessageWithRetryMetadata`? So I don't agree at all that Go code is easier to understand and maintain than Scala.
• etaty 10y ago
  The scala example is plain wrong. import play.api.mvc.RequestHeader def getUserId()(implicit request: RequestHeader) = { request.cookies.get("uid").map(_.value.toLong).filter(_ > 0) } Return type is missing, it will throw exception (toLong).
  • sedro 10y ago
    You don't need to specify a return type in scala. In this case the return type is inferred as Option[Long]. You are correct about the exception if the cookie's value can't be parsed as a Long. You might instead write the code as: def getUserId()(implicit request: RequestHeader): Option[Long] = { request.cookies.get("uid") .flatMap(cookie => Try(cookie.value.toLong).toOption) .filter(_ > 0) } or, equivalently: def getUserId()(implicit request: RequestHeader): Option[Long] = for { cookie <- request.cookies.get("uid") value <- Try(cookie.value.toLong).toOption if value > 0 } yield value
  • jcdavis 10y ago
    function return types are not required in scala, although every style guide I've seen requires them for any non-trivial function
    • mi100hael 10y ago
      I only use them on methods/vals that are intended to be publicly used just so I don't inadvertently change the type of something and break someone else's code. Within private methods, it doesn't really matter.
  • mark242 10y ago
    It's okay, since cookies is a Map[String, String] so running the get returns an Option[String]. If the author is concerned, the way to express this to be more expressive could be something like this: val uidOpt: Option[Long] = request.cookies.get("uid") map { case Some(uidStr) if uidStr.toLong > 0 => Some(uidStr.toLong) case _ => None }
  • dcu 10y ago
    it's funny, this discussion alone kind of proves the author's point
• bpyne 10y ago
  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'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.
• 100k 10y ago
  I'm learning Scala at my new job (previously worked in Ruby, Python, and long ago, Java and enjoy learning about functional programming). It's a fine language with a lot of great things about it...that get tossed the second you touch Java. It'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.
  • mi100hael 10y ago
    > It's wonderful to not have null. Except that you do anyway! If you hit a NPE in Scala, you're doing something objectively wrong. You should be wrapping any calls to Java libraries that may return null with Option().
    • MrPowers 10y ago
      I agree that null should generally be banned from Scala code, but your statement is a little too strong. I use Spark / Scala for big data applications and Option() is slower than null. From the Databricks Scala style guide: "For performance sensitive code, prefer null over Option, in order to avoid virtual method calls and boxing."
  • pyrale 10y ago
    You should try Haskell. It's like doing Scala, but without the Java.
  • orclev 10y ago
    You might also want to check out Kotlin. It's basically what everyone wished Java 8 had been, but wasn't because a) backwards compatibility, and b) difference of opinion (looking at you Optional). We have a set of coding conventions we use for our Java code that includes things like using Optional.empty() instead of null and declaring all method parameters (and as many locals and properties as we can get away with) as final. We've found that using Kotlin allows us to write equivalent code in a far more succinct fashion because all those conventions we follow are the default state in Kotlin, and it's deviating from those conventions that requires extra syntax in Kotlin.
• ascotan 10y ago
  I just personally hate seeing a giant method chains in a code block. How do i know how this call chain behaves in production? Where's all the logical exit branches from this for error recovery? Is this properly null checking if required? I see this in python and javascript all the time. This style of programming is what i call 'happy path' programming. It only works properly with valid input. Go forces the developer to explore non-happy path cases during development. This leads to java's 'check for null' boilerplate everywhere. The syntax is ugly however, personally believe that it leads to higher quality systems.
  • ebola1717 10y ago
    Scala carries some baggage from being on the JVM that makes this not-quite-true, but it mostly enforces all of those things in the type system. There's no null-checking required, and if something can fail, the type system should tell you. e.g. your method signatures will read doSomethingRisky(): Try[Result] and to use that value you'll either have to carry that Try forward, or handle its failure cases.
  • agentgt 10y ago
    > How do i know how this call chain behaves in production? > Where's all the logical exit branches from this for error recovery? Is this properly null checking if required? I see this in python and javascript all the time. This style of programming is what i call 'happy path' programming. It only works properly with valid input. If this is done correctly this fluent pattern is usually a monad. This works really well with typed languages that have variant types that enforce pattern matching like Scala and Rust. This pattern is actually far less error prone than imperative null checking (in my experience) as you have to to deal with the wrapped value but it can be equally tedious if the language isn't expressive. An example of this syntax for Java can be seen in RxJava.
  • pyrale 10y ago
    Learn the functional style, and it will look so much more simple. >Where's all the logical exit branches from this for error recovery? No exit; the error is carried on in the pipe until the end. Successive transformations simply have no effect, since the data is in error. The chain output type can be either the data you want, or an error. > Is this properly null checking if required? Stop using null's. > This style of programming is what i call 'happy path' programming. It only works properly with valid input. The unhappy path can be handled just as well, you merely have to incorporate it in the type of output your system can produce. In that way, errors are also a happy path. > Go forces the developer to explore non-happy path cases during development. [...] The syntax is ugly however, personally believe that it leads to higher quality systems. When I program in a language like Haskell, not exploring unhappy paths leads to code that doesn't even compile. Usually this leads to pretty good quality.
• sly010 10y ago
  Does it have to be one or the other? They are suitable for different things. 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. Go's standard library around networking and crypto makes it the best language of choice for pretty much anything network related. Scala doesn't even come close. 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.
  • pjmlp 10y ago
    I doubt that Go network libraries and crypto libraries are so well battle tested as Java ones, which Scala can take advantage of, specially taking into account the amount of JVM and library vendors.
    • sly010 10y ago
      Scala not having a single well defined networking library and having to revert to using Java is exactly why I prefer Go for networking. Gotta call a http endpoint in Go? https://golang.org/pkg/net/http/ Gotta call a http endpoint in Scala? https://www.google.com/search?q=best+http+client+library+in+scala Perhaps I just don't have enough experience with Scala and I don't know the best practices (maybe everyone just uses akka and apache commons for everything?) yet.
      • pjmlp 10y ago
        Many of us love the polyglot nature of JVM and .NET, and don't mind using the best library, even if written in system language of the platform.
      • saryant 10y ago
        The java.net package already exists. And there's Netty, which is more battle-tested than likely any networking library save BSD's.
• TeeWEE 10y ago
  Scala is a very complex languages, allowing tons of construct. And multiple ways to code anything. In any serious, bigger team project, you don't wanna use Scala imho. Not forgetting the super ugly stack traces. If you really need functional programming, use a more functional language. If you need speed, consistent code, and lots of developers. Use golang. Its simplifies software engineering. Also if forced to use the JVM, i would chose Kotlin over Scala.
  • TeeWEE 10y ago
    def doSomething():Unit = {...} def doSomething:Unit = {...} def doSomething() = {...} def doSomething = {...} def doSomething() {...} def doSomething {...}
    • kodablah 10y ago
      The ambiguous non-equals form will go away w/ Dotty IIRC. And the presence/absence of parentheses are NOT the same thing.
    • adriaanm 10y ago
      Procedure syntax (the last two lines, lacking the `=`) will be deprecated in Scala 2.13. The two variants before those are due to type inference. Are you really arguing against type inference? The empty argument list `()` is a convention to denote that a method has a side-effect, whereas a method with no argument list at all is considered pure.
• strictfp 10y ago
  Very similar to the c++ vs c debate. 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. 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. Scala is the kitchen zink of languages, i could elaborate but I don't even know where to begin. Go is very simplistic and architected to solve some recent problems. It'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. 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 "Worse Is Better". 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't know where they came from. Does anybody here know maybe?
  • eweise 10y ago
    Java was a way For Sun to sell more servers so they pushed it as application server technology.
    • strictfp 10y ago
      But do you know who designed the server tech? Was it old mainframe people?
      • fauigerzigerk 10y ago
        For what it's worth, the initial EJB spec was written by IBM, so I guess the answer to your question could be yes. "The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems" https://en.wikipedia.org/wiki/Enterprise_JavaBeans https://en.wikipedia.org/wiki/Enterprise_JavaBeans
• yogthos 10y ago
  I like Clojure for the same reasons. The simplicity and consistency of the language can't be overstated when it comes to writing maintainable code.
• nickik 10y ago
  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. Normally, it's a small orthogonal language with a highly typical 'Clojure' style of writing programs. 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't have to pass around pointers ever, you can just pass around to references to immutable data or safe reference type.
• dcu 10y ago
  You can find a similar comparison here: http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/ http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala...
  • pyrale 10y ago
    I find this article much more interesting than op. In particular, the focus on keeping functional codebases simple is, I believe, the core of what makes a successful functional codebase. Basically, at some point when working languages like Haskell, Scala or F#, you are given a choice between power and ease-of-hire/onboarding. Apparently, they made the second choice, which I believe is the good one in their situation. I believe it is possible to stick to functional languages and make a team-enforced decision to keep things simple, but the choice of simply opting out of it is also on the table, and I won't blame them for it. I would just have preferred having a simple language AND a great type system.
  • agentgt 10y ago
    Basically replace "Go" in that article with "Java 8". Java 8 makes for a much stronger argument for their situation considering they wouldn't have needed to rewrite any of the Scala code. The author of the article almost admits it multiple times. With really only one point: One of the other benefits of Go was widening the pool of backgrounds we can hire. We can take someone from any language background and have them ramped up on Go in weeks. With the Scala side there’s the JVM learning curve, the Java world of containers, black magic of JVM tuning, profiling tools, etc… Do new developers really need to know about the JVM and tuning? Hell I'm not even an expert with JVM tuning. You can go pretty far with the defaults.... Containers... nobody uses containers anymore. Profiling, debugging, monitoring tools.. ahhh the JVM has the best. You need to profile code regardless of language. That is like saying Go lang developers really need to know about C and calling channels black magic. I don't know of a wider pool than Java.
• monoid 10y ago
  I wanted to like the post and then I read this: > As a developer, the only performance that I care about is my development cycle
• fbunau 10y ago
  The analysis is done from the perspective of an imperative programmer. It's like someone writing Java-like Python code. When you write in Scala you completely change the way you write code, the whole paradigm. This question could be asked Haskell vs Go, it would be the same IMO. If you have chosen Scala, you don't choose it as a Java replacement, you choose it as a programming philosophy replacement Edit: Picking on Scala for lack of network libs is like picking on Go for lack of Category theory libs
  • untoreh 10y ago
    Why do you change the way you write code with Scala? Scala is both functional and oo, Go is also like this except it is minimal at being both
• ninly 10y ago
  I'm curious about the claim (er, "observation") that At scale, the skill level of developers reading/writing/maintaining/testing code is going to be a normal distribution around the mean of "not expert." Has this been researched or shown in any formal way? Or have similar observations been formulated elsewhere?
  • sushisource 10y ago
    I believe Google actually did some research that concluded something to this effect, and it was a big part of why they started pushing Go internally. Whether or not that's the right conclusion based on that data is debatable... I'd argue not.
    • ovidnis 10y ago
      Why not? It seems reasonable to me that as the number of people working on some piece of code grows the average skill will settle around "not an expert", whatever that means.
      • ninly 10y ago
        I'd tend to expect the same (and agree that "not an expert" is vague), but I'm actually a bit more curious about the proposal that it's a normal distribution. Why would it be? If I had to guess, I might go for something downward-skewed, or maybe even some kind of typically bimodal thing.
• deleted 10y ago
  [deleted]
• a_name 10y ago
  vacuous article.