No post body was provided.
Scala isn't fun anymore
271–280 of 394 posts
Re: Scala isn't fun anymore
#272Earlier quoted context omitted.
There's a lot of players involved in the Scala OSS drama. You can read about it here: https://www.reddit.com/r/scala/comments/9a11p1/newbie_wonder... Suffice to say there's a lot of people at each others' throats, and it probably won't get better.
That thread is 4 years old...I wouldn't say that's reflective of the current situation, nor do I find "probably won't get better" a great take, because the Scala OSS situation tries to not-repeat-mistakes. Hell the worst thing the Scala Discord deals with it are spambots!
Well, since then various factions that emerged have only come to hate each other more, a prominent "middle ground" member of the community disappeared after accusations that he was a sexual abuser, and the ecosystem seems to have firmly split between Zio and Cats, so I wouldn't exactly say things have gotten better.
Re: Scala isn't fun anymore
#273The big takeaway here for me is that Akka has changed license to BSL. It's almost crazy to me that such a fundamental and widely used project would switch to such a restrictive license. Some more details here: https://coralogix.com/blog/akka-license-change/ > Lightbend are operating on a “per core” model, with their base license starting at $1995 per core (defined as a thread or vCPU) > The license is only enforced i…
Am I the only one that doesn't think this is really all that bad? I'll admit that I've not ever written a line of Scala, but in principal it seems like the only people who have to follow this license will be those who can afford it. Sure, true FOSS is always better, bit the maintainers have to eat somehow. If you're making 25m+ ARR and are using their software, maybe you should be paying them something.
I think it presents a problem beyond paying.
At my job, I can't just reach for Akka. I need to talk to someone who has the authority to purchase a $2,000/year/core license. If I'm deploying something to 6 instances with 4 cores each, that's $48,000/year for a pretty small deployable. It might be totally worth the price, but I'm definitely going to need to justify to someone that we're going to spend a fifth the price of an engineer because I want to use Akka for this small thing. People will propose alternatives. Before, if Akka was an average addition to the project, it was fine. Most things are average. Now, it's an average addition when we should have used something else and it's costing is $48,000/year.
What happens when we want to scale it up to 24 instances for a week to handle unexpected load? Do we pay $192,000? I'm not trying to sound difficult. I just know the types of questions that will come up in meetings. Likewise, how are we going to account for our Akka usage? Do engineers put it in a spreadsheet that they all forget exist? Won't they just forget when they add a new deployable or when they scale something up? How do we alert accounting or whomever that they need to pay additional license fees when we deploy something new or scale up?
I don't need the same meetings around FOSS. I don't need to involve accounting with FOSS. I don't need to figure out how we're going to sort out the billing. Yes, all these instances will have charges from AWS or whatever, but those are already handled. Yes, companies sometimes buy licenses from JetBrains for their IDEs, but you don't have to worry about those license fees once the code is written - it's a production cost, not a running cost. Yes, after several years Akka goes back to open source (so it isn't a liability forever), but if you keep updating it (including security updates) then it keeps being that liability you need to pay for.
Then there's the issue of ecosystem and vitality. The $2,000/core price is going to shrink the ecosystem down to a tiny fraction of what it used to be. I can hear the comments in the meeting now: why would we be paying $2,000/year/core to buy into a dying ecosystem?
I think the per-core license scheme makes sense to the maintainers - the more you use it, the more value and revenue you're generating with it, the more you should pay us. However, this creates two problems: 1) it makes it hard to deploy low-margin services using Akka so you can only use it in high-margin situations; 2) it means that you really don't know what it's going to cost if you scale up - how many cores are you going to be using a year or two from now?
Microsoft licenses Visual Studio to companies earning over $1M/year, but they're licensing it on a per-engineer basis rather than per-core. Telling a company, "that engineer you're paying $100,000-500,000/year is going to cost you an additional $500-1,000/year," is a very understandable cost and seems like a small/marginal cost per engineer. Telling a company, "that engineer that chose to use Akka is going to cost you an additional $2,000-3,000,000/year," isn't the same thing at all. 100 instances with 16 cores each is $3.2M. You can argue that the company is using Akka so much so they should be paying that much, but at the same time it means that maybe the company would have been better hiring a different engineer that would have used anything other than Akka. If the company had gone with Go or C#, they wouldn't be spending that $3.2M. The company would be better off if they hired a different engineer who wrote the system in Go rather than someone who decided they liked Scala and Akka.
Yes, I'd say it is that bad. The ecosystem will shrivel as people turn away from Akka, it will be difficult to get it approved as you'll need to go through meetings and come up with ways of accounting and paying for it, and the pricing scheme makes it very difficult to offer lower margin services and presents the company with potentially nebulous costs depending on how successful it is.
It's not just about paying. There's so much crap that can happen when you build your stuff around something proprietary. I'm not saying Lightbend will be like Oracle, but companies literally spend lots of money building proofs-of-concept using other databases to get negotiating leverage with Oracle - "see, we ported part of our thing to Postgres so unless you give us a good deal, we'll just replace you." At what point would my company start doing that with Lightbend and wasting my time as an engineer on nonsense? Does Lightbend end up having a "we caught a whale" mentality if my thing takes off or would they say, "oh, we're happy you're successful and we'll cap your license fees at $25,000/year - you clearly shouldn't have to spend millions a year paying us"? Lots of people have talked on here about building your product on someone else's platform. Usually that's about building on Facebook or Twitter who might cut off your access. Often enough, we talk about proprietary databases and lock-in worries. Building on a proprietary library like Akka isn't that different. You're going to be beholden to Lightbend.
I do think that we are too averse to paying for things, but I also genuinely fear the land-and-expand strategy that so many companies have. Maybe it's just $10,000/year today, but that could easily skyrocket under certain circumstances - and it's not always easy to migrate off something once you're on it.
Re: Scala isn't fun anymore
#274Earlier quoted context omitted.
> I think you're vastly underestimating the amount of work required to support a platform like Android. That might be so, but you're not giving me a chance to change my view. I don't know, and don't care honestly, how many people are working on what; I'm asking what did those people do, specifically, that required such an immense amount of work, and what they have to show for that effort. And of course, how many peop…
I'm not going to try to explain why developing and maintaining tooling takes resources. However, a few things: - Lightbend isn't involved in Scala 3. - Martin Odersky has taught students for decades and knows how to make Scala more accessible. He wasn't afraid of stirring controversy with new keywords and the brace-free syntax. He also has enough industry experience and connections to realize what matters for the eco…
> why developing and maintaining tooling takes resources.
Developing and maintaining anything takes resources, tooling is not special at all. Yet, you still didn't say what exactly does Kotlin do that's so resource-intensive that it's impossible to replicate for Scala for the reason of lack of resources only. Do you know Kotlin's tooling?
> Lightbend isn't involved in Scala 3.
I don't get what you mean? I mean, so what? I just opened scala-lang.org - which seems to be an official Scala web page - and the information that Scala 3.2.0 was just released is at the very top of the page. It's not like PERL and Raku. And what does it matter who is involved in what if we're talking about the tooling for the language as a whole?
> Martin Odersky has taught students for decades and knows how to make Scala more accessible.
Apparently not via investing in tooling, though? If you ask Matthias Felleisen[1], who happens to also have been teaching students for 40 years at this point, he'd tell you that tooling is important for accessibility[2].
> He wasn't afraid of stirring controversy with new keywords and the brace-free syntax.
I don't know who would, actually. I'm sorry, I don't understand this sentence, could you please explain what you mean by this?
> There's no evidence for some kind of missed opportunity between Android and Scala.
I'm sorry, but that's just you being in denial. I don't intend to dispute Martin Odersky's credentials, that's completely beside the point. The point is this: in June 2019 Scala was 28th and Kotlin was 43rd on the TIOBE Index. Now, Scala is still ahead: 33rd place vs. 34th for Kotlin. And you have to account for the fact that Kotlin is almost 7 years younger. Sorry to break it you, but that's not how a healthy language's growth looks like. Clearly, there's something wrong somewhere. My interpretation is that Scala missed many chances, and disastrously so - one of them being Android development.
It's a bummer, really. I read Odersky's book in 2005, I still have the PDF. I really liked the concept of a scalable language, expressive at all levels of complexity. I learned Scala in 2009, then brushed it off in 2017. I see Kotlin for what it is: a pragmatic knock-off of Scala and Groovy. Groovy did not, but Scala had a chance to win over millions of Android developers (in addition to thousands in data centers), but blew it. I'm not happy with that.
(The other great language that could have done better but largely blew it is of course Clojure (currently 47th), but then again, they had it way harder given the language's features)
> Scala's standard library is
> rich,
I don't have a quick way of checking, could you maybe check how many classes/(other relevant entities) are there in Java and Scala respective standard libraries? I strongly suspect Java's bigger. And even that is nothing in front of Python or VW Smalltalk.
> heavy,
Why is it heavy and in what way? Too much code generated? Too big a JAR to include?
> focused on immutability,
All default (ie. used most often in idiomatic code) collections in Kotlin are immutable; the practice of favoring val over var is identical in both languages.
> not always interoperable with Java's.
What do you mean? These are all classes compiled to the same bytecode, how could they ever not be interoperable? Do you mean that you need to convert (for example) collections before you can call methods provided by Scala/Java-specific class? That's perfectly normal and counts as interoperability, and quite a high-class one at that (I mean, try to convert BEAM's list into Python's via C extension and you'll see what "not always interoperable" means...)
> Kotlin's standard library is very small
Again, can't check it easily, but yes, I get the impression that Kotlin's stdlib is a bit smaller than Scala's. Not by much though. They're both just tiny. Well, not JS-level tiny. Probably somewhere around Scheme's R7RS or OCaml.
> and heavily inlined in comparison.
Again, Scala compiler is supposed to be "intelligent enough" to produce code faster than hand-written Java in some cases! How come such a compiler has problems inlining the code of stdlib, arguably the most optimized code of all in any language? What weird things are happening in that stdlib that the compiler has such a hard time inlining them?
> On a mobile platform, this matters.
Sure. But you just said it doesn't matter for Scala, because it's happy powering server middlewares and big data frameworks, even if it means loosing out on a lot of mindshare, contributors and all that.
[1] https://en.wikipedia.org/wiki/Matthias_Felleisen
[2] https://racket-lang.org/ and https://docs.racket-lang.org/drracket/interface-essentials.h...
Re: Scala isn't fun anymore
#275> but the ecosystem is essentially a microcosm of the US political landscape. I’m guessing all programming communities are turning to this nowadays. As an Eastern European, however, it kind of pisses me off. Yikes! It's unbelievably exhausting to hear white folk say that they don't want to deal with the consequences of European colonialism. Racism exists. You can either be anti-racist or pro-racist. There's no middle…
Uh,is he white? did he even mention race? The fact you just immediately went rage mode before asking questions just proves his point.
He did mention race by referring to the "politics" in Scala, because this refers to a specific event. You can learn about it here [1]. I presumed that this was common knowledge because it is widely known in the Scala community: perhaps I assumed too much.
And yes, he's white. You can verify this for yourself by looking at the blogpost author 's About page, a video from a talk they did [2], and with their self-identification as eastern european.
I'm unsure if you meant to do this, but your comment comes off as gaslighting: you don't know what's going on and you asserted something that is false as true. Next time, if you're not certain about what's going on, I encourage you to do a little bit of Googling.
[1] http://meta.plasm.us/posts/2020/07/25/response-to-john-de-go...
[2] https://slideslive.com/38908144/a-tale-of-two-monix-stream
Re: Scala isn't fun anymore
#276Earlier quoted context omitted.
In the end, having a 'more expressive' language isn't the key competitive advantage. At least, I can't recall when a company seems to have significantly outperformed a competitor because they used a 'fancier' programming language. Yes, of course, the blogposts by PaulG and how reddit started, but I'm not sure that reddit is succesful because they programmed it in lisp at first. Twitter specifically was designed in a…
> So, if that isn't the competitive advantage, why go for it in the first place? At least blue collar languages have much, much larger pools of competent programmers to select from, which is an objective, convenient upside any manager can understand. I think its like Haskell, Rust, Go, Erlang, etc. These languages are extremely useful in the microcosm of places where they excel. Rust when you absolutely need to insur…
I think one issue is use cases that fall in-between. For example I use a lot of Python, but also need statically compiled, safe and solid language, with large ecosystem, with great Python interop. What do I choose?
In practice the answer seems to be C++, maybe Rust. I'd happily use a "simpler" language like Go, Java or Nim, but something doesn't quite match the spec.
I think, unsurprisingly, languages are designed around common use cases, but the uncommon ones are there too.
Re: Scala isn't fun anymore
#277Earlier quoted context omitted.
> there isn't an immediate difference between the two types of calls anymore (when looking at the code) There is: sync calls don't change. Async calls use the Future::fork call, all within your parent thread block scope.
Are you saying that Thread.sleep() will still be blocking its OS-thread completely so that this thread executes no other code until the end of the sleep call? Because otherwise your claim "sync calls don't change" is wrong - since this is how it currently works.
That's the very definition of what sleep() does, and the reason why, if you're calling it in an async context, you need to dispatch it in a special "blocking" dispatcher, as opposed to the other regular async calls.
Re: Scala isn't fun anymore
#278Earlier quoted context omitted.
Still here having fun with PHP :) PHP 8.2 isn't Haskell but the type system is reliable and usable. There are a few gotchas here and there, almost always due to backwards compatibility, but nothing like earlier versions, and IMHO not more than other popular languages.
No, PHP since 5.3 is just pseudo Java.
[deleted]
Re: Scala isn't fun anymore
#279Earlier quoted context omitted.
I have personally spent so much time fussing with runtime ClassDefNotFound and MethodNotFound errors in Java that I am no longer able to respond to assertions that Java is type-safe with anything but an incoherent stream of cursing and rage tears. But Scala somehow seems to take all of that and intensify it. I have heard that Scala 3 is supposed to improve this, but I don't anticipate being able to adopt Scala 3 befo…
Those sorts of java runtime errors largely depend on programmers' insistence on doing things via reflection, and it will be the same in any programming language: Like most drugs, at first reflection seems you've opened a new door into enlightenment, until eventually you find yourself sleeping in a gutter with half your teeth missing and wondering why it didn't work out as expected. A lot of Java open source is addict…
I don't think that this is entirely fair to Java programmers. Java's designers decided early on to lean fairly hard on reflection. Not just by giving Java strong reflective capabilities, but by sometimes deliberately choosing not to give Java great facilities for solving problems without using reflection.
When I first came to Java from .NET, I was initially shocked at how heavily it was used in the Java space. (.NET arguably has even more powerful reflection facilities than Java does, but they are typically avoided at all costs.) But it didn't take me very long to realize that many of the C# language features I would have chosen to use instead of reflection simply don't have equivalents in Java. So, I don't think that it's necessarily that Java developers are addicted to this stuff, so much as that they just haven't been given any other choice.
Re: Scala isn't fun anymore
#2801. SBT was never fun
2. I don't believe that scala-native was a good idea in the first place, because of all the java-interop boilerplate already present. C/JVM interop design conflicts are very hard to abstract properly. It would've been nice to adopt some WASM-compatible IR instead of MLIR/LLVM lock-in.
3. WASM-first is a very viable AOT+PGO option, it also brings new opportunities for remote exec and some interesting Architectural Approaches like automagic splitting monolith into microservices on the fly by potentialy calculating communications overhead and performing basic discrete optimizations.
So, Scala is still fun, just missing a lot of business oportunitites, it's just that Odersky decided to take another spin of EU Grants acquisition by developing a new lang.
I, personally, don't think that dotty was "good enough" to roll out last year, but overall project traction and cash-flow directions don't look that promising. And I personally choose to call it EU Budget Laundering, because it's really puzzling for me how exactly 60mil Euros grants are not enough to make Dotty stable. If no-one audits than no-one cares about it, or how does laundering and embezzlement work nowadays ?...
From a lang design standpoint, there are three things which make Scala obsolete
1. No proper formal verification - although there are things like stainless (stainless.epfl.ch) and it would've been possible to adopt zero-GC alloc during codegen by adopting CoC similarly to neut (github.com/vekatze/neut)
2. No proper support for protodef and IDL's - nowadays efficient serialization (marshaling) defines software reliability, all these JSON'y/Protobuffy/Flatbuffy thingies really causing some traction, although every single one of them are not something I'd call scalable.
3. Adopting Calculus Of Constructs (CoC) and formal verification alongside bunched-separation logic (like in F-star lang and rust) should be enough to formally prove Mem consuption, amount of IO and the respective computational overheads. Basically it would've worked similarly to CAP: pick either small mem footprint and bandwidth needed - the amount of compute power and the respective latency will be calculated and formally proven.
The exact desings of separation logic for multi-threading apps is a complex subject, but I like what Azalea Raad done with Concurrent Incorrectness Separation Logic (CISL) - it's something that would've allowed rust, for instance, to drop it's boxed types for RAII and a lot of the existing sync primitives (Arc, Barrier, Condvar, PoisonErr etc).
But who am I to talk about that... I never boiled in the Sciency Kettle and Played by the Academic Tribe Rules, spending half of my life just to copy-paste generic paperworks from here and there, filling up the gaps by slaving the Kenya/Nigeria students on forced contract terms, with usual threats, IP Extortion, common worker-contractor misclassification.
Everything professory Academic-related looks so corrupt for me nowadays.