6 ms·

I'm a bit confused. I have been told multiple times by Scala users that Scala compile times are a non-issue.

sulam 9y ago
Depends on the size of the code base, how good your incremental compilation is, and what percentage of the code changes frequently. At Twitter the values are: large, great, and relatively high.
davedx 9y ago
I'm an intermediate Scala user. Scala compile times hurt my productivity significantly. Our best Scala developer says his approach is "I know the language so well, I usually write the whole feature in one go before compiling. That way I avoid the slow compile times." Which feels to me like you will miss one of the advantages of having a compiler in the first place - that it helps you write correct code. To be fair, in an IDE you do get some of the compiler feedback in real time. But not for the whole code base, if you're working on things that have high coupling with other modules then it can be really painful. (I'm looking at you, Spray serialization!! Ugh)
eip 9y ago
I don't have any issues with compile times. But I don't work on an underpowered Crapbook Pro. If you are serious about your work and time than use serious hardware. You don't see see F1 racers show up on race day with a Scooty Puff Jr..
lmm 9y ago
They're not a complete non-issue. They're just much less of an issue than not using Scala. (And bear in mind that Twitter has literally the largest Scala codebase in the world. Almost all scala programmers work on something an order of magnitude smaller, with correspondingly smaller compile times)
qingwei91 9y ago
It depends on project size, twitter likely have some really huge scala project, but many organization are now going for microservices, so compile time is less of an issue
atemerev 9y ago
I am a Scala engineer since 2010. We adapted, incremental compilation works, and a few seconds for each new change is OK, more or less. But faster compiled languages still _feel_ better.
- harveywi 9y ago
  >incremental compilation works Not for me. There are hot zones in my code that I dare not touch unless I want to trigger an extremely long recompile. This really sucks.
  - gmartres 9y ago
    you might want to give sbt 1.0 a try, it features better incremental compilation support: https://developer.lightbend.com/blog/2017-04-18-sbt-1-0-roadmap-and-beta1/#zinc-1-class-based-name-hashing https://developer.lightbend.com/blog/2017-04-18-sbt-1-0-road...
    - harveywi 9y ago
      Thanks for the tip! Unfortunately I'm bolted into Play Framework, which does not seem to be compatible with SBT 1.0. :(
nicktelford 9y ago
I've seen a lot of complaints about Scala's compilation speed (I believe it's either the 1st or 2nd most common complaint), but I've not really had any issues myself. Could people who have had issues with compilation speed explain their workflow, I'd like to better understand the problem. For example, here's my general workflow: 1. code in IntelliJ until the feature/fix is complete, and there aren't any red-wavy lines in my source tree 2. run `compile` in an already running sbt session. As a result, I only find myself "waiting" for a compile a few times a day. And even then, because I'm using the incremental compiler it's usually only a few seconds. The only reason I run the sbt compile at all is because the IntelliJ compiler is known to be a bit buggy, especially around things like implicit resolution and some of the more advanced features used for abstract programming. I have seen CI builds take some time, but even then, in every project I've worked on, the complete compile-time is dwarfed by the time taken to run tests. I'm not trying to dismiss problems that others have; I would love to learn more about them!
- harveywi 9y ago
  Here is one that I run into frequently. You're building a CRUD app, but want some semblance of sane FP interaction with your database. So you use Doobie [1] because free monads and all. So you type your query using a Doobie SQL string interpolator... sql"SELECT ItemId from dbo.Item WHERE IsOnSale = TRUE" ...but then you forget all of the ".query[Int].vector.transact(tx).unsafePerformSync" crap that you are supposed to tack onto the end of the string to actually run your query. What are your options? 1. Type a '.' character in your IDE and watch it crash while the presentation compiler thrashes around, sifting through a combinatorial explosion of implicit values (or whatever it is that makes it so slow). You quickly learn to stop using autocomplete. In a sane world, this should take milliseconds and you should quickly get a list of methods to guide you down the right path. 2. Type a '.' and try to recompile. Wait 30 seconds. While you're waiting, what work can you possibly do??? None. 3. Stop what you're doing, open up The Book Of Doobie [2], try to remember which page has the syntax that you need for doing this one simple thing, go to that page, navigate to the right part of the webpage, read the crap, think a bit, copy/paste it into your code. This FEELS more productive than (2), but is it really? This is just one example, maybe not terribly compelling, but it happens. People (well at least me) have a limited amount of memory for administrivial crap to hold in our heads while we try to get our work done. Tooling is supposed to help with that, but with Scala it really starts to get in the way. Flow state just isn't possible. I have heard anecdotes of developers running two or more instances of scalac so that they can work on more than one feature at a time in order to not completely waste away their time. Imagine the context switching there, and having to pay attention to the little oven timer and switching context when one compiler is finally done recompiling the same code it already compiled hundreds of times. [1] https://github.com/tpolecat/doobie https://github.com/tpolecat/doobie [2] http://tpolecat.github.io/doobie-scalaz-0.4.2/00-index.html http://tpolecat.github.io/doobie-scalaz-0.4.2/00-index.html
AzzieElbab 9y ago
One of the huge benefits of strongly typed language is the ease it introduces to managing large code bases. Now imagine google size monorepo and scala compilation speed

Depends on the size of the code base, how good your incremental compilation is, and what percentage of the code changes frequently. At Twitter the values are: large, great, and relatively high.

davedx 9y ago

I'm an intermediate Scala user. Scala compile times hurt my productivity significantly. Our best Scala developer says his approach is "I know the language so well, I usually write the whole feature in one go before compiling. That way I avoid the slow compile times." Which feels to me like you will miss one of the advantages of having a compiler in the first place - that it helps you write correct code. To be fair, in an IDE you do get some of the compiler feedback in real time. But not for the whole code base, if you're working on things that have high coupling with other modules then it can be really painful. (I'm looking at you, Spray serialization!! Ugh)

eip 9y ago

I don't have any issues with compile times. But I don't work on an underpowered Crapbook Pro. If you are serious about your work and time than use serious hardware. You don't see see F1 racers show up on race day with a Scooty Puff Jr..

lmm 9y ago

They're not a complete non-issue. They're just much less of an issue than not using Scala. (And bear in mind that Twitter has literally the largest Scala codebase in the world. Almost all scala programmers work on something an order of magnitude smaller, with correspondingly smaller compile times)

qingwei91 9y ago

It depends on project size, twitter likely have some really huge scala project, but many organization are now going for microservices, so compile time is less of an issue

atemerev 9y ago

I am a Scala engineer since 2010. We adapted, incremental compilation works, and a few seconds for each new change is OK, more or less. But faster compiled languages still _feel_ better.

harveywi 9y ago
>incremental compilation works Not for me. There are hot zones in my code that I dare not touch unless I want to trigger an extremely long recompile. This really sucks.
- gmartres 9y ago
  you might want to give sbt 1.0 a try, it features better incremental compilation support: https://developer.lightbend.com/blog/2017-04-18-sbt-1-0-roadmap-and-beta1/#zinc-1-class-based-name-hashing https://developer.lightbend.com/blog/2017-04-18-sbt-1-0-road...
  - harveywi 9y ago
    Thanks for the tip! Unfortunately I'm bolted into Play Framework, which does not seem to be compatible with SBT 1.0. :(

nicktelford 9y ago

I've seen a lot of complaints about Scala's compilation speed (I believe it's either the 1st or 2nd most common complaint), but I've not really had any issues myself. Could people who have had issues with compilation speed explain their workflow, I'd like to better understand the problem. For example, here's my general workflow: 1. code in IntelliJ until the feature/fix is complete, and there aren't any red-wavy lines in my source tree 2. run `compile` in an already running sbt session. As a result, I only find myself "waiting" for a compile a few times a day. And even then, because I'm using the incremental compiler it's usually only a few seconds. The only reason I run the sbt compile at all is because the IntelliJ compiler is known to be a bit buggy, especially around things like implicit resolution and some of the more advanced features used for abstract programming. I have seen CI builds take some time, but even then, in every project I've worked on, the complete compile-time is dwarfed by the time taken to run tests. I'm not trying to dismiss problems that others have; I would love to learn more about them!

harveywi 9y ago
Here is one that I run into frequently. You're building a CRUD app, but want some semblance of sane FP interaction with your database. So you use Doobie [1] because free monads and all. So you type your query using a Doobie SQL string interpolator... sql"SELECT ItemId from dbo.Item WHERE IsOnSale = TRUE" ...but then you forget all of the ".query[Int].vector.transact(tx).unsafePerformSync" crap that you are supposed to tack onto the end of the string to actually run your query. What are your options? 1. Type a '.' character in your IDE and watch it crash while the presentation compiler thrashes around, sifting through a combinatorial explosion of implicit values (or whatever it is that makes it so slow). You quickly learn to stop using autocomplete. In a sane world, this should take milliseconds and you should quickly get a list of methods to guide you down the right path. 2. Type a '.' and try to recompile. Wait 30 seconds. While you're waiting, what work can you possibly do??? None. 3. Stop what you're doing, open up The Book Of Doobie [2], try to remember which page has the syntax that you need for doing this one simple thing, go to that page, navigate to the right part of the webpage, read the crap, think a bit, copy/paste it into your code. This FEELS more productive than (2), but is it really? This is just one example, maybe not terribly compelling, but it happens. People (well at least me) have a limited amount of memory for administrivial crap to hold in our heads while we try to get our work done. Tooling is supposed to help with that, but with Scala it really starts to get in the way. Flow state just isn't possible. I have heard anecdotes of developers running two or more instances of scalac so that they can work on more than one feature at a time in order to not completely waste away their time. Imagine the context switching there, and having to pay attention to the little oven timer and switching context when one compiler is finally done recompiling the same code it already compiled hundreds of times. [1] https://github.com/tpolecat/doobie https://github.com/tpolecat/doobie [2] http://tpolecat.github.io/doobie-scalaz-0.4.2/00-index.html http://tpolecat.github.io/doobie-scalaz-0.4.2/00-index.html

AzzieElbab 9y ago

One of the huge benefits of strongly typed language is the ease it introduces to managing large code bases. Now imagine google size monorepo and scala compilation speed