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 have made big strides in compilation times, to the extent that java vs scala compilation times I feel are the same or well worth the cost, so this has been and will be an ongoing effort. The Java group is also working on being native, so we will likely see Java native when it gets there.
Reasonable Scala Compiler
91–100 of 161 posts
Re: Reasonable Scala Compiler
#92Earlier quoted context omitted.
I agree that most application-level code doesn't need new macros (you rarely have to develop a new macro to add a feature to an application) but there are definitely a lot of very legitimate use-cases for them outside of Shapeless. To give just a few: * https://github.com/adamw/macwire * https://github.com/fthomas/refined * https://github.com/adamw/quicklens * https://github.com/scala/scala-async * https://github.com…
macwire and scala-async are bad ideas in my book (having worked on codebases that use them) and I suspect the same of machinist and refined; they're both making too big a change to the language to make sense as a library, the cost/benefit doesn't stack up. (I do think prototyping language improvements is one other thing macros are good for, but that's not something you'd do in production code). quicklens looks like a…
What's wrong with async for you? For me, 95% of the time, it is fantastic, and for the 5%, I just fall back to some other method.
Re: Reasonable Scala Compiler
#93Earlier quoted context omitted.
macwire and scala-async are bad ideas in my book (having worked on codebases that use them) and I suspect the same of machinist and refined; they're both making too big a change to the language to make sense as a library, the cost/benefit doesn't stack up. (I do think prototyping language improvements is one other thing macros are good for, but that's not something you'd do in production code). quicklens looks like a…
What's wrong with async for you? For me, 95% of the time, it is fantastic, and for the 5%, I just fall back to some other method.
I find continuation-based stuff impossible to reason about; the only way I can understand the flow is in terms of values i.e. futures. And if we're working with futures I'd rather have them work as a plain old monad with for/yield that looks like any other monad, rather than having to remember what some unique future-specific syntax desugars into.
Re: Reasonable Scala Compiler
#94It 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…
> 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 Java with Scala syntax)
Any concrete ideas? In my experience the parts people find intimidating often aren't actually language features, they're things some library or other implements.
I mean there are things I would remove from Scala if I were in charge - structural types (provided there was still a way to express partially applied types i.e. standardize kind-projector in the core language), Dynamic - but they don't tend to be the parts that trip people up.
Re: Reasonable Scala Compiler
#95Earlier quoted context omitted.
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…
Besides the options you mentioned I really think Typescript is a high contender on that list. Even though it's just Javascript with typing it ticks most boxes you mention. Depending on how you value some features (e.g. nr. 5) it might even be the best option.
Its FP support is even more limited than C#'s, no?
Re: Reasonable Scala Compiler
#96Earlier 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…
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 been learned yet.
Re: Reasonable Scala Compiler
#97It 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…
Historically anything with heavy use of implicits is embarrassingly bad for compilation.
It's also atrocious for comprehension.
Re: Reasonable Scala Compiler
#98It 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.
You can use JS from scala also.
Re: Reasonable Scala Compiler
#99Earlier quoted context omitted.
Besides the options you mentioned I really think Typescript is a high contender on that list. Even though it's just Javascript with typing it ticks most boxes you mention. Depending on how you value some features (e.g. nr. 5) it might even be the best option.
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.
Re: Reasonable Scala Compiler
#100Scala just sucks. It was a research project that turned into a bad idea. I hope Scala dies