27 ms·

Making the move from Scala to Go

• stcredzero 10y ago
  As it turned out, more flexibility led to devs writing code that others actually struggled to understand. This is what happens in almost every language. Niftyness and the prospect of impressing your coworkers distorts the cost-benefit calculation. This is in addition to the true costs appearing months or years after the code is written, involving the interaction of complex factors, like increased cost of debugging. "Clever" should be regarded as a limited resource. Also, the shop should encourage a culture where "clever" with regards to making code easier to understand should be valued above all else.
  • fbreduc 10y ago
    this is a developer problem not a language issue, i've seen "nifty" code in go just as well..
    • tostitos1979 10y ago
      Some languages make it easy to shoot yourself in the foot with nifty. I found Perl and Scala to be in that camp.
    • stcredzero 10y ago
      The design of a language/environment can sometimes exacerbate this particular developer problem. Because so much of the power of Smalltalk lay in its powerful debugging, weird proxy stuff had a potent impact.
    • Daishiman 10y ago
      Some languages have footguns and constructs that are error prone.
  • michaelchisari 10y ago
    I don't agree that all languages are created equal in this regard. I think that there are cultural norms and expectations that come with certain languages that make them more or less susceptible to "cleverness." For instance, python has never had the problems that ruby or perl had.
    • stcredzero 10y ago
      I don't agree that all languages are created equal in this regard. I never said that. I'm only asserting that no language is completely immune, because hubristic cleverness is intermediate to stupidity and genius. I think that there are cultural norms and expectations that come with certain languages that make them more or less susceptible to "cleverness." Cultural norms can indeed help or hurt.
    • atilaneves 10y ago
      I've seen Ruby-like Python. Just because Ruby makes it easier to do metaprogramming doesn't mean you can't do it in Python.
      • michaelchisari 10y ago
        Of course it's not impossible.
  • WkndTriathlete 10y ago
    Agreed, but they also complained about map() and flatMap(). I have to think that eventually every developer can understand the more straightforward monads, functors, and Either - which, along with type aliases, IMO, can make code a lot more readable. I think the more esoteric features should be reserved for complex code, especially if it's possible that those features can prove runtime correctness at compile time and result in easily-composable modules. I wouldn't expect more than one or two developers to need to develop such a subsystem, however, so the "clever" is used in isolation.
    • faitswulff 10y ago
      The full comment is actually: > No map, no flatMap, no fold, no generics, no inheritance… Do we miss them? Perhaps we did, for about two weeks. So they weren't complaining about map and flatMap, they just missed them.
      • nine_k 10y ago
        They only missed these features for 2 weeks? Good for them! Their problem domain is likely so simple and neat that it fits the Go's limited built-in types well, and does not lead to frequent copy-paste programming. If so, Scala has been an overkill.
        • kjksf 10y ago
          As simple as a distributed, horizontally scalable SQL database, perhaps? (https://github.com/cockroachdb/cockroach https://github.com/cockroachdb/cockroach). Those dumb Go programmers and their toy programs (https://quicknotes.io/n/1XB0 https://quicknotes.io/n/1XB0).
          • nollbit 10y ago
            Software can be complex without having very complex types
          • nine_k 10y ago
  • nrjdhsbsid 10y ago
    I always work with a few developers that complain about my long variable names and aversion to certain shortcuts like ternary operators. They don't understand that unclear code is probably the number one cause of technical debt. Nobody wants to waste time trying to understand it so they start to attach workarounds and it just keeps getting worse. Some of their code is so "clever" that I've refactored the line with 7 method calls just to understand what the hell is going on. Lambdas and fluent syntax make me quiver with fear. In the wrong hands they let you do unspeakable things
    • kbenson 10y ago
      > aversion to certain shortcuts like ternary operators. > They don't understand that unclear code is probably the number one cause of technical debt. At the same time, verbosity can have an obfuscation quality all of its own. For simple assignment, I find a ternary operator very clear and concise, and much preferable to a 5-9 line (depending on style) if/else for a simple assignment. It also might keep you from using the single statement version of if/else if your language supports it, and that's probably justification in itself given how many problems that's caused in the past. Specifically, I think: usefulMetric = wantComplexCalc ? complexCalc(foo) : simpleCalc(foo); is preferable to: if ( wantComplexCalc ) { usefulMetric = complexCalc(foo) } else { usefulMetric = simpleCalc(foo) } even if only because it doesn't obscure intent with what is essentially boilerplate.
      • ludicast 10y ago
        Agreed, plus obviously your "if" statement doesn't do the assignment to usefulMetric. One more way the ternary wins (along with functional languages that use "if"s as expressions).
        • kbenson 10y ago
          D'oh! Fixed. Thanks. :)
        • LgWoodenBadger 10y ago
  • hliyan 10y ago
    As the saying goes: it's easier to write code than understand it. Therefore if you write code as cleverly as you can, then by definition you're not smart enough to understand it...
    • deleted 10y ago
      [deleted]
    • JulianK 10y ago
      For those that like trivia, the original quote I believe is by Kernighan and it's about debugging code rather than writing it, which I feel makes more sense: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" https://en.wikiquote.org/wiki/Brian_Kernighan https://en.wikiquote.org/wiki/Brian_Kernighan
    • nradov 10y ago
      Yes but occasionally there's no other option. I once had to code a parser for a data format with an odd non-BNF grammar with a bunch of special cases. In order to meet the functional requirement for user-friendly error reporting when parsing invalid inputs I was forced to write really clever (in a bad way) code. Fortunately we haven't found any serious defects in it because I don't think I understand it well enough to debug it.
      • arvinsim 10y ago
        It is okay to write clever code if necessary. Solutions to some problems require it. Clever code for the sake of being clever is rarely worthy it.
    • true_religion 10y ago
      I sometimes optimistically believe that my cleverness will increase over time.
  • lacampbell 10y ago
    I'd much rather deal with concise, clever code that has a sane interface and works, rather than sprawling long winded code where everything is void and the same low level constructs are used everywhere. And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".
    • pron 10y ago
      > And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb". There are two problems with this argument. First, brilliance in code is not a property of what linguistic abstractions the code makes use of, but the elegance of the algorithm and engineering. I sincerely doubt that no brilliant code had been written prior to the introduction of your favorite linguistic abstractions. Second, even supposing you're right, what difference does that make? If your code's maintainers are dumb, do you think that you could change this reality by making life harder for them, or is it your job to adapt yourself to the reality of the system you're a part of? When creating something for dumb people to use, is it a sign of good craftsmanship to make it harder for them to work with?
    • nemothekid 10y ago
      >And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb". IMO, the answer is people vastly underestimate the cognitive cost of reading code. "Code" rarely exists in a vacuum, the reader has a universe of inputs, outputs, problems, solutions, failures and goals. The cognitive cost of trying to read someone's code is something that must be paid multiple times per day and at one point do you have to wonder - is the gain in expressiveness for a single programmer worth the cognitive cost of the multiple programmers who have to parse that code. I'd imagine the answer is no - especially for companies that spend more time iterating and patching based on customer feedback than actually designing and architecting systems. My belief is that expressive languages have their place but companies are far more likely to build their software in a "patch-test-iterate" environment which favors less expressive languages.
      • runT1ME 10y ago
        I'll keep repeating myself: the cognitive cost of "code" is dwarfed by the cost of understanding an application. If a couple esoteric languagn features take an extra few hours to learn but reduce LOC tenfold, it's a price I'd pay every time. Not everyone feels this way, the investment to learn these features may not pay off right away, and if you come from a "move fast and break things" language (python/php/js) it can feel like a waste of time.
  • hobarrera 10y ago
    This is one of the extremely cool things about python. There's always one right way to do this, and it's usually pretty obvious. There's also quite clear, standard style guidelines, so code is generally formatted pretty much homogeneously, and tends to be a lot more readable than many other languages.
    • ajyoon 10y ago
      Per the Zen of Python, there should always be exactly one sensible way to do something, but unfortunately this is not often the case. List comprehension can be achieved just the same with functools, itertools, explicit for loops, etc. That said, I do tend to have that mantra a little more present in my head when I'm working with Python.
  • devdoomari 10y ago
    yep... making 'understandable' is really important. But given that discipline, scala would outshine go since scala has much better typechecking than go - e.g. http://getquill.io/ http://getquill.io/ can typecheck against a running DB schema, etc.
  • edejong 10y ago
    This (lengthy) quote comes to mind. If you think it is interesting, please read the whole EWD. EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called “the one-liners”. It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question “Can you code this in less symbols?” —as if this were of any conceptual relevance!— or he just asks “Guess what it does!”. From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. " [1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...
    • galacticpony 10y ago
      I think it is interesting that you left out the very next few sentences, which provide very relevant context: "I see a great future for very systematic and very modest programming languages. When I say “modest”, I mean that, for instance, not only ALGOL 60’s “for clause”, but even FORTRAN’s “DO loop” may find themselves thrown out as being too baroque." While I agree with the general sentiment, it's very important to take anything Dijkstra says with a huge grain of salt. He was a mathematician first and foremost. He obsessed about things like a mathematician. Such people, while very smart, make for very unproductive software engineers. They also have a way of sounding deceptively smart and thoughtful, when really they're just talking out of their ass. Beware.
  • PopsiclePete 10y ago
    It got really bad the past 10 years or so with the "look at what I can do, ma!" blog posts where someone spends 4 pages violating the language in order to get clicks. It's especially endemic in Ruby-land, I find.
• filips_rajesh 10y ago
  First Yammer, then LinkedIn, then Twitter, and now movio.co. The exodus away from Scala continues.
  • dj-wonk 10y ago
    > As a whole, Movio hosts a much broader and diverse set of opinions, so the “we” in this post accounts for Movio Cinema’s Red Squad only. Scala remains the primary language for some Squads at Movio.
  • joneholland 10y ago
    Expedia continues to become larger and larger users of Scala.
  • Cyph0n 10y ago
    Regarding LinkedIn, they are not moving away from Scala AFAIK. And Yammer was a long time ago. Note that Scala has improved quite a bit since then, especially with the release of 2.12.0 (Java 8 support). I don't understand why, but there seems to be a lot of negativity aimed towards Scala. It's a solid language backed by the JVM, has great Java interop, and beautifully combines OOP and FP in a way I've never seen in any other language. Also, ScalaJS[1] is absolutely amazing. Yet every few weeks, you get a blog post detailing why Scala is a failure and how it will be dead in a few years. Seriously, what gives? [1]: https://www.scala-js.org/ https://www.scala-js.org/
    • mahyarm 10y ago
      Using another language that has tooling problems & slow compile speeds, I can understand why that alone would make you not want to use it anymore. After a certain point all of the advantages of the ecosystem starts going away if compile/indexing speeds are not good and tooling doesn't work. Golang was designed from the start to make tooling and fast compile speeds a first class citizen from the start. It has a lot of decisions that make sense when your working with large teams.
      • Cyph0n 10y ago
• Avshalom 10y ago
  Making the move from Go to X, and why we're not going back (2018)
  • clishem 10y ago
    https://mobile.twitter.com/HackerNewsOnion/status/758771091363856384 https://mobile.twitter.com/HackerNewsOnion/status/7587710913...
  • toppy 10y ago
    [meta] That's what movio is about, n'est ce pas? [/meta]
  • amelius 10y ago
    Your article is missing an explanation, i.e. the "why" part.
• ludicast 10y ago
  Scala is the latest whipping boy(1). It's a great language with tons of warts, but it actually acknowledges the warts. Case in point, when (2)Paul Phillips went after Scala (mentioned in the article), Odersky took some of that criticism to heart for the next iteration/rewrite of the Scala compiler. In an industry where everyone doubles down, that's extremely refreshing. Scala's cognitive footprint can lead to misbehaving programmers, but clean Scala has its own elegance if the cuteness is avoided. The slowness I'll give you though :(. 1) I'm old enough to remember this language CoffeeScript that "really really sucked". And then all of a sudden, people were using ES6/TS with parameter destructuring, classes, lambdas, but yeah, CS was the bad guy. 2) Despite his bellyaching, Paul Phillips never really left Scala the language (check his commit log), just the compiler team & lightbend.
  • fineline 10y ago
    "Old enough to remember CoffeeScript" sounds funny to those old enough to remember UCSD Pascal on Apple ][ or RPG2 on IBM System 34's.
  • Daishiman 10y ago
    Well Coffeescript was refreshing in being very terse and introducing a lot of niceties that were missing in JS. It was also trivial to introduce footguns given its whitespace rules and some pretty radical syntax rules. New Javascript has basically taken the best that CS had and wrapped it in the necessary turd that is backwards compatibility in a hastily designed language, but the results speak for themselves and modern JS is just much more pleasurable.
    • jiaweihli 10y ago
      Yes, the frustrating thing was that people previously praised the language _despite_ its obvious footguns. A language where 'dropping parentheses where you can' is idiomatic is a disaster waiting to happen. I don't know about you, but I never want to be holding a footgun, ever.
      • dagw 10y ago
• joneholland 10y ago
  Sounds more like moving away from a big jvm monolith is how they gained their speed. Our Scala based microservices build in seconds. Anyway, no idea who movio is, but cool they like go. Not sure why they needed to write Scala FUD in the process.
  • Daishiman 10y ago
    I think that if you have to move to microservices just to avoid atrocious compilation times that means there's something horribly wrong in the language stack. Microservices should be used to solve architecture problems, not a workaround for compiler slowness.
    • scalatohaskell 10y ago
      just cyclic dependencies between project's generated source codes of exposed interfaces/contracts. ez. It's not hard to fuck up ur sw eng. practices and blame language.
  • tapirl 10y ago
    how about the deploy duration and memory consumption?
    • joneholland 10y ago
      Deploy in seconds as well. We create executable jars using grpc.
      • tapirl 10y ago
        Deploy in seconds is too long. Most Go programs are deployed in less than one second.
• andrewvijay 10y ago
  Really well written. We have a similar story where we re wrote parts of our Java code in go and the build time has reduced from 15m to 3.6m! Coffee break to reading a small medium article.
  • howeman 10y ago
    How much code do you have that compilation is 3 minutes?
    • andrewvijay 10y ago
      Its not go code fully. Its java that takes 3 mins. Go takes very less time like 3-4 secs. Multiple smaller services so we compile only what we change.
      • pjmlp 10y ago
        > Multiple smaller services so we compile only what we change. Also doable in Java.
        • andrewvijay 10y ago
          sure. Never denied. But we are breaking apart that java code part by part. The docker build size is also very small as mentioned in the article. Our app involves lot of bandwidth so we good with smaller containers.
  • namelezz 10y ago
    > the build time has reduced from 15m to 3.6m. Is 3.6m the build time of the remained Java code, the rewritten Go code, or both remained Java and rewritten Go code together?
    • andrewvijay 10y ago
      java ~ 3.4 mins, go - 3-4 secs :D
• deleted 10y ago
  [deleted]
• anonymous7777 10y ago
  ok this is bias. Every language has its pros and cons. Go is not well proven as much as JVM did.
• imh 10y ago
  Looking through the really abstract scala code they linked brings up a problem that really frustrates me in haskell. Why doesn't anybody document their really abstract code? You know it's going to be confusing, so why not help out? If I have a type like def foreignKey[P, PU, TT <: AbstractTable[_], U] ... It's not sufficient to document the function's arguments. You also need to document the type variables! Likewise in haskell with code like f . g x . (h (i x) $ j y z) . k $ aNamedVariable It really isnt' so hard to refactor that into let descriptivelyNamedFunction = (h (i x) $ j y z) anotherDescriptivelyNamedVariable = descriptivelyNamedFunction . k $ aNamedVariable in f . g x $ anotherDescriptivelyNamedVariable It's much larger, but in certain places it prevents so many headaches. It's great that you can put stuff inline, but both communities seem super lax about accepting code that is the opposite of self-documenting. edited for clarity, i hope
  • runT1ME 10y ago
    What do you mean "document the types". They're type parameters... can you suggest better names for the parameters in StrongSyntax?
    • imh 10y ago
      As a small example, let's say I have a typed "agg" function with associated typeclass: class typedAgg t where agg :: t f r a b -> (r a -> b) -> f (r a) -> f b ... To lots of people, that's going to be really confusing. It might be easier if I document that f is supposed to be the type of the table, r is the type of the row, and a is the type of elements in the rows, if that's the intended usage.
      • runT1ME 10y ago
        But I'm saying, if you have a Higher Kinded Type like Strong, what do you name the variables? They don't refer to actual nouns. We're abstracted from that level.
        • imh 10y ago
• runT1ME 10y ago
  It took some of us six months including some after hours MOOCs, to be able to get relatively comfortable with Scala Huh. Yeah, sounds like Go is a really good choice for you guys! For some reason our team is able to onboard new engineers and have them be productive in less than a month...
  • lazzlazzlazz 10y ago
    You're either being a little unfair, or have a very low standard for "productive".
    • kod 10y ago
      No, there's a huge difference in quality of programmers. I've led a team that was productive (by which I mean shipping code that met business goals) within weeks of starting with scala. I've been on other teams where some of the guys still couldn't understand closures after 6 months.
      • codygman 10y ago
        That sounds less to do with quality and more to do with exposure to the functional paradigm.
      • geoka9 10y ago
        > I've led a team that was productive (by which I mean shipping code that met business goals) within weeks of starting with scala. Personally, I like to measure things like that by how fast a team/developer can get up to speed on maintaining an already existing non-trivial codebase in the language. Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Scala.
        • runT1ME 10y ago
          Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Scala. I don't agree. I work on an incredibly large Scala team and a powerful type system gives you a lot more confidence to make everything from minor bug fixes to sweeping refactors. The price paid for having to learn the complexities and power of Scala (which I'll admit is much harder than other languages) pays off in that it lowers the overall application complexity by reducing the need for a plethora of frameworks/libraries. If you write Scala like you'd write a java/python/Go application, you'll have better type inference and a worse IDE, along with slower compile times. Not a great proposition. If you write Scala like a pure functional language that allows you to create powerful libraries and DSLs that make it possible to hack together very reliable applications, you'll be amazed.
• didibus 10y ago
  Worked with a principle engineer once who used language as a litmus test. If you could not understand functional programming like Lisp or MLs, he'd just know not to get you on his team. Obviously, most of the software could be written by monkeys, and only need to produce trivial functionality, in those cases, please switch to Go or at least stick to Java or C#. I say that because in the hands of someone who doesn't know, more expressive languages can cause havoc, and turn really messy. Especially the hybrid languages like Scala.
  • unoti 10y ago
    Leading teams to victory and accomplishing business objectives is an even more important litmus test, in my book. But different strokes for different folks I guess!
    • didibus 10y ago
      But the best thing you can do to improve the team's chances of accomplishing business objectives is to choose its members more carefully.
      • unoti 10y ago
        I agree. But personally I'd be concerned about a team lead who thinks the make or break thing is whether a candidate engineer loves fondling their monads all day.
        • didibus 10y ago
          Ya, it's a little draconian, but in practice it was more nuanced. If you just didn't know those things, it was fine, but if you couldn't learn and eventually understand them...
        • lacampbell 10y ago
          He said languages like Lisps and ML - they're not famous for monads.
      • 10y ago
• overcast 10y ago
  X = the current disliked language of the month on Hacker News Z = latest, most discussed language on Hacker News Making the move from X to Z, and why this is just a marketing campaign from a marketing group.
  • argonaut 10y ago
    I've been on HN for years. Scala has been widely criticized with these exact same criticisms for years. These are all legitimate issues people have, even if you don't think they're valid.
• richardwhiuk 10y ago
  So _four_ developers moved from Scala to Go. 'As you can see, we largely came from the stateful procedural world.' No, you come from the 'my first languages' world....
  • cafebabbe 10y ago
    Ah, the GORILLAS.BAS world...
• mark242 10y ago
  Obligatory "did you try running sbt ~ compile before you started complaining about the compile times" post. It's amazing how the tools for faster turnaround times exist-- the one thing the Scala community needs to do a better job of is clear, opinionated documentation. Also -- https://github.com/scala-native/scala-native https://github.com/scala-native/scala-native -- watch that space.
  • tylerpachal 10y ago
    Could you explain this a little bit? I am just getting into Scala, usually I use `sbt run` and `sbt test` while I am working, then `sbt dist` to package my production app. What does `sbt ~ compile` do ?
    • deleted 10y ago
      [deleted]
    • joshlemer 10y ago
      If you run `~` before any command, sbt watches the directory for any source changes, and on detecting source changes, redoes the command. So `sbt ~compile` will re-compile any new sources as soon as they are saved.
      • jpliska 10y ago
        The use of the ~ here illustrates the problem in the scala world: a lot of surprising bells and whistles. Why not call it watch instead of ~?
        • justinhj 10y ago
          Or just use IntelliJ and you can reload classes while your program is running if you want. Sbt is a very powerful tool but it's not written with readability for new users in mind.
      • Sphax 10y ago
        Wait, how does that help build time exactly ? It may help with the perceived build time, but your CI builds are still taking the same (long) time.
• unoti 10y ago
  I have a simple question. In the article they mentioned they had a concurrency issue with a timed buffer that they later neatly solved with go channels and goroutines. They said that they solved the problem in Scala by moving to the actor model, but that required importing Akka into their project and training everyone how to use Akka. My simple question is: couldn't they have achieved the heart and soul of the actor model by just making an object on its own thread, and talking to that object on a simple synchronized message queue? It's a handful of easy to understand lines of code, and nobody needs to delve into the sea of madness that is learning and configuring Akka and its actor model. In more general terms, it's possible to use Scala as Java that plays well with immutability and functional programming techniques without turning your codebase into an overly complex difficult-to-understand mess. But for some reason people just can't stop themselves. For what it's worth, Elixir hits a real sweet spot of functional goodness, combined with awesome concurrency without getting too deep into bizarre complexity.
  • joshlemer 10y ago
    I think it's becoming a more commonly held opinion in the Scala community that people often tend to go off the deep end with Akka and I tend to agree with that. In particular, I think that most of what people use Actors for can be done with Futures, and what can't be done with Futures can most of the time be done with Akka Agents (http://doc.akka.io/docs/akka/current/scala/agents.html http://doc.akka.io/docs/akka/current/scala/agents.html). And when I use Actors, I tend to want o wall them off in their own place in the codebase, instead of letting the actor-ness touch multiple parts of the code.
  • digitalzombie 10y ago
    Actors should be in a process no? If it's in a thread then it'll take the main process down with it. Erlang's BEAM VM every actor is in it's own process. So if something goes bad then it can be restarted via supervisor. Scala is on JVM and JVM isn't built with concurrency in mind and I think Erlang's BEAM is too good at this. Akka is gimped too, you have to write actor a certain way iirc other wise it takes over the scheduler. BEAM is preemptive, it doesn't matter if you have a for(1) loop, your process/actor can only take some much of the cpu time. I think hands down Erlang is a really really beautiful language for concurrency. It's syntax is ugly but it's such a small language that does everything you need for concurrency. Scala is just big and there are so many way to shoot yourself in the foot and tons of compromises. I also think implicit type is too magical and shot myself in the foot many time using libraries that use implicit type.
• lkrubner 10y ago
  Since they cite me (and my essay from 2014) as part of their decision making process, I want to throw in 2 cents here. They ended up deciding on Go, whereas I have ended up preferring Clojure, yet I agree with a lot of what they say, so I'll try to clarify why I ended up with a different decision than what they made. I understand what they mean when they write: I think the first time I appreciated the positive aspects of having a strong type system was with Scala. Personally, coming from a myriad of PHP silent errors and whimsical behavior, it felt quite empowering to have the confidence that, supported by type-checking and a few well-thought-out tests, my code was doing what it was meant to. There are times when I appreciate the strict type-checking that happens in Java. I do get what they mean. But there are also a lot of times when I hate strict type-checking (in particular, when dealing with anything outside of the control of my code, such as whimsical, changing 3rd party APIs that I have to consume (for some business reason), or even 1st party APIs that feel like 3rd party APIs because they are developed by another team (within the same company) or for some reason we can not fix the broken aspects of some old API that was developed in-house 6 years ago.) Because of this, I have become a proponent of gradual typing. If I am facing a problem that I have never faced before, I like to start off without any types in my code, and then, as I understand the problem more, I like to add in more contract-enforcement. This is what I attempted to communicate in my essay "How ignorant am I, and how do I formally specify that in my code?" [1] I think everyone who works with Clojure sometimes misses strict type-checking. Because of this, there have been several efforts to offer interesting hybrid approaches that attempt to offer the best of all worlds. There is Typed Clojure for those who want gradual typing, and there is more recently Spec. Given what I've written, you might think I am a huge fan of Typed Clojure, but I've actually never used it for anything serious. The annotations are a little bit heavy. I might use it in the future, but for now, I am most excited about Spec, which I think introduces some new ideas that are both exciting for Clojure, and which I think will eventually influence other languages as well. Do watch the video "Agility & Robustness: Clojure spec" by Stuart Halloway. [2] I also sort of understand what they mean when they write this: No map, no flatMap, no fold, no generics, no inheritance… Do we miss them? There are times when we all crave simple code. Many times I have had to re-write someone else's code, and this can be a very painful experience. There are many ways that other programmers (everyone who is not us, and who doesn't do things exactly like we do) can go wrong, from style issues such as bad variable names to deeper coding issues such as overuse of Patterns or using complex algorithms when a simple one would do. I get that. All the same, I want to be productive. And to be productive in 2017 means relying on other people's code. And, in particular, it means being able to reliably rely on other people's code -- using other people's code should not be a painful experience. Therefore, for me, in 2017, one of the most important issues in programming is composability. How easy is it for me to compose your code with my code? That is a complex issue, but in general, those languages that allow for high levels of meta programming allow for high levels of composability. Both Ruby and Javascript and Clojure do well in this regard, though Ruby and Javascript both have some gotchas that I'd rather avoid. In all 3 languages, I find myself relying on lots of 3rd party libraries. I use mountains of other people's code. Most of the time, this is fairly painless. But there are some occasionally painful situations. With Ruby I run the risk that someone's monkeypatching will sabotage my work in ways so mysterious that it can take me a week to find the problem. And Javascript sometimes has the same problem when 3rd parties add things to prototype, perhaps using a name that I am also using. I so far have had an almost miraculous time using Clojure libraries without facing any problems from them. It's this issue of composability that makes me wary of Go. While I sometimes crave a language that simple, I can't bring myself to give up so much of modern languages best features. [1] http://www.smashcompany.com/technology/how-ignorant-am-i-and-how-do-i-specify-that http://www.smashcompany.com/technology/how-ignorant-am-i-and... [2] https://www.youtube.com/watch?v=VNTQ-M_uSo8 https://www.youtube.com/watch?v=VNTQ-M_uSo8
• rodrigosetti 10y ago
  Nice write-up. I wonder if you guys have tried using Scala as a functional programming (_no_ vars, returns, partial functions, exceptions, mutable data structures, etc.) - or just used it like in the stateful procedural world.
  • cdegroot 10y ago
    I think the problem here is that Scala doesn't make any choices for you. Now you're busy having to do a ton of code reviews to make sure that everyone stays within the chosen paradigm, stuff will of course slip through and bite you, and there you are with one big nice mess. Plus, it's too simple to just pull in a Java library which doesn't mesh well paradigm-wise with what you have (or a Scala library for that matter). I've done a ton of Scala and I've been left with the same conclusion as I had waaaay back with C++ - too many potential solutions, too many pitfalls and ways to make a mess. I guess I'm a person that wants to make the language make the paradigm choice for me and then I'll happily stick with that. One reason I like a language like Elixir so much - the language made the choices, it matches the problem set I work on pretty well, all the libraries look the same, life is simple, I can just write code (instead of trying to understand a moderately complex build.sbt file which basically comes with a paradigm of its own).
• kev009 10y ago
  I would consider Scala a far better language from a safety, syntax and design perspective. Go is compelling due to the low GC pause times, and to some extent the community for some types of software. I would imagine switching between these to be quite rare. I would expect more movement from Scala to Swift or perhaps Rust.
• _Codemonkeyism 10y ago
  Maintaining a Scala code base for some years, I've learned a lot. I would not go back to a language that does not support Option/Maybe and map/flatMap. These really changed my coding style. My largest problems [1] are all still there after years, developers only payed lip service and that killed Scala I think. The largest bad design decision was to support inheritance which leads to it's own problems with type inference. Sad that after Java devs already recognized how bad inheritance is that Scala also got inheritance. The sticking out problems is how very very very slow Scala compiles. This makes web development (even with Play) and unit testing a huge pain (and the complicated syntax + implicits + type inference makes IntellJ as an IDE very very slow on detecting problems in your code) Concerning the article I do think Futures are a more powerful (and higher) concept compared to coroutines. They are easier to combine IMHO [2] Now trying Kotlin for the faster IDE and compilation speed, sadly the Kotlin developers think Option is only about nullable Types (it's not and something differen!) and don't embrace it. [1] http://codemonkeyism.com/scala-unfit-development/ http://codemonkeyism.com/scala-unfit-development/ [2] http://codemonkeyism.com/a-little-guide-on-using-futures-for-web-developers/ http://codemonkeyism.com/a-little-guide-on-using-futures-for...
  • adriaanm 10y ago
    The only thing on your list on your blog [1] that's still true is that we care about PL research. Since 2.10, we've worked really hard on improving the migration between major versions, and the feedback has been very positive. We'll keep working on finding the right balance between ease of migration and fixing issues in the libraries. Scala 2.13 will be a library release, with further modularisation of the library (towards a core that we can evolve much more slowly, and modules that can move more quickly, but where you can opt to stay with older versions as you prefer). We've also invested heavily in incremental compilation in sbt. Sbt is meant for use as a shell, and it's super powerful when used like that. When I'm hacking the compiler in IntelliJ, recompiles of some of the biggest source files in the compiler (Typers.scala, say) take just a few seconds. I rarely have time for office chair sword fights anymore. With Scala 2.13, half of my team at Lightbend is dedicated to compiler performance. We'll have some graphs to show you soon, but our internal benchmarking shows our performance has steadily improved since 2.10.
• coconut_crab 10y ago
  My company also have a lot of problems with Scala, both technical and non technical ones, but so far we have managed to control it: - As for slow compilation times, incremental building helps a lot. - Intellij works most of the time, and if it doesn't a few type annotation will fix it. - It's very hard to find people with Scala experience. We have given up on finding those and decide to train people from the beginning for 2 months. I myself studied mechanical engineering in university and I can code just fine after a few months. - The language itself is very complex, so we let more experienced programmers write the backbone/framework/library/common parts and the less experienced one do the code glueing-job. That way we can have Scala type safety and expressiveness without scaring the juniors. IIRC one company used Haskell also do the same and they said it is very hard to introduce runtime bugs because almost everything were caught during compile time, "If it compiles, it works". You may ask why going through so much trouble just to use Scala. There are many reasons (speed, type safety etc..), one of them is that we can be immensely productive when needed, the conciseness of the language combine with a powerful type system let us implement complicated features rapidly without very few bugs. IMHO Scala strives to combine both FP and OOP on top of JVM so a lot of tradeoffs had to be made. The developers have to learn a lot of concepts and have good self discipline, but in exchange we can write fast, robust systems and even enjoy it. (Edited for better formatting, this is my first time posting here.)
  • gazarullz 10y ago
    +1 for "If it compiles, it works" .... been there done that ... multiple times !!! And yes in the beginning the feeling of "it works on the first run" was just strange and it get me some time getting used to it
• bad_user 10y ago
  Some notes: - the actor model, along with the Akka implementation, has nothing to do with functional programming; and it isn't orthogonal either, since an actor's mailbox interactions are definitely not pure, with actors being stateful and at the same time non-deterministic; in general if you place those in the same article, there's a high probability that you never did functional programming; and if you did actual functional programming (as in programming with mathematical functions), then you wouldn't want to go back to a language that makes that impossible ;-) - Akka actors are not the only game in town for processing data, you can also use Finagle, FS2, my own Monix and even Akka Streams; And yes, concurrency often requires multiple solutions because there's no silver bullet and Go's channels suck compared with what you can do with a well grown streaming solution - Scala's Future are not meant for "hiding threads" and 1:1 multi-threading is actually simpler to reason about, because if that fancy M:N runtime starts being unsuitable (because lets be honest, most M:N platforms are broken in one way or another), then you can't fix it by choosing a more appropriate solution without changing the platform completely - Your devs are maybe lazy or maybe they don't give a fuck, but given that you're supposedly dealing with concurrency in your software, if those developers struggle with a programming language, then it's time to invest in their education or hire new developers, because the programming language is the least of your problems - Paul Phillips still works with Scala and he most likely hates languages like Go, so when you mention him or his presentation, it definitely cannot be in support of Go
  • 16bytes 10y ago
    I don't understand the claim that Akka actors are both impure and non-deterministic. If your actor is communicating only through its inbox, then it is both pure and deterministic. Given the same set of messages in the same order, you arrive at the same actor state. Sure, you can do wacky things with side-effects, but that's not akka's fault. > in general if you place those in the same article, there's a high probability that you never did functional programming; and if you did actual functional programming This sounds a lot like the "no true Scotsman" fallacy. I'm not attacking your argument here, but perhaps you could expound upon that first point and clarify.
    • 10y ago
• jorblumesea 10y ago
  Scala is an excellent language from a safety and design perspective. It's biggest flaw is the lack of a corporate sponsor and higher barrier of entry. Map, FlatMap, Options are all really great but hard to grok at first.
  • adriaanm 10y ago
    Thanks, glad you like it! We at Lightbend (my employer) don't think of ourselves as very corporate, but we definitely sponsor Scala development. My team is hard at work on Scala 2.13 (well, except the part of it that's commenting on HN stories).
• adriaanm 10y ago
  [Scala team lead at Lightbend here] I'm always eager to learn how we can improve Scala, especially as we kick of the Scala 2.13 cycle (hard at work on compiler performance and standard library improvements). Email is 'adriaan.at("lightbend.com") Regarding Scala's growth, I will leave you with https://www.indeed.com/jobtrends/q-scala.html https://www.indeed.com/jobtrends/q-scala.html.
  • koevet 10y ago
    For completeness: https://www.indeed.com/jobtrends/q-scala-q-golang.html https://www.indeed.com/jobtrends/q-scala-q-golang.html
    • rubenv 10y ago
      Or for those who don't call it "golang": https://www.indeed.com/jobtrends/q-scala-q-golang-q-go.html https://www.indeed.com/jobtrends/q-scala-q-golang-q-go.html
      • misja111 10y ago
        The extra keyword 'go' that you added will return all job postings that have any occurrence of the word 'go' in their description. See for another example: https://www.indeed.com/jobtrends/q-scala-q-golang-q-description.html https://www.indeed.com/jobtrends/q-scala-q-golang-q-descript...
      • furrydog 10y ago
        "Go" the language is tricky to search for as just the word "go", so I wouldn't read much into that. Many job ads contain the word go, but have nothing to do with go the language. e.g. "...go to our website..." "...go above and beyond..." etc.
    • virtualwhys 10y ago
      Well, more accurately would be to compare Scala to other languages[1] that operate in the same space (OO/FP). [1] https://www.indeed.com/jobtrends/q-scala-q-haskell-q-ocaml-q-clojure-q-ceylon-q-f%23-q-kotlin.html https://www.indeed.com/jobtrends/q-scala-q-haskell-q-ocaml-q...
• diminish 10y ago
  "..it felt quite empowering to have the confidence that, supported by type-checking and a few well-thought-out tests, my code was doing what it was meant to. " Does this mean that on what software is "meant to do" type checking covers most test cases and only few additional is needed to ensure iy does what it's meant to do?
  • maloga 10y ago
    That's not what I meant to emphasise, but kind of. I was contrasting the Scala programming experience to this: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ which seems to be pretty much the point expressed by the Coursera people in the blogpost I quoted from them.
• bsaul 10y ago
  Wonder where they'll go once their codebase becomes crippled with interface{} type and nil pointers check, and they stop using chanel to return to mutex for performance reasons, or more control. Note : sounds snarky, but it's an honest question i find asking to myself after having tried many server side techs and feeling limited with go.
  • Sphax 10y ago
    Probably nowhere because 1) never happens 2) is a non-issue and 3) too probably 99% of the time.
    • stymaar 10y ago
      1) I have a totally different experience ! When your are writting code which must have a certain degree of genericity you end up having a ton of interface{} … 2) wat ? How having a null pointer a non issue ?! Empirically it causes fewer bugs than in Java or JavaScript, but it's still a really common source of bugs in Go. 3) I've never run into this kind of problem myself since I dont use Go for performance-heavy code.
• misja111 10y ago
  In my experience, the larger your codebase, the more you appreciate these features: - a strong type system - a pure functional language so you have referential transparity - an IDE that helps you with refactoring If your project is small than you can do without all of those, actually they might even slow you down. When I read the article, I get the feeling that this particular team was working on a small codebase.
  • stymaar 10y ago
    The author also complains about the sub-optimal IDE experience with Scala and then says he moved to a langage that has none …
• hocuspocus 10y ago
  Some points might be valid it's really hard not to dismiss the whole article when you write things like this: > The funny part is that, because dependency hell is so ubiquitous in Scala-land (which includes Java-land), we ended up using some of the projects that we deemed too complex for our codebase (e.g scalaz) via transitive dependencies. First, I've just checked, there are 237 dependencies in my classpath, and it never caused me any issue. Dependency management is a complex problem, but the JVM ecosystem does a pretty good job at it. Binary incompatibilities that are specific to Scala are pretty much non-existent today outside of very specific cases. Secondly, why use stuff that you deem too complex and then complain that it is? Transitive dependencies are just that, transitive. I have Cats and Shapeless in my classpath and I haven't found yet the need to use them in my own code.
  • cdegroot 10y ago
    It is too bad though that e.g. IntelliJ cannot tell the difference, will offer you the transitive dependency's stuff in code completion, and now you are tied to it. Of course, the thing _you_ used went away in the newer version that the newer version of your direct dependency uses, and now you're spending time figuring out dependencies instead of writing code. Which, in my experience, happens pretty much all the time in Java/Scala land. (and I won't start about the sorry state of build tools for the JVM; seen them all, nothing is as nice as what I'm using now (Elixir/Mix)).
• unscaled 10y ago
  This mentions weak IDE support as one of Scala's pain points, but Go has very much the same problem, and the language is vastly less complex. The two best IDEs for Go right now IMO are VS Code and the EAP Gogland, but both of them are not yet on par what you get with Java. VS Code has only support for very rudimentary refactoring (renames) and relies on a rather slow horde of external CLI linters (executed on save) to provide code analysis. Gogland has pretty nice refactoring, but its built-in code analysis is still too shallow. Both will get better, but I can't take the claim that you'd move to Go from another language due to "lack of a good IDE". If you want the best IDE move to Java (or Kotlin, or C#) and never look back.
  • mmargerum 10y ago
    Not really. Emacs works great because of tools like godef and gofmt. If guis is your thing https://www.jetbrains.com/go/ https://www.jetbrains.com/go/
    • unscaled 10y ago
      I explicitly mentioned Gogland (the Jetbrains IDE). I'm not a fan of heavyweight editors (including emacs), and I'd gladly just use vim for Go if vim-go had refactoring support beyond the useless gorename. Gofmt works nicely across the board, but godef needs your entire package to compile as far as I remember. Neither of them gives you refactoring support, and gorename doesn't give you much either. You seem to think godef/gofmt is enough which is fine, but in this case Scala has the same level of support as Go.
  • geodel 10y ago
    Go can be written without good IDE. I just use Sublime with Go plugin it works great. Also Gogland gives sub-par experience to many experienced Go users. E.g. it does not use `gofmt` but their own formatter which they use for all IDEs. Not sure about their refactoring tool but `gorename` seems to me fine refactoring tool.
    • FrancoDiaz 10y ago
• taylodl 10y ago
  Felix looks like an awesome programmer! :)
• gbersac 10y ago
  If I had too move away from scala I would rather consider swift. Could anyone help me compare those two languages ?
  • drhurdle 10y ago
    http://hyperpolyglot.org/rust http://hyperpolyglot.org/rust Here is a pretty good comparison between Rust/Swift/Scala
• DrBazza 10y ago
  Stroustrup is right, there are languages that people complain about, and languages that no-one uses. Go is now firmly in the former camp. Even if the complaints are always generics and error handling.
• cjauvin 10y ago
  Having this smartness disparity between devs is really bad for team dynamics, and complexity leads invariably to this. More and more I believe this to be a profound truth.
  • dasmoth 10y ago
    This seems like an argument for the lowest common denominator. What should programmers who enjoy working with more powerful abstractions do?
    • blacksmythe 10y ago
      >> What should programmers who enjoy working with more powerful abstractions do? Work on teams where the lowest common denominator is higher.
• eternalban 10y ago
  And they could have just used Java from the beginning.
  • geodel 10y ago
    And how do you propose to offset the benefit of smaller image size and lower memory usage?
    • eternalban 10y ago
      I see. Smaller image size and lower memory usage was the critical factor informing the decsion to use Scala and not Java? If we're talking server provisiong cost bread ($) I think factoring in the costs of stack switch, code rewrites and salaries should be on the table too! p.s. Have been writing Go code since the day it was released. My comment has nothing to do with their decision du jour.
• justinhj 10y ago
  Some experience to share: I studied Scala and FP on the side before jumping to a team that was using it in production. Most of the engineers on the team have an enthusiasm to learn about and use fp. Bi-weekly we have a book club where we take turns presenting a topic from functional programming in Scala, functional reactive domain modelling and others. We program as simply as possible but when a new technique is discovered we go ahead and use it after it's been presented to the team and everyone is comfortable with it. all code is reviewed and unreadable code does not pass Compile times haven't been an issue. As an example a 100k line Scala program with around 900 files takes around 2 minutes to rebuild whilst incremental changes are immeasurably fast. Reloading code while a local server is running is easy by default in IntelliJ. Using worksheets for playing is often useful. we don't use actors where streams would make more sense and vice versa, know the purpose of your tools I've had bad experiences with Go. I know that for the application I'm working on it would not scale to 10 programmers working and constant refactoring due to business goals changing.
  • alexbanks 10y ago
    What magical place do you work that allows for this level of engineering quality? > all code is reviewed and unreadable code does not pass Sounds quite nice.
    • justinhj 10y ago
      I work at a mobile games company called IGG
    • lewapkon 10y ago
      Thorough code review is a great process that should be used in every company.
      • alexbanks 10y ago
        Keyword: Should
  • SatvikBeri 10y ago
• noelwelsh 10y ago
  I think this team was doomed from the start. If you come from an imperative programming background, as this team did, (typed) FP is a new way of thinking. It takes a long time to adjust to this new mindset, particularly if you've been programming in imperative languages for a long time. Go, on the other hand, is more of the same. It doesn't seem that anyone on the team had a background in typed FP, and it doesn't seem that they had any support from the organisation to make this shift. I'm not surprised it took them a long time and didn't end well. Learning new things is hard and until universities and other training providers start teaching FP these kinds of stories will continue. (The alternative, to have companies investing in training and mentoring [plug: my company provides these services for Scala] doesn't appear to be likely en-masse, even though it would be radically cheaper than throwing away code.)
  • tapirl 10y ago
    They just want a language more efficient to do develop/test/deploy loops. Yes, Go does much better than JVM based langauges from this point.
• eternalban 10y ago
  You know, this really needs to be said: Does this company have 'adult' technical supervision or what?
• eklavya 10y ago
  I don't know, types help me think. I get lost real soon without them and the reason why I could never pick up any Lisps. In Scala/Haskell I can come up with a solution incrementally and types are the biggest reason why. I always have that feeling that I am missing out on the trumpeted awesomeness of Lisps but I can never justify using them. Maybe there is a personal angle to language selection but I just can't help but feel types are the future and a real advancement of technology.
• jksmith 10y ago
  "Part of my frustration with Scala (and Java) was the feeling that I was never able to get the full context on a given problem domain, due to its complexity." This. Same with any other kitchen sink language.
• s1gs3gv 10y ago
  All this whinging about compile speed ~LOL~ I remember when software development was a gentleman's game and we looked forward to sharing a half hour together in somebody's office or around the railing or coffee pot to exchange ideas and news while the build finished. Scala is good. Its not perfect, its not appropriate for every situation, but its worth learning and using. Go has an anachronistic feel about it that is just, well, ugly.
• AzzieElbab 10y ago
  wrt to programming languages, going from scala to go is like going from english professor to honey boo boo. go is basically new php with lots of ftm features baked in. scala, for all it's flows stays true to it's goal - it is a scalable language. use as mush of it as you are comfortable with and keep growing. here is btw one of the "coolest" features of go in scala http://storm-enroute.com/coroutines/docs/0.6/101/ http://storm-enroute.com/coroutines/docs/0.6/101/