Reasonable Scala Compiler

https://github.com/twitter/reasonable-scala#

by adamnemecek • 9 years ago

183 154 9 years ago

I am a bit concerned that between the Scala, Dotty, Typelevel, and now the Reasonable Scala Compiler, that the Scala community might become fragmented. Hopefully the rsc's claim of "making our findings available to the Scala community at large" holds true.

Edit: should have keep reading before commenting. In their related work document:

we are definitely not declaring Lightbend Scala dead. To the contrary, we view ourselves as complementary to Lightbend Scala and hope that our results will create new opportunities for the official compiler. We are planning to keep in contact with Lightbend to discuss our findings and facilitate technology transfer.

foolfoolz2• 9 years ago

scala and dotty will be one and the same in the next major version. the rest are niche tools. no one should be afraid to develop their own compiler or tool chain for fear of fragmentation. the lessons learned can only help the trunk

hota_mazi6• 9 years ago

Regardless of Scala, it's an absolutely insane idea to develop your own language to write your apps.

Either stick to the real Scala or switch to Java or Kotlin, but writing your own language is a failure waiting to happen.

I give this project a few more months before it gets canceled.

carlosdp2• 9 years ago

That's... not true. You mention Kotlin, that was developed by JetBrains as a better language to develop Intellij and plugins.

Hack/HHVM was developed by Facebook to modernize PHP.

There are plenty of cases where organizations successfully developed their own languages/compilers that gave them advantages. It's insane only if you have no good reason to do it. This sounds like they have a need: compile times are slow.

alexandercrohde• 9 years ago

you think compile times are so slow that they're saving time by writing a whole language? I'd like to see the numbers on that...

sk5t• 9 years ago

JetBrains' business and expertise is language stuff, lexers, compilers--isn't it fair to give them a pass on making a language?

One needn't extend the same consideration to, say, fogcreek...

hasenj3• 9 years ago

Hack/HHVM was developed by Facebook to modernize PHP.

Yes but why use PHP in the first place? It's not the right tool for something like Facebook.

yawaramin2• 9 years ago

It's not a new language, it's a reduced subset of the same language.

hota_mazi6• 9 years ago

You're playing with words. They are creating their own language which is a subset of Scala, and they decide which features to keep based on whether they are fast enough to compile.

The point is: developing your own language to ship your apps is crazy.

mintplant2• 9 years ago

Funny you should mention Kotlin, as it's the result of JetBrains doing just that: developing their own language to write their apps. Mozilla represents another successful example with Rust.

I'm of the opinion that developing new, purpose-built languages (or extending existing ones) is a strategy that isn't given as much consideration as it should.

Throaway7862• 9 years ago

Jetbrains is a compiler/IDE company, they have the expertise to do such task. What will Twitter gain from this endeavor?

hasenj3• 9 years ago

Funny you should mention Kotlin, as it's the result of JetBrains doing just that: developing their own language to write their apps.

JetBrains is in the business of IDEs and similar programmer tools. Kotlin fits right in with the rest of their business.

Imagine if JetBrains produced a chatting program, because their engineers were not satisfied with the existing options.

foolfoolz2• 9 years ago

it's insane to write your own language switch to Java or kotlin

ah yes rewriting in a new language, the classic not-insane approach

hota_mazi6• 9 years ago

I offered several alternatives and I made it clear they belong in a spectrum. Don't make it sound like I claimed it was binary.

If the options are "Keep writing in Scala", "Port to Kotlin" and "Write a Scala compiler", the latter is clearly the worst and most costly of all.

zeckalpha• 9 years ago

You posted this on hacker news, which is essentially the only app written in its language.

addisonj• 9 years ago

It will be interesting to see what the subset is.

I have been writing scala for 2 years, mostly in spark and flink and as much as I love parts of it, overall, the language is just not the most approachable. Some of the features are super valuable every once in a while, but I might gladly give some of them up for a streamlined language that is easier to get people started on (while not just writing imperative style Java with Scala syntax)

My other curiosity is compatibly. If I can compile a subset of my project much faster that doesn't need all of Scala, that seems like an okay place to be in.

adamnemecek4• 9 years ago

Check out Kotlin. I picked it up in like half a day. It wasn't idiomatic Kotlin but w/e. It can compile to JS and you can use just about any JS lib from Kotlin (which is insanity). You'll be able to write ios apps with it soon enough.

Scala can be too hard sometimes.

brianwawok• 9 years ago

You can use JS from scala also.

alextheparrot• 9 years ago

He's using Spark and Flink... Given that I'm also in that big data space, I'm certain the tooling provided by Kotlin is strictly worse than Scala for those applications.

afghanPower• 9 years ago

Clojure(Script) can do the same.

MrBuddyCasino• 9 years ago

It will be interesting to see what the subset is.

Totally. Its interesting that they approach this from a compile speed angle, I wonder how much they are also considering the mental load of certain features.

This might become an interesting project for companies already doing Scala. New ones at this point will probably prefer Kotlin.

sulam4• 9 years ago

Historically anything with heavy use of implicits is embarrassingly bad for compilation.

koolba3• 9 years ago

It's also atrocious for comprehension.

lmm12• 9 years ago

I have been writing scala for 2 years, mostly in spark and flink and as much as I love parts of it, overall, the language is just not the most approachable. Some of the features are super valuable every once in a while, but I might gladly give some of them up for a streamlined language that is easier to get people started on (while not just writing imperative style Java with Scala syntax)

Any concrete ideas? In my experience the parts people find intimidating often aren't actually language features, they're things some library or other implements.

I mean there are things I would remove from Scala if I were in charge - structural types (provided there was still a way to express partially applied types i.e. standardize kind-projector in the core language), Dynamic - but they don't tend to be the parts that trip people up.

needusername• 9 years ago

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

sulam4• 9 years 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.

davedx3• 9 years 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• 9 years 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..

lmm12• 9 years 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• 9 years 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• 9 years 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.

harveywi6• 9 years 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.

nicktelford2• 9 years 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!

harveywi6• 9 years 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

[2] http://tpolecat.github.io/doobie-scalaz-0.4.2/00-index.html

AzzieElbab• 9 years 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

Throaway7862• 9 years ago

Twitter is not performing well as a business. It is also at almost all time low. Should it be working on a new language/compiler?

adamnemecek4• 9 years ago

It's because their devs are spending too much time compiling their code /s

monksy• 9 years ago

or maintaining their monorepo

daxfohl• 9 years ago

Maybe it was a business deal. If you start seeing Martin Odersky retweeting Justin Bieber a lot going forward, you'll know what's up.

jmnicolas• 9 years ago

Doesn't Scala run on the JVM ? Are they talking about JIT times or are there other Scala 'environment' that are not semi-interpreted ?

ptx• 9 years ago

They are talking about compilation of source code to Java byte code, i.e. the same kind of compiler as javac from the JDK. (There is also Scala Native, but that doesn't seem to be what this is about.)

maemre• 9 years ago

This is the compiler from Scala to Java bytecode. It does type checking, some optimizations (like inlining, removing some instances of boxing, or converting tail-recursive functions to loops), and converts all Scala-specific features to some Java constructs (e.g. traits become interfaces, classes etc.; lazy values become methods and accompanying values; lambdas get lifted to the class they are defined in).

The JIT works on Java bytecode. Java also has a similar compiler (javac) from Java -> bytecode.

jankotek• 9 years ago

Identify a subset of Scala that can be compiled with reasonable speed

I am afraid of Scala fragmentation. There is no way new compiler can be 100% compatible. Hopefully it will be tested on major projects, or there will be some official Scala Language spec.

It would be nice to add a switch into old scalac, which downgrades its features, to make it compatible with new scalac.

I believe Scala has too many features, and it will be very difficult to fix compilation speed. But there could be decend boost just by rewritting compiler from scratch. If anything we will get better error messages.

Compilation speed was major reason why Jetbrains started Kotlin.

Disclaimer: I worked with Scalac / IDE back in 2009. Kotlin fanatic.

skrebbel• 9 years ago

Hopefully it will be tested on major projects

Twitter has pretty big resources. It's probably feasible for them to spin up a build farm that runs their compiler against all active Scala projects on GitHub, measuring error count and compilation speed as they go along.

harpocrates• 9 years ago

There is no way new compiler can be 100% compatible. Hopefully it will be tested on major projects, or there will be some official Scala Language spec.

I, for one, think that an official language spec would do the language a lot of good. As it stands, it is sometimes difficult to separate bugs from features in scalac...

dtech2• 9 years ago

I am not sure how complete/correct it is, but there is one for 2.9 [1]

Martin Odersky & co have been focusing most of their effort the last few years on Dotty (aka Scala 3), which succeeded in giving in giving Scala a proven theoretical basis in exchange for a few esoteric typesystem features they couldn't prove. [2]

[1] http://www.scala-lang.org/old/sites/default/files/linuxsoft_...

[2] http://www.scala-lang.org/blog/2016/02/03/essence-of-scala.h...

majidazimi2• 9 years ago

This truly means we still lack a programming language with:

    1. reasonable support of object oriented programming.
    2. reasonable support of functional programming.
    3. solid concurrency features.
    4. runs comparable to native code.
    5. simple to learn.

Even though it is not difficult to create such a language but we see a new language poping out every now and then and none of them try to solve these issues.

adamnemecek4• 9 years ago

Rust, swift and kotlin once they have the llvm backend will fit the bill.

jonathanyc2• 9 years ago

Rust is very neat, but it lacks OO features.

AJRF• 9 years ago

Swift is awesome but lacks atomicity guarantees and it allows some race conditions even when using gcd.

https://github.com/apple/swift/blob/master/docs/proposals/Co...

davedx3• 9 years ago

I wouldn't say Rust is simple to learn. The borrow checker alone is quite a steep hill (though the compiler errors are very good).

In my limited experience Rust and Swift both suffer from boilerplate/ceremony you have in many other OOP languages (C# too). Static languages for you I guess - there are benefits too...

jonathanyc2• 9 years ago

It seems to me like OCaml has all of those features except for #3 (which admittedly is pretty frustrating to me too). What do you think?

willtim• 9 years ago

Depends on what you mean by concurrency support. OCaml has nice green threads via Lwt.

jon_smark• 9 years ago

OCaml has great support for concurrency (check out Lwt or Async libraries). Do you mean parallelism, perhaps?

bmc75052• 9 years ago

Kotlin?

1. OOP: https://www.packtpub.com/mapt/book/application_development/9...

2. FP: https://blog.plan99.net/kotlin-fp-3bf63a17d64a

3. Concurrency: https://kotlinlang.org/docs/reference/coroutines.html

4. Native: https://github.com/JetBrains/kotlin-native

5. Simple: https://try.kotlinlang.org/

davedx3• 9 years ago

Kotlin looks very nice. But I think there are languages with better concurrency support - Elixir (cheap green threads in the VM) and Scala (actors and futures) come to mind.

I think it really depends on your use case too. Kotlin is great for mobile apps and games, where coroutines are fantastic (see also C#/Unity there). For writing scalable web services, you need more control and resilience. There Elixir and Scala are the heavyweights.

clhodapp4• 9 years ago

The thing that Scala has and Kotlin completely lacks is the tooling to allow you to avoid runtime reflection. Typeclasses and macros (and especially both together) are way too powerful-yet-principled to give up once you're used to them.

ece4• 9 years ago

Scala has scala-native: https://github.com/scala-native/scala-native

Any myriad of FP (scalaz, cats), concurrency libraries (rx, akka)

scastie: https://scastie.scala-lang.org/

scala.js: https://www.scala-js.org/

This FP-focused fork of the Scala compiler: http://typelevel.org/scala/

The next gen Scala compiler called dotty: http://dotty.epfl.ch/

Twitter doesn't mention scala-native...

lmm12• 9 years ago

Kotlin doesn't really support FP in the modern sense of the term; effects are all special cases in the language (null, async), so you can't abstract over them generically (e.g. you could never implement "traverse" in Kotlin because you can't even write the type signature it's supposed to have) and you can't use a custom effect if you want to do something the language designers haven't thought of. E.g. there's no nice way to do validation where you want to have a message in the case of failure (in some ways this is actually a regression from Java, which at least had checked exceptions for this kind of use case, not that they're a great solution).

pjmlp2• 9 years ago

The language doesn't matter if the eco-system and the actual business reason to adopt it isn't there.

iLemming2• 9 years ago

even though that's not difficult

Turns out to be quite arduous:

- You ask for reasonable support for both object-oriented and functional programming, this already contradicts with the notion of state (that objects suppose to contain in OOP) and "stateless" ways of FP, let's ignore that for a moment

- FP means different things for different people - some would argue it has to have well thought type system, but what exactly that means? Is strongly but dynamically typed like in Clojure is okay (with added sugar like Clojure.spec)? Or it has to have static types? Does it have to have then type inference like in Elm? Or definitely it has to have algebraic data types like in Haskell? Or maybe dependent types like in Idris?

- Concurrency models vary too, for example: STM in Clojure and Haskell aren't exactly the same. Actor model in Erlang is a beast and sounds awesome on paper, but in real life process coordination may become a headache. Primitives based on CSP model are also known to have their own quirks. Concurrency in any language is never simple and straightforward.

- You're asking for an fast FP language - with immutable data structures and lazy/non-strict evaluation it's probably unrealistic to get it to run as fast as native code

- And "simple to learn" is also very subjective quality - for some Python is easy, but Clojure is hard. For some Haskell is not that difficult as people describe it. For some it feels like insurmountable mountain.

As you can see - it's not that simple. And we probably not gonna get a "perfect" language that suits everyone anytime soon.

majidazimi2• 9 years ago

I would argue Scala already has all of them but the last one. However there are shit load of absolutely unnecessary features in the language. As the parent link states, twitter just removed shitty features and there you go: An easy to use Object/Functional language which runs fast and has awesome concurrency features.

catnaroek5• 9 years ago

FP means different things for different people

It's difficult to agree with a definition of FP that doesn't require expressing as much computation as possible as function evaluation. Functions being mappings from values to values, having a rich set of values (not the same thing as objects!) is a prerequisite.

didibus• 9 years ago

These all exist, you just don't agree with them being reasonable:

Scala, Common Lisp, C++, D, Clojure, F#, OCaml, Kotlin, etc. Those could all count or not depending on your subjective opinion.

The truth is, it is difficult to create the perfect language, and any sufficiently complete language will always start to have part of it that suffer in exchange.

catnaroek5• 9 years ago

Scala, Common Lisp, C++, D, Clojure, F#, OCaml, Kotlin, etc.

Out of those, only OCaml really provides “reasonable” support for functional programming. The ability to manipulate compound values (say, lists or trees) directly, without using objects having a queryable physical identity, is of course a prerequisite.

it is difficult to create the perfect language, and any sufficiently complete language (...)

Maybe the excessive amount of features is the problem in the first place.

moomin• 9 years ago

I'd have said the fact that no-one's done it is pretty good evidence it's not as easy as you think. As plenty of people have pointed out, FP means different things to different people. But so does OO. In fact, I'd argue that Scala is about as close as you're going to get to your spec. Not helped by the fact that, as any Scalazzi could tell you, the requirements of 1 and 2 contain contradictory elements and make complexity shoot through the roof. (You can get fewer FP features and less complexity by going for F# instead.)

Personally, I like Haskell. It's great for 1 and 3, 4 is pretty acceptable and 2 gets thrown in the bin.

5 could do with some work, though.

m12k• 9 years ago

What I'm looking for in a language:

1. Solid mix of functional programming and Object oriented programming (though FP is more important - I'd gladly give up inheritance if I get good support for interfaces and traits instead)

2. Static type checking

3. Good support for efficient immutable data structures.

4. Solid concurrency features

5. Easy cross-compilation to and interaction with JS

5a. Cross-compilation to iOS and Android would be nice but it's not a dealbreaker

6. Good tooling (i.e. IDE-support, package manager)

7. A solid standard library

8. An active open source community around it

9. Said open source community should contain a good web MVC framework (or sensibly pluggable modules to the same effect)

10. A REPL

11. Sensible compilation times

So far it looks to me like only Scala and Haskell are candidates - and it sounds like Scala really struggles with the compilation times. If Reason/ocaml gained more traction it might become a contender. And if I gave up on static type checking then Clojure would be an option. And if I settled for a sprinkling of functional programming instead of having that be the basis, then Kotlin or maybe C#. Any other suggestions?

lmm12• 9 years ago

I think you've covered the main options. At a guess: Maybe F# if you're willing to go with a smaller open-source community. Maybe Rust or Idris if you're willing to deal with something a bit less mature with less tooling. Maybe Swift, Crystal or Nim, though I know less about them and their communities seem smaller.

Matthias2473• 9 years ago

Besides the options you mentioned I really think Typescript is a high contender on that list. Even though it's just Javascript with typing it ticks most boxes you mention. Depending on how you value some features (e.g. nr. 5) it might even be the best option.

superlopuh• 9 years ago

Sounds like OCaml to me, although I'm not super experienced with it. Not sure exactly how concurrency is handled.

mahyarm• 9 years ago

I've heard that Haskell also has a compile time problem. And swift does too. :(

akhilcacharya• 9 years ago

This is basically what I'm looking for too.

For me, ES6+ is near ideal in terms of syntax and features if it had parallelism support.

adamkruszewski• 9 years ago

Common Lisp comes to mind (ducks) ;)

smitherfield4• 9 years ago

Not a trendy language by any means, but C# meets all your criteria.

1. About the strongest OOP support of any language which doesn’t have a dynamic or Scala-esque exotic type system. Also supports non-OOP imperative, unlike Java.

2. Linq is nigh-on the best FP support offered in any non-FP language’s standard library, and really is one of the best FP libraries period.

3. Invented async/await, by far the most ergonomic concurrency primitive yet created.

4. Fast and easy to tune for performance (stack-allocated value types which can also be passed by reference).

5. If you know Java or C++ you’ll be productive within minutes.

harveywi6• 9 years ago

I had used Scala for many years before trying C#, and I have to agree. The only thing that I really missed in C# were higher-kinded types.

colefichter• 9 years ago

3. Invented async/await, by far the most ergonomic concurrency primitive yet created.

This feels like a bit of hyperbole. The actor model seems much more intuitive than async/await. Indeed, message passing between actors is how concurrency works in the real world (think about how people interact with each other).

mhh__• 9 years ago

dlang.org? :)

You can write (compiler enforced) pure functional code, and the standard library is somewhat monadic.

joefkelley• 9 years ago

My opinion of this changed after reading this comment by the developer: https://www.reddit.com/r/scala/comments/6ubuix/twitter_annou...

Sounds like they are intending it as a research effort and hope to make progress with the entire Scala community, not fork it.

amelius• 9 years ago

Will they use this compiler only for prototyping/debugging/testing? Or also for production work?

ece4• 9 years ago

Overall, I feel like with the success of Go and Kotlin, having an easy to learn language definitely wins. Faster runtime speed might be a bigger 'market' than wanting fast compile times, which matters if you have a large enough codebase. I do wish Scala native was further along, and if the language was going to get simpler, it would focus more on native speed than compilation time. Quite a few Scala compiler releases have made big strides in compilation times, to the extent that java vs scala compilation times I feel are the same or well worth the cost, so this has been and will be an ongoing effort. The Java group is also working on being native, so we will likely see Java native when it gets there.

danarmak2• 9 years ago

The Java group is also working on being native, so we will likely see Java native when it gets there.

I haven't heard about this. Can you give a reference please?

ece4• 9 years ago

They are working on AOT compilation: https://www.youtube.com/watch?v=Xybzyv8qbOc&index=241&list=W...

jgalt2122• 9 years ago

So Clojure is slow to start and Scala is slow to compile. Is Scala also slow to start? As compared to a Java program to performs the equivalent functions.

iLemming2• 9 years ago

Clojure doesn't have slow start-up, Leiningen and Boot-clj make it feel slow. But once you start a REPL you can keep it running. I keep mine running for weeks.

jgalt2122• 9 years ago

I know. I've often heard this, but for me that's a bit tricky b/c I'm worried that my current definition of "foo" is not what it is in my .clj file b/c I may have monkey-patched it in the REPL and forgot I did that.

Others• 9 years ago

I'm interested in what they said about reducing the compiler to 4 passes. Dotty takes a really interesting approach to this with 'miniphases' (https://infoscience.epfl.ch/record/228518/files/paper.pdf). I think it'll be interesting to compare these two methods when both compilers are production ready.

harveywi6• 9 years ago

I'd like to see a Scala compiler that works more like a proof assistant like Coq. I want the compiler's job to be to help me quickly write correct code. That should be first-class functionality. Batch-compiling the same source files over and over again should be just a neat trick that the compiler can do on the side.

wpietri2• 9 years ago

Huzzah! Maybe this is already in the works, but I would love to see a compiler that stays hot in RAM and works incrementally.

RAM is cheap nowadays, and the number one reason I want a fast compiler is to speed up my feedback cycle between making a change and evaluating the effects of the change. So I want something that squats on a large chunk of RAM and works in parallel with me, updating with every edit I make.

_lbaq• 9 years ago

SBT always runs Scalac in the same VM, so it will be hot and JIT compiled after a few passes.

Intellij implemented a SBT Shell in 2017.1, so it will keep the same SBT session going between passes also.

wpietri2• 9 years ago

That's a good start, but won't the compiler still be batch-oriented? By which I mean doing a ton of I/O and activity only when I hit go?

I'm talking about something much more real time. I want the parser to keep everything hot, updating every time I hit a key. And whenever I get to anything that the parser approves of, downstream stages, which also keep everything hot, dynamically update all of their structures, revising object files as they go.

Batch orientation is great, and I understand why compilers started there. But I want something that moves beyond that. It's sort of the difference between a batch-oriented rendering system like TeX or early word processing versus a modern WYSIWYG word processing setup, where we burn resources prodigiously to give users much faster feedback loops.

sorokod• 9 years ago

Gradle?

edem• 9 years ago

Writing a reasonable compiler would need a reasonable language, no? Scala had its chance in the last 13 years now it is time for this abomination to go.

Reasonable Scala Compiler

Related Stories