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

111–120 of 161 posts

Re: Reasonable Scala Compiler

#111

Post by harveywi »

lmm wrote: post #104
koolba wrote: post #97

Earlier quoted context omitted.

It's also atrocious for comprehension.

Not the same thing. The thing that slows down compilation is recursively derived implicit parameters for typeclasses, which don't tend to be a problem for reading - you just write "myObject.toJson" (and behind the scenes it recurses through the structure of myObject at compile time, ensuring that all of the nested types bottom out in values that can actually be serialized to JSON, and compiles to something of similar…

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 playing whack a mole with the types, as needed, punctuated by longer compilation times.

Re: Reasonable Scala Compiler

#112

Post by ece »

danarmak wrote: post #103
ece wrote: post #91

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…

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

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

Re: Reasonable Scala Compiler

#113

Post by koolba »

harveywi wrote: post #111
lmm wrote: post #104

Earlier quoted context omitted.

Not the same thing. The thing that slows down compilation is recursively derived implicit parameters for typeclasses, which don't tend to be a problem for reading - you just write "myObject.toJson" (and behind the scenes it recurses through the structure of myObject at compile time, ensuring that all of the nested types bottom out in values that can actually be serialized to JSON, and compiles to something of similar…

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.

Re: Reasonable Scala Compiler

#114

Post by virtualwhys »

harveywi wrote: post #107
nicktelford wrote: post #78

Earlier quoted context omitted.

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

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

FWIW, the author of Doobie doesn't even use an IDE, which is par for the course I believe for users of Scalaz, Cats, Shapeless, etc. inference heavy libraries.

Abstraction isn't free in Scala, you pay for the features used; tooling suffers as a result, thus projects like Twitter's RSC come into being.

You may want to checkout Quill, or Perhaps Slick (though the latter I suspect is similarly IDE challenged). Barring that, give your IDE loads of RAM.

Re: Reasonable Scala Compiler

#115

Post by nicktelford »

harveywi wrote: post #107
nicktelford wrote: post #78

Earlier quoted context omitted.

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

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

Thanks! I haven't used doobie yet (though I intend to), I had no idea it's API caused IntelliJ such an auto-complete headache.

I'm curious how a faster scalac would help in this case though. Perhaps I'm missing something, but scalac's errors don't really facilitate this kind of API exploration.

I completely agree that exploring an API (because who wants to memorise the standard library and API of all your dependencies) in IntelliJ is often quite cumbersome. One trick I've come to lean on a lot is to type '.ensur' to determine the type of the current term; this causes IntelliJ to present the method signature for 'ensuring', which is available (implicitly) on everything (except Nothing), showing the current type in its return type.

Re: Reasonable Scala Compiler

#116

Post by danarmak »

ece wrote: post #112
danarmak wrote: post #103

Earlier quoted context omitted.

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

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

IIUC, this is about AOT but still using the JVM. This is a fix for slow warm-up, but in longer running processes the eventual behavior isn't different from JIT. Which is important in its own right, but very different from a hypothetical 'Java native' in the sense of 'Scala native', without a JVM at all.

Re: Reasonable Scala Compiler

#117

Post by loup-vaillant »

stewbrew wrote: post #82
catnaroek wrote: post #65

Earlier quoted context omitted.

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

While OCaml might be the most reasonable in theory, AFAIK opam on Windows still doesn't work. Also its standard library is too minimal for my liking.

User catnaroek was only talking about support for Functional programming. And they're right: it's hard to reasonably support typed functional programming without sum types.

And we're talking about a language dammit, not libraries or package managers. Let's have a good language first, then build the tools around it.

Re: Reasonable Scala Compiler

#118

Post by lmm »

harveywi wrote: post #111
lmm wrote: post #104

Earlier quoted context omitted.

Not the same thing. The thing that slows down compilation is recursively derived implicit parameters for typeclasses, which don't tend to be a problem for reading - you just write "myObject.toJson" (and behind the scenes it recurses through the structure of myObject at compile time, ensuring that all of the nested types bottom out in values that can actually be serialized to JSON, and compiles to something of similar…

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…

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

It's not possible to actually build, because at the end of the day you are (presumably) using the implicit for something (e.g. JSON-serializing the value). You could explicitly pass ??? where the implicit is wanted to get a runtime failure where it's used. I guess it might be possible to have tooling do that "magically", but I'm not sure how useful that would be; if you're working on that particular area you can use ??? by hand, if you're not working on that area then you presumably won't be rebuilding it since you're presumably using incremental compilation anyway.

What is possible is to fail-fast when resolution fails, and not check for duplicates when resolution succeeds - one main reason for the blowup is that at every stage of recursive resolution you have to check whether the implicits were ambiguous. There's a proposed fix for that piece: https://github.com/scala/scala/pull/5649

Re: Reasonable Scala Compiler

#119

Post by superlopuh »

m12k wrote: post #79
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.

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

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

Re: Reasonable Scala Compiler

#120

Post by gmartres »

dtech wrote: post #86
harpocrates wrote: post #58

Earlier quoted context omitted.

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

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/bl…

The latest spec for 2.12 is available at http://www.scala-lang.org/files/archive/spec/2.12/
Post reply on HN