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

141–150 of 161 posts

Re: Reasonable Scala Compiler

#141

Post by smitherfield »

colefichter wrote: post #140
smitherfield wrote: post #125

Earlier quoted context omitted.

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…

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

I knew I'd get pushback on that one, it is somewhat hyperbolic; I'm here using "most ergonomic" to mean "closest source-level similarity to the synchronous equivalent." Which is perhaps not the "best" way to model concurrency, but has the advantage of being very easy to learn.

Re: Reasonable Scala Compiler

#142

Post by pjmlp »

16bytes wrote: post #137
harveywi wrote: post #127

Earlier quoted context omitted.

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.

I think I'd miss pattern matching the most. The first time I saw how pattern matching with regular expressions automatically extracted the matching bits I was sold. I'd also miss block expressions. I keep wanting to write if-expressions (as opposed to if-statements) in every non-scala language I touch. But I agree, c#/.net is a good alternative if you're used to the expressiveness of scala.

It is not at the same level as Scala, but C# 7 has pattern matching.

Re: Reasonable Scala Compiler

#143

Post by iLemming »

jgalt212 wrote: post #105

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.

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.

Re: Reasonable Scala Compiler

#144

Post by mahyarm »

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…

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

Re: Reasonable Scala Compiler

#145

Post by smitherfield »

koolba wrote: post #126
smitherfield wrote: post #123

Earlier quoted context omitted.

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.

And the incremental compilation isn't fast enough for you? Plus building Angular 2 (hundreds of thousands of LoC) takes only a few seconds.

Re: Reasonable Scala Compiler

#146

Post by sorokod »

wpietri wrote: post #133

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.

Gradle?

Re: Reasonable Scala Compiler

#147

Post by jgalt212 »

iLemming wrote: post #143
jgalt212 wrote: post #105

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.

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.

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.

Re: Reasonable Scala Compiler

#148

Post by akhilcacharya »

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…

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.

Re: Reasonable Scala Compiler

#149

Post by dtech »

simon_o wrote: post #96
dtech wrote: post #86

Earlier quoted context omitted.

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…

There are also specs for later versions, it's just that they are pretty outdated and unmaintained. (Like pretty much everything related to documentation.) I think Jetbrains has some experience using that spec to implement the IDE's Scala typechecker. Long story short: years later, it still doesn't work. I would be kind of concerned about the esoteric new features they added to Dotty, looks like the lesson has not bee…

They removed the esoteric features because they could not be theoretically proven sound, not added them.

Re: Reasonable Scala Compiler

#150

Post by wpietri »

_lbaq wrote: post #139
wpietri wrote: post #133

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.

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.

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.

Post reply on HN