Live data from Hacker News

Reasonable Scala Compiler

github.com

41–50 of 161 posts

Re: Reasonable Scala Compiler

#41

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.

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

Re: Reasonable Scala Compiler

#43
post #40

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.

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/

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.

Re: Reasonable Scala Compiler

#44
post #34

Earlier quoted context omitted.

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.

Not to mention they can also decide laters to add new features to this new language, further diverging from Scala.

They are already diverging from Scala since they are only implementing a subset of it:

> We are planning to start small with a trivial subset of Scala and then gradually add features, carefully measuring their impact on compilation performance

It will be a while before they reach parity with Scala, and I'll bet the project will be canceled before they even come close.

Re: Reasonable Scala Compiler

#45

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

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.

Re: Reasonable Scala Compiler

#46

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.

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

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

Re: Reasonable Scala Compiler

#47

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.

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

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

Re: Reasonable Scala Compiler

#48
post #31

Earlier quoted context omitted.

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

You mean something like this: https://plugins.jetbrains.com/plugin/233-idetalk :)

Or this: https://github.com/JetChat/JetChat

Re: Reasonable Scala Compiler

#49

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

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)

Post reply on HN