191–200 of 235 posts
Earlier quoted context omitted.
Damn dude, nice work. We've going 8 -> 11 right now and it's a pain in the butt.
What pain are you having specifically?
TL;DR: anyone doing it wrong anywhere breaks you, and it’s only a win if you feel a need to rip pieces out of your JVM.
Earlier quoted context omitted.
Why do you think Scala has more features than Java/Kotlin? I think it's the opposite. For example null: where Kotlin has a special operator and semantics, Scala simply has the "Option" type in the std lib.
Do you seriously think Scala has fewer features than Java and Kotlin?
Also Scala is not (yet) bootstrappable and the first binaries depended on proprietary software. https://bootstrappable.org/projects/jvm-languages.html https://bootstrapping.miraheze.org/wiki/Bootstrapping_Specif...
Now that's an interesting thought. Since someone was already working on a bootstrapping compiler, I suppose that's the best way, but since the JVM is so high level in general, and doesn't normally have many optimizations at the bytecode level, I almost wonder if it wouldn't be easier to start from one of the early compilers de-compiled into Java instead.
Their approach is to write secondary smaller implementations of the same thing in other languages and use those to build the larger thing. The seed of their bootstrap less than 1000 bytes of hand-written machine code (not assembly), and they are working on eventually reaching a full Linux distro.
I’m never going to use a library written in Scala for the same reason, plus chances are I’d have to spend hours fiddling with SBT to rebuild it at some point.
Scala (with Maven) at the top please, then Java all the way down thanks.
Meh, the complaints fall basically in two categories: 1. Open source libraries are sometimes not maintained which is absolutely true but also just a general hazard of the open source software ecosystem. The solution in most cases is to just not use open source libraries that are somebody's hobby project (which the author very sensibly recommends). But that is true whether you are using Scala or not. 2. Spark is weird…
Some responses: 1. Yea, but languages that are backwards compatible have libs that are useful for way longer. I can still use Java JAR files that were built with Java 8, and published many years ago. The open source libs get stale so much quicker in Scala. 2. I'd actually argue that Spark is less weird that some other dependencies. If you look at the cats README ( https://github.com/typelevel/cats ) there is this cav…
Earlier quoted context omitted.
I think Scala needs to be treated something like how smart shops treat C++: there's so much there you can hang yourself with, so you need to define a subset/dialect and create a style guide and stick with it. This is how C++ has been successful at Google, and it's how I'd approach something like Scala if I were to go back to doing it now.
An evergreen conversation: "I love C++." —Alice "Oh? Which C++?" —Bob Every successful C++ team defines its own C++ subset.
Earlier quoted context omitted.
Were semialgebras a right abstraction, or over-engineering? What is helpful in situations like this is the motto "as simple as possible, but not simpler". During a code review, if you see something you think is too complex, ask the author: "How could it be made even simpler? If not, how exactly a simpler approach did not work?" It sometimes helps find an overlooked simplification.
> Were semialgebras a right abstraction, or over-engineering? I think that's missing the point. The criterion should be: is the code clear enough to be easily testable, easy to debug, and easy to evolve? I will take a wrong abstraction with the qualities listed above any day of the week.
The problem with wrong abstractions, though, is that they do not work, especially when you make the next step on the roadmap.
I would say that clear, testable, evolvable code with little abstraction may be fine. OTOH boilerplate and copy-paste prevents easy or well-controlled evolution. The abstractions end up inlined and fused in the code, instead of being made visible, and become easy to miss a case when a concerted change is needed.
One of the main slides the stood out was discussing something like 20 or 30 different kinds of "types" in Scala. I cannot find it anymore, it may have disappeared with the political "drama" I've heard happened within Scala that included attempts to blackball people.
I've never personally coded in it, I use groovy on the JVM and it satisfies my needs but it has nothing to brag about in terms of avoiding spaghetti code.
It has all the same problems of bootstrapping any language that isn't a "X but distinctly better/easier/more features/fixes major problems in X". A big big lift.
I think only Rust is a language that is sufficiently different that has any real long term chance.
Earlier quoted context omitted.
Do you seriously think Scala has fewer features than Java and Kotlin?
But there is no such thing as Java. It is Java plus spring plus guava plus something else for immutables
Earlier quoted context omitted.
8 to 11 can be a bit trickier, though. Subsequent upgrades should be boring again, but 8->9 can get interesting.
I just upgraded a spring boot app from 8 to 15, and it was seamless. It's been long enough now that most major dependencies just work with 9+ again.