Scala just sucks. It was a research project that turned into a bad idea. I hope Scala dies
Reasonable Scala Compiler
101–110 of 161 posts
Re: Reasonable Scala Compiler
#102Earlier quoted context omitted.
Its FP support is even more limited than C#'s, no?
Imho they are about the same, or maybe TS is even a little bit better, since you can really have freestanding functions (C# has either (static) member functions or delegates). The Javascript ecosystem probably also leans a bit more towards FP style in the mainstream (with lodash, ramda, redux, etc.) than C# does. What are you missing in particular? I guess the main thing for both is tail recursion.
Does TypeScript have any kind of "do notation" or "comprehension" syntax? LINQ is not the best by any means but it does seem like a big improvement over nothing.
Re: Reasonable Scala Compiler
#103Overall, 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?
Re: Reasonable Scala Compiler
#104Earlier quoted context omitted.
Historically anything with heavy use of implicits is embarrassingly bad for compilation.
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 efficiency to manually naming all the fields). The thing that causes readability issues tend to be overuse of implicit conversions, and the community has largely moved away from that, thankfully.
Re: Reasonable Scala Compiler
#105So 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.
Re: Reasonable Scala Compiler
#106Earlier quoted context omitted.
This has existed on the JVM for years: annotation processing. Much less heavyweight than macros and easier to reason about.
Annotation processing is impossible to reason about; it's equivalent to macros but much less visible. Most Scala doesn't need macros (other than those inside shapeless) because Scala has a) higher-kinded-types, for/yield and an existing library for working with context-like types, and b) generic traversal of object graphs via shapeless. Between them those cover virtually all the use cases for annotation processing, m…
> Annotation processing is impossible to reason about
Maybe for you but given how popular annotation processing is on the JVM (and especially on Android), plenty of people are reasoning with them just fine.
Actually, it's so popular and easy to use that it's slowly replacing reflection in pretty much every library I've seen.
Re: Reasonable Scala Compiler
#107I'm a bit confused. I have been told multiple times by Scala users that Scala compile times are a non-issue.
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"
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
Re: Reasonable Scala Compiler
#108It 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 Ja…
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.
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.
Re: Reasonable Scala Compiler
#109I'm a bit confused. I have been told multiple times by Scala users that Scala compile times are a non-issue.
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.
Re: Reasonable Scala Compiler
#110Earlier quoted context omitted.
Annotation processing is impossible to reason about; it's equivalent to macros but much less visible. Most Scala doesn't need macros (other than those inside shapeless) because Scala has a) higher-kinded-types, for/yield and an existing library for working with context-like types, and b) generic traversal of object graphs via shapeless. Between them those cover virtually all the use cases for annotation processing, m…
> Annotation processing is impossible to reason about Maybe for you but given how popular annotation processing is on the JVM (and especially on Android), plenty of people are reasoning with them just fine. Actually, it's so popular and easy to use that it's slowly replacing reflection in pretty much every library I've seen.
"Better than reflection" is a low bar, and I'd suspect it's more popular on Android precisely because better alternatives like Scala are less popular there (and also because Android codebases are smaller, so can get away with more unreasonableness).