blandflakes

6 ms·

31.
by blandflakes 10mo ago
I find that if most of my logic is relatively gluey, then the fields in my API boundaries are heavily optional, at which point types add a lot less than they do when most of my logic is more internal, and in cases where what I'm doing
32.
by blandflakes 10mo ago
This has sort of been my issue with Elixir. I've been doing Scala for years but I think Phoenix is really the best web story at the moment for how I want to be building web apps. And while I believe that the benefits of static typing
33.
by blandflakes 10mo ago
I always find downvoting on stuff like this perplexing. It still isn't there. I know that a lot of Scala people are doing metals and some kind of text editor experience, but if you've used something as powerful as Intellij, the
34.
by blandflakes 10mo ago
One impressive thing for us is that the changes to macros were hardly an issue. We'd been trending off macro-heavy libraries for a while, and our Scala 3 adoption has not really been harmed by the new macro system.
35.
by blandflakes 10mo ago
The bug in TFA is hardly a reason that Scala is not a success, though.
36.
by blandflakes 10mo ago
Have you ever heard the expression "you get what you pay for?"
37.
by blandflakes 11mo ago
I think we're simply going to have to agree to disagree. Your position presupposes quite a bit of "systems already in motion" to make the point that there isn't friction. Except... there is, and _somebody_ has to maintai
38.
by blandflakes 11mo ago
Bazel being used by some companies is not vindication that sbt wasn't a significant source of friction, just another arena where sbt was considered less fit for the job (whether one could argue sbt should have been able to do the job w
39.
by blandflakes 11mo ago
No, it doesn't matter. You are advocating for the special case, not the average case, and it has no bearing on C#'s _general_ aptness that it can't be deployed somewhere. The same is true of Java! This is nitpicking with no j
40.
by blandflakes 11mo ago
> Kotlin multiplatform being adopted by Google for huge projects like Google workspace makes it sound like it may actually be a winning proposition, if you ask me. Kotlin is replacing the more-than-a-decade old, battle tested, Java-to-Ob
41.
by blandflakes 11mo ago
It frankly doesn't matter in which markets C# isn't an option - if you're in one of those, well... then obviously don't consider C#. That doesn't somehow indict C# as a language which better makes it possible to wri
42.
by blandflakes 11mo ago
I also work at a company that used to do a lot in Scala, and have seen the decline firsthand. Who's anecdata is better? I think a lot of posters make the mistake of saying "$otherLanguage has it worse." That's irrelevant
43.
by blandflakes 11mo ago
I'm not advocating for Gradle either, but you already pointed out why the build tool being bad is relevant for Scala and not for Kotlin - Android developers have enough other reasons that they're going to use Kotlin, even though G
44.
by blandflakes 11mo ago
Kotlin is pretty nice. I think the build tool in Scala being so esoteric didn't help with adoption; I remember avoiding Scala for a few years because dealing with sbt left a horrible taste in my mouth.
45.
by blandflakes 11mo ago
> However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected. My employer has d
46.
by blandflakes 11mo ago
It competes in some ways and not in others. It does a pretty good job of providing similar benefits as many Scala ecosystems, but providing approachability over purity. Kotlin becoming The Official Android Language helps it quite a bit, tho
47.
by blandflakes 11mo ago
I think realistically we're looking at a lot of causes (which is not surprising; it's rarely a singular thing). Scala 3's momentum may have already been negative but how Scala 3 landed represented a nail in the coffin for a l
48.
by blandflakes 11mo ago
> IDE support for Scala 3 was really rough when it first released. We checked in on it with every IntelliJ release for roughly 3 years before we decided it was far enough along. Prior to that it was rough enough that we froze migration e
49.
by blandflakes 11mo ago
As other posters mentioned, a lot of it is about lacking critical mass in the first place. Making such a dramatic change is a high-risk thing, and Scala didn't have enough of a lead at all to justify it. > The only bad thing was tha
50.
by blandflakes 11mo ago
The language is actually really nice. The "we won't ship dotty as the next version of Scala, just kidding, here it is", the breakage of editors and IDEs that lasted for years, etc (aka, the WAY they did it) make migrating a p
51.
by blandflakes 11mo ago
Yeah, I think with a community as small as Scala's, you can't really afford: a. fragmentation of the ecosystem b. repeated shuttering/abandonment of some of the most popular options (Lift, Play, Akka) c. splitting the languag
52.
by blandflakes 11mo ago
They really obliterated their momentum with how they went about Scala 3, unfortunately.
53.
by blandflakes 11mo ago
I have a similar experience, though it's not necessarily related to shortcomings in the STM implementation (which I always felt was quite competent in the space). To expand, I think a few things are true: 1. I've come to feel that
54.
by blandflakes 11mo ago
I also feel like this is good advice when making a language shift, or any _other_ shift, even a stylistic one. A lot of my coworkers get in this situation where, when a change in direction is made, they feel like we have to stuff the roadma
55.
by blandflakes 11mo ago
Joy is probably an improvement on slog, but one person's joy is another's hell. I've inherited a lot of joyful projects that were an awful fit for continued maintenance because joyful meant using new, unproven, and unstable t
56.
by blandflakes 1y ago
Return false! They aren't equal. But of course we're comparing a reference to a primitive, so we either lift the primitive to a reference, or lower the reference... so here we are.
57.
by blandflakes 1y ago
This really becomes tedious when you're working with Java's primary means of codesharing/abstraction, inheritance. You can't subtract an IOException from an interface, and you can't introduce one if you're exte
58.
by blandflakes 1y ago
No disagreement on my part. I largely hope not to be in a world where I'm choosing between C or Go, though!
59.
by blandflakes 1y ago
My job has been making a tactical retreat from Scala, and it's really fascinating to look to alternatives like F# and see that they're even less "successful", from an adoption point of view. I'm surprised at how lit
60.
by blandflakes 1y ago
We've been running .NET on linux for years, what are you talking about?

More ›