26 ms·

Scala isn't fun anymore

• cumwolf 4y ago
  i have similar dependency complaints about flutter. I revisited a flutter project that was <1 yr stale and it took me days to resolve all dependencies, i ended up giving up and removing many dependencies and refactoring around it.
• aslak 4y ago
  It was always an ugly pairing of Java and worst of functional programming imo
• saberience 4y ago
  I don't have a ton to say here, the article says it all really. But this also reflects my experience when developing with Scala and although I love the language and its brevity, I went back to Java because I hated the Scala toolchain, sbt, dependency issues, etc. Basically, I like the language in isolation but the overall experience was horrible.
  • smrtinsert 4y ago
    Honestly Java is lately the best it's ever been, at least for backend services. So much power in the frameworks (ok Spring Boot) with so many powerful libraries and tools and available apis. You really feel like you can do anything with it lately.
  • badpun 4y ago
    Java has the same dependency issues? I vividly remember spending days on jars shading in Maven. Basically, a single approach that would solve this, irrespective of the language, would be isolating dependency trees of every library from each other, essentially duplicating the code of many common libraries in RAM (like Docker, but for libraries inside the same process). There's an option to do that in Maven, but it's not the default. And it still would not work for dependencies where there should be only a single instance of it in RAM, like for example loggers...
    • mbfg 4y ago
      One thing is Scala plays fast and loose with backwards compatibility. So much so that akka actually prints out messages if they find jars with different versions. It's a pain in the arse.
    • zokier 4y ago
      > Basically, a single approach that would solve this, irrespective of the language, would be isolating dependency trees of every library from each other Doesn't solve the problem completely because it is normal that applications need libraries to interoperate; consider case where application is passing objects between two libraries that both use types from a third library.
      • badpun 4y ago
        Then your app would explicitly be doing the impendance mismatch resolution (converting objects from one version of library to the other) when doing the library calls.
        • CrimsonRain 4y ago
          which someone would have to code in as that's not automatically possible all the time.
      • jayd16 4y ago
        You're pretty much screwed in that case but that's kind of by design and the entire point of versioning, isn't it?
      • layer8 4y ago
        A major problem is that Maven (and friends) doesn’t distinguish between API dependencies (the API of a library using types from the API of another library) and implementation dependencies (a library depending on another library as an implementation detail). If that distinction were made consistently, implementation dependencies could indeed be separated into a dedicated classloader for each library, and you’d only have to worry about API dependencies, which would go a long way. The Java 9 Modules architecture would have been an opportunity to introduce something like that, but alas they didn’t.
  • cryptos 4y ago
    A good middleground is Kotlin. You get some of the nice features / syntax from Java without the problems. While Scala is actually a way more powerful language, Kotlin is more than good enough for most real world tasks and the tooling is so much better.
    • jillesvangurp 4y ago
      Exactly, you might even go as far as to say that Kotlin exists because the people at Jetbrains looked at and dismissed Scala as just not what they were looking for in a language. And then they went on to develop Kotlin instead. Kotlin is unique in the sense that the language originated from a company whose primary business it is to provide developer tooling and IDEs (intellij). They know a thing or two about what developers like and appreciate in their products. It shows. This language is very nice to use for programmers. Lot's of clever syntax that minimizes boiler plate. Lot's of clever IDE support. Lot's of convenient features. Good build tooling. And so on. In contrast, Scala was always a bit all over the place. Lot's of different takes on how to do things; not all of them very successful in retrospect, tooling was a bit iffy, and so on. It's the reason Kotlin got popular with Android developers early on because it provided a massive improvement over plain Java and sort of worked as a drop in replacement and was easy to switch to. As soon as Kotlin became available (pre 1.0), the Android community was all over it because at the time they were stuck with a pretty outdated Java language version. It did not take long for Google to make it the language of choice and start providing lot's of Kotlin focused updates to their SDK. For the same reason, it got popular with Java backend developers early on. It doesn't really matter what Java backend framework you use; Kotlin is a drop in replacement for Java and the chances are pretty good that your framework of choice already has extensive Kotlin support in the form of Kotlin DSLs, extension functions, etc. That's certainly true for Spring/Spring Boot, Quarkus, and most other mainstream server side Java frameworks you can name. The comparison with Scala is fair because a lot of Kotlin libraries are inspired by work in the Scala community. Additionally, it seems a lot of former Scala developers are now doing a lot of Kotlin. For better or for worse, it seems to compete pretty effectively with Scala. Either language of course is a pretty big improvement over Java; even with the improvements that Oracle has been trickling in over the last few years.
• auggierose 4y ago
  This guy loves sbt. For me it's one of the main reasons to use TypeScript instead of Scala.js. npm is so much better. I have been writing a lot of code in Scala.js and Scala about a decade ago, but thinking now of it, I feel only dread. Scala the language is nice enough, but the whole ecosystem around it is so stuffy.
  • hocuspocus 4y ago
    Give Mill a try. You need to realize the Scala ecosystem is not monolithic. Things are mostly fine if you stay within a corner, but can get complicated when you start mixing dependencies from multiple domains. I think that is true for many languages. The JVM ecosystem is rich, and that comes at a price.
    • auggierose 4y ago
      Oh, didn't hear of it, interesting. But anyway, I am focusing on the browser these days, and a Scala.js that a) doesn't interoperate with TypeScript b) doesn't allow me to author npm packages is too much of a hassle.
    • jodersky 4y ago
      Seconded. Mill is a very versatile build tool. It mainly focuses around modeling builds as DAGs of tasks, and thus allows you to only rerun what is necessary after changes. Other tools like Bazel are built around this model too, but IMO Mill has "taste" in the way it is configured. It also gets out of your way, you can seamlessly integrate it into various shell scripts, and you don't need to make your project revolve around your build tool.
  • vips7L 4y ago
    I yearn for maven after having to use sbt the past few years.
• nivenkos 4y ago
  Now I just miss Rust when writing Scala.
• smallerfish 4y ago
  Kotlin is a fine middle ground. I would say that coroutines was a misstep (though that's a matter of taste), but otherwise their choices have been pragmatic, and their multiplatform efforts are impressive.
  • matsemann 4y ago
    Yeah, the interop makes Kotlin also a hundred times easier to test out. No changes to setup or tooling, just drop a few lines in your pom.xml and you're good to go. But curious, what's wrong with the coroutines? For some projects I've found them a nice abstraction when you have lots of IO-bound tasks, and they're bound at various places in the code making use of a single executor+threads/tasks hard to scale.
    • smallerfish 4y ago
      > But curious, what's wrong with the coroutines? Maybe I need to revisit them, as I've only used them (on 1.6) in the context of kotlinjs (which has a limited implementation) so perhaps my impression is flawed. That said, I didn't like how viral they are in the codebase. In an executor/thread paradigm, you can box up the asynchronous behavior quite cleanly; in a codebase that uses coroutines, I ended up propagating `suspend fun` up and back in my codebase.
      • matsemann 4y ago
        Ah, yes. The "which color is your function" is a bit problematic, but nothing inherit to Kotlin's approach I feel. I'm having the same issues in an asyncio python project now, for instance.
        • vips7L 4y ago
          I am so happy Java chose not to color functions with its implementation.
          • matsemann 4y ago
• petesergeant 4y ago
  > the ecosystem is essentially a microcosm of the US political landscape what does this mean?
  • amval 4y ago
    It's hard to answer meaningfully without risking starting a pointless debate in the comments or being fully honest, but I will try: There are two FP ecosystems inside the Scala community with a very adversarial relationship towards each other. The root is that many years ago the lead developer of one of those FP communities allowed (based on community feedback) a speaker to give a technical talk. There were some people demanding that he'd be cancelled based on his right-wing views. This evolved into a full-blown conflict with serious accusations over the years about political alignment. I am not a member of the Scala community but are interested on the language and somehow this conflict kept popping up. I agree with the author about the "US political landscape" microcosm: the conflict felt absurd and completely blown-out of proportion to me as an european.
    • threeseed 4y ago
      Note this all happened years ago and thankfully the community has very much moved on. Travis one of the guys involved has even left Scala to do his activism work full-time.
      • hocuspocus 4y ago
        I don't think the community was allowed to move on. JdG has repeatedly behaved like an asshole and poured fuel on the fire with Typelevel people who never cared about that original LambdaConf drama and his feud with Travis. Instead of moving on, he decided to make more ennemies, to the point several library maintainers don't want to touch anything even remotely related to Zio.
    • bigbillheck 4y ago
      That speaker wasn't just anybody with 'right-wing views', it was 'Mencius Moldbug' himself. (See, for example: https://www.unqualified-reservations.org/2013/09/technology-communism-and-brown-scare/ https://www.unqualified-reservations.org/2013/09/technology-...)
• threeseed 4y ago
  I actually think Scala is in the best position it's ever been. There is a commitment to making the language simpler, easier and cleaner. On the backend, ZIO (https://zio.dev https://zio.dev) is the best concurrency library on any platform. On the frontend you have really interesting Scala.js projects like Laminar (https://laminar.dev https://laminar.dev). The biggest issue really is the tooling. SBT is simply awful.
  • brightball 4y ago
    On any platform?
    • threeseed 4y ago
      It has the ability to make real-world concurrency scenarios trivial e.g. * 3 fibers - each fetches from remote storage, local storage and in-memory cache. * Race them, kill the two slowest and give me the result. * Free the resources safely including if any of the connections fails for an unforeseen reason. That's a few lines in ZIO. Pain to get working properly in Java, Rust, Go, C++ at least.
      • bdangubic 4y ago
        This is exactly the kind of problem that 0.000324% of us are having while being productive in Java/Rust/Go/C++ ... ;)
        • geodel 4y ago
          Thats the thing with Scala, they are solving important problems. It is not spending time on useless problem like performant build system. I mean code is gonna compile eventually, if not today maybe tomorrow. But complex problem like described above will not be solved unless someone make a decent framework for it.
        • misja111 4y ago
          In the last 10 years every team/company I have been working in had to deal with at least one of these problems. Good for you if you only ever have to work with single threaded applications, but for most of us the reality of modern software development is different.
• adamdecaf 4y ago
  I wrote scala for six years and was on the team to first deploy akka in production. I've seen Json libraries come and go while also struggling to read files written with OO and FP patterns intermixed. Scala can be beautiful but in practice it gets messy. Switched to Go four years ago and I've never looked back. Go made programming fun again just like PHP did before either of them.
  • user3939382 4y ago
    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.
    • cutler 4y ago
      No, PHP since 5.3 is just pseudo Java.
      • deleted 4y ago
        [deleted]
  • xwowsersx 4y ago
    hmm, did we work together then? :) Always thought I was on the first team to deploy Akka in production.
  • dionian 4y ago
    to be fair, using Akka was mostly never fun, avoiding that improves the scala experience dramatically.
    • cryptos 4y ago
      I was part of a team that processed really large files (hundereds of GB) in an Akka cluster. At that time Akka seemed like a clever choice to us, since we were Scala enthusiats and Akka was the framework of the day, but it took us many weeks to master (more or less) Akka. We could have done the same in a more robust and manageable way with Spring Batch in a fraction of the time. Akka had a really steep learning curve for doing relatively boring things. Technically it was quite interesting, a from a business perspective it was a desaster.
• ctrlmeta 4y ago
  > I’m also having affectionate memories of JavaScript and Python I am afraid, things are equally messy in JavaScript and Python too. "X language isn't fun anymore" is exactly how I feel about X = JavaScript, X = Python, X = C++, X = Java and many other languages. There was a time when I found Python and Js to be very fun languages. But recently the ecosystem has been becoming a mess. Build breakages on dependency upgrades are the biggest fun-killer IMHO. Heck, there was a time when I found even Java to be fun. C++ too was fun in its early days. But every language keeps adding more syntax, more complexity and more ideas that deviate from the original design goals of these languages. These additions make the languages messy and the simple and characteristic ideas for which the languages were once loved get lost in all the complexity. I find it really disappointing. I really wish the languages preserved their original culture and philosophy. For the never-ending and ever-increasing churn in all the languages I have gradually gone back to adopting Emacs Lisp and Common Lisp for all my personal programming needs. Common Lisp's standard is frozen in time, so for better or worse, I am protected from the constant churn I see in other languages. Emacs Lisp has a really good leadership that has been very wise to avoid adding additional complexity to the language. I wish the more modern languages were more reluctant in adding new complex ideas into the languages.
  • Helmut10001 4y ago
    Even Markdown is further distorted the more time passes (and it isn't even a programming language).
    • pwpw 4y ago
      How so? I only use basic markdown (e.g. for ReadMes and quick note taking), so I'm fairly ignorant.
      • Helmut10001 4y ago
        Yes, but some 'central' agencies push for specific Markdown formats/use. E.g. Nextcloud [1] wants to use Markdown as a format, to save the output of their wysiwyg text editor. Everytime you open a Markdown file in nextcloud-text, it is 'formatted' correctly, according to the Commonmark specs, and written back, _without_ asking the user. [1]: https://github.com/nextcloud/text/issues/593 https://github.com/nextcloud/text/issues/593
• hocuspocus 4y ago
  The irony here is that the dependency hell within pure Scala libraries has improved tremendously and is not really a problem anymore, yet we need to deal with many binary compatibility issues due to transitive Java dependencies. Things that regularly cause issues, for instance when assembling JARs that get shipped to a Spark cluster at work: Guava, Jackson, Kryo, Log4j, Hadoop's transitive dependencies (like Netty) ... not Scala's fault.
• the_duke 4y ago
  The 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/ 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 if your company earns over $25 million in annual revenue I guess Lightbend is really struggling, but this is probably the end of Akka outside of niche markets / large enterprises. edit: HN discussion - https://news.ycombinator.com/item?id=32746807 https://news.ycombinator.com/item?id=32746807
  • halfmatthalfcat 4y ago
    2.6.19 will be forked and a community-driven Akka will emerge eventually.
    • jsiepkes 4y ago
      Has a champion risen to the task yet? Forking a project is no easy feat. Certainly not one the size of Akka. You need a corporate backer who is going to put at least one person full time on it. I've seen plenty of forks start out with the best of intentions only to slowly fade in to nothing.
      • halfmatthalfcat 4y ago
        It's only been a week since the announcement, I'd expect it'll take a while.
      • Test0129 4y ago
        https://www.theregister.com/2022/09/08/open_source_biz_sick_of/ https://www.theregister.com/2022/09/08/open_source_biz_sick_... Here's an article on it. Their logic actually makes sense. Not that I support gouging customers, but when you consider how there are massive billion dollar companies with expensive lawyers figuring out how to end-around OSS (via SaaS, etc) this is the logical conclusion. A lot of companies make a lot of money on OSS and give little to nothing in return. This isn't in the spirit of OSS but company men don't really care. So it seems like Akka finally got sick of it and is now coming to collect its (without question) overdue paycheck from these people. It's just unfortunate they went so aggressive with it. $2000/vCPU/year will do a lot of damage to smaller projects in the process of sinking the billion dollar open source leeches in the process.
• keewee7 4y ago
  The commercial entity behind the Scala language didn't do enough to make it more usable for Android developers. It has been downhill ever since.
  • hocuspocus 4y ago
    I really wonder why every time Scala is discussed on HN, someone wants to rewrite history about some mythical synergy with the Android ecosystem. This is so bizarre. In what world would Typesafe/Lightbend have found the money and resources to pull off even a fraction of what Jetbrains did with Kotlin? Let alone convince Google. On the other hand I'm very happy Scala isn't tied to the Android runtime.
    • klibertp 4y ago
      > In what world would Typesafe/Lightbend have found the money and resources to pull off even a fraction of what Jetbrains did with Kotlin? Let alone convince Google. What did Jetbrains do with Kotlin that required money and resources outside of Scala's community reach? (Also, what do you mean about convincing Google?) I learned Scala a few years back and am working with Kotlin this year. I use Android Studio - I expected to be mind-blown with the IDE support. I wasn't. The only feature worth mentioning is the automatic conversion of pasted Java code to Kotlin, which is really trivial to implement if you have tools for working with AST of both languages and a bit of free time. Scala is handicapped here, last I checked, and only got better with version 3 rewrite, but if that's a killer feature for Kotlin, then replicating it for Scala by heaping regexes until they cover 95% of cases would also work. I honestly don't see anything in Kotlin and the IDE that couldn't be implemented for Scala as a plugin, if there was interest in that.
      • hocuspocus 4y ago
        I think you're vastly underestimating the amount of work required to support a platform like Android. How many people are directly employed by either JetBrains or Google to work on the Android + Kotlin story, vs the total number of Typesafe/Lightbend employees at its peak... which has always been burning through VC money and is financially struggling even after focusing on their core knowledge domain. > (Also, what do you mean about convincing Google?) Google decides what Android becomes or not. What makes you think they would have been interested in Scala in the first place? Even if someone did the integration work for free (which is an insane premise), Google likes boring languages. Plus, Scala's standard library is somewhat at odds with a fast and lean mobile runtime.
• rjh29 4y ago
  > Maybe this is just me getting older (going to turn 40 soon). Maybe all programming is terrible. Similar age and that is my experience. There are just so many roadblocks, things that don't work properly and you need to mess around debugging or googling github/stackoverflow to resolve before you can get to the fun part. I'm sure this was the same when I was younger, but I had more energy and was able to plow forward regardless.
• killingtime74 4y ago
  I love Scala, now I love Rust
  • valenterry 4y ago
    They are both awesome. Good reasons to love them both even though they both have their problems. :)
• cube2222 4y ago
  I think one more problem with Scala, apart from the lack of stability and having to solve the language's problems instead of your application ones, is one of local maxima. Most of the ecosystem uses monads. And the way most projects end up using monads is have "the one monad" that every function returns. ZIO is an example of that. Understandable, since the alternative is to have tons of different function colors. However, since in that case the monad really is just a configurable semicolon semantic, you've just gone full circle and chosen a single global one. And in that case, why not just choose a language where that semantic already is the core semicolon semantic of the language? You're living with a ton of complexity for very limited gain.
  • azernik 4y ago
    1. Because different projects will want different monads 2. In my experience, having up-conversions between different monads is intuitive low-noise
    • cube2222 4y ago
      > Because different projects will want different monads It doesn't look like that to me, based on how the ecosystem currently converges on a single one. I understand there may be some projects that do that, but if the majority converge, then it's still needles complexity. However, I might be wrong. I've been an external observer for a while already.
      • valenterry 4y ago
        History proofs this wrong. Just look at it: first there were Scala Futures and Twitter Futures. Then there came Scalaz and Monix, later Cats-effect. Now ZIO also joined. And each library even brings different kind of effect types. And all of that works, even in combination! This is as if you mix angular and react. Sure, you should try to not do that as much as possible, but the mere fact that you can do this in Scala is a sign of awesome language and library design that is far outstanding compared it the majority of other languages. You could never come up with the "one true solution" from the very beginning.
• mhd 4y ago
  Wasn't this a somewhat common opinion 10+ years ago, when it looked increasingly C++ in its split of user bases (weird operators for one, less boilerplate Java for others)? I mean, that's how we got languages like Ceylon, Fantom or Kotlin.
• jbirer 4y ago
  I think lots of programmers (including myself) get lost in the programming language features and forget to have fun with what the application actually does.
• vips7L 4y ago
  I'm doing a Play framework upgrade at work right now... and boy did the scala ecosystem not make this easy.
• vegai_ 4y ago
  Was it ever? To me it always seemed like a Java with the added burden of functional programming and more complicated OO.
  • therealdrag0 4y ago
    It took some adjustment but I love it now. Not sure I could go back to Java.
• lupire 4y ago
  Programming isn't fun anymore. Modern ecosystem is too complex for fun.
  • runevault 4y ago
    Are all of them though? Web stuff is if you fall down the hole of "everything must be a docker container" and "chase latest JS fads" but I wonder if there is a saner route. Also things like console apps should still be pretty sane, depending on what you are building. However trendy programming has very much become pointlessly complex.
• deleted 4y ago
  [deleted]
• geodel 4y ago
  Regarding Akka situation. I am feeling Java Loom + Structured concurrency[1,2] is coming at write time. I think lot of existing project will try to shove in virtual threads in reactive solution in sub-optimal way and It may not lead to great results. Already an implementation of Loom based server is out[3]. Going by how simple code looks and how performant code is compare to reactive solution even in ALPHA release. I am going to be using it very soon. 1. https://openjdk.org/jeps/425 https://openjdk.org/jeps/425 2. https://openjdk.org/jeps/428 https://openjdk.org/jeps/428 3. https://medium.com/helidon/helidon-n%C3%ADma-helidon-on-virtual-threads-130bb2ea2088 https://medium.com/helidon/helidon-n%C3%ADma-helidon-on-virt...
  • valenterry 4y ago
    Loom will be the next billion dollar mistake after nulls. Keep my words in mind for a decade or two...
    • geodel 4y ago
      Okay, are you going to give reason or is it more of a Thought leader style pronouncement?
      • valenterry 4y ago
        Haha, I guess you are right. The reason why it is a mistake is because it is essentially trying to solve the rpc problem once again even though it has been tried many times without success. There just is a difference between making a synchronous call within your own OS thread vs. making such a call against anything else (the filesystem, the network, ...). Because you can assume that a synchronous call either succeeds and you can continue whatever you do. Or the whole thing crashes because e.g. the thread was killed due to some external effect or OOM error. But in that case, you have the guarantee that no more code on your thread is being run. With Loom, it is not clear anymore if more code will be run based on your call or not, since there isn't an immediate difference between the two types of calls anymore (when looking at the code). This missing distinction is exactly what makes it easier to use but it also makes it very easy to use the "wrong default".
• throwaway91322 4y ago
  If you want your engineers to spend time playing with highly academic libraries that are unnecessarily complex for the business problem you are trying to solve, choose Scala.
  • hocuspocus 4y ago
    Highly academic libraries, because of course companies like Comcast or Disney Streaming are universities.
    • throwaway91322 4y ago
      Red herring.
  • wbillingsley 4y ago
    Although there are some complex libraries available for Scala, there's also a lot of very simple stuff. It's a very expressive language, and sure that lets some libraries do some very powerful and complex things or find new abstractions that'll come across as really complex. But it's also very good for expressing things simply. Earlier this year, I wrote some materials for teaching git in a little interactive OER I've been trying to build up. With Scala, I could write a little git simulation and embed it into my slides and it did not seem like a big undertaking. Across these and the decks after it, there's quite a lot from simulating git, to visualising diff a simple diff algorithm, to doing git graphs that'll sit well in an interactive slide https://theintelligentbook.com/supercollaborative/#/decks/vcs-history/0 https://theintelligentbook.com/supercollaborative/#/decks/vc... https://theintelligentbook.com/supercollaborative/#/decks/vcs-branch/0 https://theintelligentbook.com/supercollaborative/#/decks/vc... https://theintelligentbook.com/supercollaborative/#/decks/vcs-diff/0 https://theintelligentbook.com/supercollaborative/#/decks/vc... to letting students do an in-browser tutorial that tries to simulate a VS Code-like environment https://theintelligentbook.com/supercollaborative/#/challenges/gitLocalTutorial/0/0 https://theintelligentbook.com/supercollaborative/#/challeng... In the JS or TypeScript ecosystem, I think I'd have been hanging off so many libraries that I'd be dreading how fast my dependencies move. Here, I've got a dependency on one JS text editing widget and one JS Markdown parser, and one Scala dependency on (my own) little front-end framework ... and that's about it. The rest I could "just write". Ok, my code ain't fantastically commented because I'm not expecting collaborators, but there's 15 commits in writing the whole darn thing, including the slide decks and interactive tutorial. https://github.com/theIntelligentBook/supercollaborative/commits/main/src/main/scala/supercollaborative/versioncontrol https://github.com/theIntelligentBook/supercollaborative/com...
• misja111 4y ago
  > We’re left with the Scala FP communities, which yield awesome libraries and are awesome people, but the ecosystem is essentially a microcosm of the US political landscape. This sentence puzzles me. Does anybody know what the author could have meant with it? As a European Scala FP programmer, I have no idea.
  • halfmatthalfcat 4y ago
    Typelevel vs ZIO (John DeGoes) drama? Allegations against Jon Pretty?
  • groby_b 4y ago
    If you click on the "Politics" tag (which the author has attached to the article...), you'll quickly learn why. They are a fan of free speech == unrestricted speech. Most larger ecosystems these days have a code of conduct, restricting some forms of expression if they are deemed detrimental to the community. Something that very much riles advocates of unrestricted speech. Often, having a code of conduct is conflated with social justice activism - a movement that is prominently lamented in US politics more so than Europe. Note: I'm not interested in debating which side is right here, or if that conflating of positions makes sense. Just pointing out the likely origin of the "microcosm" comment.
    • phillipcarter 4y ago
      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_wondering_about_the_history_of_the/ 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.
      • sp33der89 4y ago
        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!
• icedchai 4y ago
  I worked at a Scala shop, a little over 10 years ago, and it wasn't fun then, either. 1) IDE support was unstable (Eclipse was basically unusable, IntelliJ was better.) 2) Builds were slow 3) Everyone using their own little dialect, and arguments would ensue over whether we should use that feature or not. Perhaps it's better now.
  • whimsicalism 4y ago
    I experience 1 & 2 quite a bit, 3 a bit less but I can totally see how that would be a problem.
  • hocuspocus 4y ago
    It is.
  • esarbe 4y ago
    It is, by quite a bit. While the "Scala IDE" project is dead for all practical purposes, IntelliJ IDEA's Scala plugin is actually pretty amazing. There's also a VisualStudio plugin that does pretty much the same and is advancing by leaps and bounds. There are also interconnecting projects that provide i.e. language server or build server that are reused by other projects. It's pretty modular. Metals (https://scalameta.org/metals/ https://scalameta.org/metals/) is amazing. In general the language has become a wee bit faster to build, there was good progress with build times during the 2.12/2.13 cycles. With Scala3 the language got a bit simpler; concepts that were implemented explicitly using (hehe) implicits got their own keywords and a lot of the opinionated boilercode that cause a lot of debates is now generated during complication and hidden. A lot of "standardization" has occurred.
    • valzam 4y ago
      I think the IDE issue still exist in many projects due to the complexity of generic FP libraries + bad support for scala 3. The last scala project I worked on used scala3 + cats and it was very touch and go if we could continue using this stack due how flaky intellij behaved. Multiple times a day autocomplete would just stop working. This btw was noticably better in scala 2.13.
• SkyMarshal 4y ago
  What does he mean by this? (Figuratively, or literally?): ”We’re left with the Scala FP communities, which yield awesome libraries and are awesome people, but the ecosystem is essentially a microcosm of the US political landscape. I’m guessing all programming communities are turning to this nowadays.”
  • epgui 4y ago
    I have the same question.
    • dionian 4y ago
      https://www.reddit.com/r/scala/comments/d06fkf/effective_today_john_de_goes_has_been/ https://www.reddit.com/r/scala/comments/d06fkf/effective_tod...
      • epgui 4y ago
        What does that have to do with US politics? Seems to me to be a bit of a tenuous link.
  • dionian 4y ago
    I just ignore the political people and often choose the libraries they hate, having a lot of fun
  • jackcviers3 4y ago
    They are speaking of the feud between ZIOs creator John de Goes and long-time Typelevel steering committee member Travis Brown (https://meta.plasm.us/posts/2019/09/01/jdg-and-the-fp-community/ https://meta.plasm.us/posts/2019/09/01/jdg-and-the-fp-commun...) and split the community along those same party lines.
    • phillipcarter 4y ago
      Some other important context is this is around peak controversy time around codes of conduct in all programming communities. Some degree of political fighting was going to happen one way or another, but it was made substantially worse by decisions made by the Lambda Conf committee at that time to allow Curtis Yarvin to speak. You can read their rationale and it's clearly well thought-out, but in hindsight it led to a much worse outcome than if they just dropped him. Subsequent conferences after 2016 and 2017 were uneventful and uncontroversial, but the shadow of those years would never go away. It's also a very US-centric kind of political battle that I'm sure a lot of European Scala programmers feel is strange and doesn't apply to them, but has nonetheless taken their ecosystem by hostage.
• dionian 4y ago
  Same exact problem existed before scala. I also agree it's not fun.
• rufius 4y ago
  Scala the language is fine. Not my favorite - it’s a little conceptually big for my taste but that’s a preference thing. Scala the ecosystem was never fun though. I can’t decide if it’s worse than JavaScript (NPM upgrade hell sucks hard).
  • dhosek 4y ago
    When I saw the whole having to include the compiler version in dependencies I lost interest in Scala fast. I’m using it now for work, and it’s—fine—but there does seem to be a lot of fragile magic involved with it.
• kardianos 4y ago
  Golang has two great things going for it: 1. Emphasis on API stability. 2. Simple dependency management that generally just works.
  • shakow 4y ago
    Go dependency management sucks hard as soon as you leave the ‶everything open source on Gihthub″. Having to change my global git config (e.g. https://gist.github.com/dcyou/06a4f6e0a770887fbd01fa8276b945c0 https://gist.github.com/dcyou/06a4f6e0a770887fbd01fa8276b945...) to cater to Go is asinine.
• SanjayMehta 4y ago
  Having tried to use Scala only indirectly via a DSL and having given up for various build issues, I thought it was only due to my ignorance of the system. But having said that, this paragraph jumps out as completely perplexing: "We’re left with the Scala FP communities, which yield awesome libraries and are awesome people, 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." Please don't tell me there are political camps in FP now.
  • dragonwriter 4y ago
    > Please don't tell me there are political camps in FP now. All nontrivial groups of humans end up with political camps. If you don't notice it in a space, it probably means that there is one dominant political camp and it is the one you are in.
  • malcolmgreaves 4y ago
    > Please don't tell me there are political camps in FP now. Nope. Well, politics is pervasive because politics is just the word we have to describe how people in groups interact. I'll summarize the situation: There's a very small minority of prominent Scala people that are fine giving space and a platform in the community to people that are known white supremacists. [1] It's unfortunate that they're decided to inject their brand of politics into the Scala community. The community has had to respond by adopting codes of conduct that compel members to act with basic decency and morality. [1] http://meta.plasm.us/posts/2020/07/25/response-to-john-de-goes/ http://meta.plasm.us/posts/2020/07/25/response-to-john-de-go...
• Test0129 4y ago
  > Maybe this is just me getting older (going to turn 40 soon). Maybe all programming is terrible. I’ve actually started to read Java newsletters, maybe Spring isn’t that bad, I’m also having affectionate memories of JavaScript and Python, and thinking about having a plan B in case this programming thing doesn’t work out The older I get the more this rings true. I've had several false starts with fancy new languages and consistently yearn for the simplicity (relatively) and lack of choice the old times had. I've been programming a lot of personal projects in C because of that. Rust is cool but too much headache and still too "fresh" to be more than just an academic exercise for me. Go is the same, except im actually insulted at how limited I am with it. etc. Yea, this is probably me getting old. But I like to have one or two languages I can get things done with it. I've been programming Python since the early 00s in one form or another betting on it replacing Perl, and C has always had a charm to it C++ could not give.
  • rzwitserloot 4y ago
    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 time when RoR was really popular, but I'm not sure it worked _because_ it was built in RoR, and we all remember how twitter still exists simply by the grace that they managed to rewrite themselves away from the fail whale before competitors woke up to match their feature set. Now it's written in scala and, to me anyway, I see hundreds of developers and I'm not _at all_ impressed by their development momentum, even though it's written in scala. 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.
    • Test0129 4y ago
      > 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 insure memory safety, Go when you need near-C speeds but a simple to use concurrency system, Haskell for rigid typing, Erlang for high availability, etc. The problem is the dead average developer looks at these, and sees these high flying companies doing cool things in it, and then decides "wow I should write everything in this - it's the future!" Scala is the same way. It's not objectively better than a modern java in any way which might be taken as fighting words. But foregoing a lot of developer history you gain the power to reason about a very, very small subset of programming easier at the cost of speed, time, etc. For a company like a twitter with a very specific use case for this it made sense. Especially since at the time twitter switch from RoR to Scala, Python and it's concurrency platform didn't exist. However, I would speculate if they switched today they would've almost certainly gone to Python which would have been a much less "cool" switch and probably not even made the news cycle.
• seinecle 4y ago
  Join the Java community and enjoy the robustness / the lack of headaches!
• haolez 4y ago
  By chance, I happened to stumble across this fringe programming language recently: https://www.unison-lang.org/ https://www.unison-lang.org/ The way that it deals with dependencies seems to fix a lot of the problems that the author has mentioned.
  • moistly 4y ago
    Unison has come up on HN quite a few times. You might want to do a search.
• atemerev 4y ago
  Scala was fun before Typelevel broke the community. I liked Scala when it was a pragmatic, hybrid FP-OOP language, with a powerful actor model implementation. Now, OOP became a curse word, and if you do not do purely functional code with tagless-final and don’t know the definition of free monad by heart, you have no business writing Scala code (I like pure FP too, but if I want to write Haskell code, I can do it in Haskell), and the community drama with “typelevel/cats vs Scalaz” and “typelevel vs zio” was too much for me to handle. The new community is too toxic for me to continue writing anything in Scala. The only bright point in Scala is lihaoyi’s ecosystem, which is sane enough to actually use, but it is too much to maintain for a single person, and it is losing momentum. So I quit, and moved to Common Lisp, which is interesting and pragmatic enough.
  • hocuspocus 4y ago
    It's unfair to put that on Typelevel, but anyone can look up why it exists and judge for themselves. However, Li Hayoi's libraries aren't a silver bullet. I could also argue something like "if I wanted to write exeception-throwing Java code, I can do it in Java." I use http4s/fs2/CE because of the better ergonomics, and I never needed to learn what a Free monad is.
• bigbillheck 4y ago
  I only ever did a few hobby-level projects in scala, never more than a couple thousand lines or so. There were several reasons that stopped me from wanting to go further (sbt being so unpleasant, uncertainty about the future of things with dotty, and a community I didn't want to be associated with (the worst of whom, Tony Morris, having since been kicked out, but still)).
• rr888 4y ago
  5-10 years ago Scala projects were great because the best and most motivated Java developers were keen on FP and this shiny new language which could leave behind legacy code bases. Now Scala codebases are likely legacy projects themselves and the best devs have moved only golang/rust or even Java17.
• kirse 4y ago
  I enjoyed Scala, but I enjoy F# much more. .NET Core is a healthy cross-plat ecosystem, many of the VSCode/F# tooling issues have been eliminated over the past few years (IntelliJ was really one of the core reasons I preferred Scala), plus Akka.NET has F# bindings. Come on in, the water's warm: https://fsharp.org/learn/ https://fsharp.org/learn/ https://getakka.net/ https://getakka.net/
  • timmyboop 4y ago
    How long does it take for someone with about a decade's experience in C# to a point where they can write idiomatic F#?
    • devmunchies 4y ago
      I didn't have c# exp and it took me a month to feel "productive comfort", and less than 2 months until i felt "native comfort". I've been using it for about 2 years now. That said I: • had zero C# experience and it was the C# interop that caused me the most pain. Its easy now but I didn't grok how to properly pass arguments to overloaded C# methods (i kept messing up parenthesis, commas, and didn't pass argument names to tell f# the right function signature) • have been coding for 8 years • have functional lang experience with elixir and elm. Now f# is my primary backend language.
    • kirse 4y ago
      5yrs ago I was roughly the same, depends how much you commit up front. I had minimal FP experience, so I bought "Domain Modeling Made Functional" [1] by Scott Wlaschin and used it for side projects / class libs first. Took about 6 months to experience the full mental shift. Even if you eventually decide you can't commit a team to F#, it's highly worth it because doing at least one app in F# will vastly improve your C# and how you structure applications. [2] I personally just got addicted to the expressive power, it's hard to replicate with any other ecosystem given the full power of .NET under the hood. Giraffe is also a great place to start if you know ASP.NET Core. [3] [1] https://www.amazon.com/dp/1680502549 https://www.amazon.com/dp/1680502549 [2] https://www.youtube.com/watch?v=US8QG9I1XW0 https://www.youtube.com/watch?v=US8QG9I1XW0 [3] https://github.com/giraffe-fsharp/Giraffe https://github.com/giraffe-fsharp/Giraffe
• waynesonfire 4y ago
  good riddance. the only use case for scala is spark and i'm starting to switch to the JavaRDD. Scala should have never entered the enterprise space. Anyone thinking about porting Play to another framework?
• eranation 4y ago
  I'm starting to worry, I had a bet that Flex (Flash based UI component library) would be the future, then I got hyped by Ruby, then I fell in love with Scala, I'm worried about getting hyped about a technology again.
• malcolmgreaves 4y ago
  > 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 ground when everyone lives in a society that is built on the backs of hundreds of years of stolen labor in inhumane conditions. There's not _one part_ of modern, global society that isn't affected by racism. Remember, it's an extreme privilege to look at a part _real life for the majority of people on the planet_ and say "it's just politics."
  • gorjusborg 4y ago
    Uh,is he white? did he even mention race? The fact you just immediately went rage mode before asking questions just proves his point.
    • malcolmgreaves 4y ago
      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-goes/ http://meta.plasm.us/posts/2020/07/25/response-to-john-de-go... [2] https://slideslive.com/38908144/a-tale-of-two-monix-stream https://slideslive.com/38908144/a-tale-of-two-monix-stream
      • gorjusborg 4y ago
        First, I sincerely wish you happiness. There is no 'winning' to be had when we treat people as enemies. I don't know you, but I witnessed your behavior here. My reaction was to your behavior, not to you as a person. > 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 No, I didn't make any assertion. I asked questions based on your attack on the author. You comment was completely out of context of the article, so it seemed off-base. I can understand if you have inside knowledge, but your reaction was still not a good look to the majority of people like myself who are not. > Next time... ...I encourage you to do a little bit of Googling. Your behavior is still illustrating some of the author's point. Some individual/group cultures are cesspools of unhappy/combative people. As someone who has no desire to 'pick a side' of a language community battle, I identified with the author's lack of enthusiasm for a particular community, without knowing all the details. There's nothing wrong with that.
• ragnese 4y ago
  I can't help but notice that the majority of the libraries he mentions are Java-first. I don't have an extremely strong argument that this is the root of many of his problem with version mismatches, but I do have a strong hunch that it is. I've spent a little bit of time with Scala, a little bit with Clojure, and a lot with Kotlin. My biggest conclusion from all these years of working with non-Java JVM languages is that Java interop is actually a language mistake. Or, rather, Java interop ends up being "design debt". It's great to bootstrap your new JVM language into popularity because people can try to gradually switch from Java or use mature Java libraries when your $NEW_LANG ecosystem is still nascent. But, the problem is that Java libraries are written in Java style and are written within the constraints of Java and Java's type system. The most obvious (albeit likely the least problematic) example is null in Kotlin and Scala. Both languages have superior ways to handle the "bottom type" to Java, but a Java library obviously doesn't get to use those. The other problems come from how much information can be expressed at compile time. The biggest design flaw in Java as a language is that it combines type-erased generics and runtime type reflection/inspection. Either one of those is fine, but they are quite literally incompatible concepts. You can't apply type-based logic on a type that doesn't exist. Yet, because of how unexpressive Java's type system is, any sufficiently complex Java library/framework will make ubiquitous use of type reflection. Usually while leveraging annotations. I can't tell you how many type bugs I've found in the JacksonXML Kotlin compatibility module and in Vert.x with Kotlin. Nulls sneaking in where they aren't supposed to, value classes randomly causing issues because something boxes up a Function object and then uses reflection somewhere surprising, things not serializing correctly because JacksonXML or Gson doesn't understand some perfectly valid type I've defined, etc. But something like JacksonXML should never exist in Scala. Scala has type-classes, so you can define your serialization and deserialization logic on the type itself. Then it can be checked at compile time. For Java, defining and passing around a separate serialization object for each type would be too cumbersome, so all of the serialization libraries use reflection and just hope they can figure out the deserialization at runtime. When you find out that it can't because your app crashed, then you can backtrack and "teach" Jackson/Gson how to deserialize your troublesome type with a custom deserializer class and an annotation. And it's not just the type systems being incompatible. It's also the style and idioms. Java frameworks really like to be "magical" and hands-off, because it's so verbose to define and pass around separate classes for everything. I believe this is also manifested in the OP's issues with libraries depending on other libraries and causing version conflicts. If Java libraries were less "plug and play", they would ask the user to provide logic, instead of saying "Don't worry, I'll do everything for you under the hood." Is this just a cliché Java flame comment? Maybe it is. But it's based on my many years of dealing with Java and every popular JVM language (excepting Groovy; I don't have any experience with it outside of gradle). I now have a policy that if I'm working on a Clojure, Kotlin, or Scala project, Java dependencies are nearly forbidden. It's a very high bar to include a Java library dependency, and if it uses generics or reflection, it's basically an instant "no".
• pshirshov 4y ago
  I don't understand why do we have to listen to this boring crap. Most of the article are complaints about dependency convergence. Convergence is completely irrelated to Scala. It happens with any JVM projects and may happen with almost any project for any platform. There are multiple ways to address it. Regarding Akka - let it rest in peace, it was one step ahead and ten steps back. Actors have too many fundamental problems to be a good general-purpose model.
  • troutwine 4y ago
    > I don't understand why do we have to listen to this boring crap. You don't? You chose to read the article yourself of your own free will. At least, I hope you did.
    • pshirshov 4y ago
      This link had been heavily spammed across all the Scala communities over last week. I'm pretty tired of this "useful" discussion.
      • troutwine 4y ago
        Alright, well, this is not a Scala community so I'm sorry you've seen this in your select social circle to the point of annoyance. Still, you aren't forced to read it.
• varelse 4y ago
• yarosh 4y ago
  1. 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.
• gengstrand 4y ago
  While there are some language features in Scala that are a bit of a buzz kill (see https://glennengstrand.info/software/coding/java/scala https://glennengstrand.info/software/coding/java/scala for more on that), the OP is mostly complaining about https://en.wikipedia.org/wiki/Dependency_hell https://en.wikipedia.org/wiki/Dependency_hell The Akka BSL is a big disappointment to me as well but a better name for that would be LightBend isn't fun anymore.
• Shorn 4y ago
  I wonder what this means for Gatling (the load testing tool)? Gatling achieves it's relative low-overhead characteristics (compared to a naive approach like JMeter's) by leveraging Akka. Does this mean Akka lawyers will be coming for Gatling customers, or will they go after a slice of Gatling's pie? Either way, hopefully someone will reproduce the Gatling functionality on the JVM using the Loom programming model. Then we can wait a few years and start the whole dance again. I don't have a workable solution to propose. I guess I'll just quietly polish my dancing shoes and get ready for the next song.
• pqyzwbq 4y ago
  Scala was fun when my company was small. Later, we need to recruit more people, it became harder and harder. Each need to learn a lot before they can contribute bug fix to product. They need to learn: - Scala - Akka - very basic of sbt (if they need to change more than basic usage, they come to me for that change, as I'm the only one who learned complex sbt syntax in our team currently) - Play framework - Slick But now, several years later, Akka's license change really make us to consider switch back to plain Java and Maven one part by another. For the actor model, I really like it, it can simplify Synchronization A lot, we researched Vert.X, which seems can do most of Akka (Although I haven't research whether Akka Clustering, persistent can work similar in Vert.X yet).
• wizwit999 4y ago
  Sound more like issues with sbt, I use Gradle when I write Scala, but I admit I use Kotlin nowadays.
  • hocuspocus 4y ago
    It literally has nothing to do with sbt. Gradle won't save you from binary compatibility conflicts caused by diamond dependencies.
• fithisux 4y ago
  I started looking seriously into Scala 3 without any Scala 2 exposure 6 months ago. I do not need it for any project but I wanted to see what is there. I love it. Also, he does not mention Chisel.