Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reasonable Scala Compiler

github.com

Post reply on HN
Print view View original

121–130 of 161 posts

Re: Reasonable Scala Compiler

#121

Post by gmartres »

harveywi wrote: post #109
atemerev wrote: post #75

Earlier quoted context omitted.

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.

>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.

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-road...

Re: Reasonable Scala Compiler

#122

Post by Others »

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.

Re: Reasonable Scala Compiler

#123

Post by smitherfield »

koolba wrote: post #113
harveywi wrote: post #111

Earlier quoted context omitted.

This is interesting. Would it be helpful, and possible, to add a "YOLO mode" to the Scala compiler so that it just make-believes that recursively derived implicit parameters bottom out properly? Maybe force the caller to give an explicit type (even if the type is wrong). I'd do that to reacquire some semblance of quick compile times. Then, when the developer has finished they can switch off "YOLO mode" and start play…

Typescript is kind of like that. You can run the compiler with the type validations disabled. That can lead to potentially broken code but it can also be significantly faster than waiting for all type checks to complete.

But if you do that you’re just writing JavaScript with pointless added verbosity and significant complexity pointlessly added to your toolchain.

Re: Reasonable Scala Compiler

#124

Post by jghn »

koolba wrote: post #97
sulam wrote: post #22

Earlier quoted context omitted.

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

It's also atrocious for comprehension.

Depends completely on how the implicits are being used. The older form of implicit conversions are pretty rough, but the more modern trend towards implicit enhancement IMO can improve readability.

Re: Reasonable Scala Compiler

#125

Post by smitherfield »

majidazimi wrote: post #35

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.

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.

Re: Reasonable Scala Compiler

#126

Post by koolba »

smitherfield wrote: post #123
koolba wrote: post #113

Earlier quoted context omitted.

Typescript is kind of like that. You can run the compiler with the type validations disabled. That can lead to potentially broken code but it can also be significantly faster than waiting for all type checks to complete.

But if you do that you’re just writing JavaScript with pointless added verbosity and significant complexity pointlessly added to your toolchain.

The idea is to have fast compilation most of the time (local dev) and slower/full compilation during the "real" build.

Here's a testing analogy: My CI server runs all tests, every time. My local machine only runs the ones I tell it to run as if I change one small piece of an app then I'm not going to wait for the entire test suite to run.

Re: Reasonable Scala Compiler

#127

Post by harveywi »

smitherfield wrote: post #125
majidazimi wrote: post #35

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.

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 ergonomi…

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.

Re: Reasonable Scala Compiler

#128

Post by jon_smark »

jonathanyc wrote: post #38
majidazimi wrote: post #35

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.

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?

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

Re: Reasonable Scala Compiler

#129

Post by harveywi »

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.

Re: Reasonable Scala Compiler

#130

Post by devdoomari »

koolba wrote: post #97
sulam wrote: post #22

Earlier quoted context omitted.

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

It's also atrocious for comprehension.

that can be mitigated with IDEs showing marks on implicit uses, with mouse-over-to-peek-definition features (hope this lands on intelliJ... and hopefully a free license for me lol)
Post reply on HN