@avinder42 Did you have a chance to check Scala Native compatibility for ZIO DynamoDB? In general lack or limited compatibility is a drawback of all ZIO ecosystem (.

This library really works wonders. It allows for concise, readable, declarative code, instead of many lines of boilerplate. At the same time, concerns that something is out of our control are unfounded. You need to try it and simply see for yourself.

@code A helpful thing, if it were also in accordance with best practices, such as: "7 rules of git commit messages". It could google for it ;-)

@kitlangton Congrats!

I come from Java and Scala. And there I have guarantees when it comes to types. And I fully agree that "Integrating with JavaScript is still dangerous lol". Frontend is not my domain. But out of curiosity, I'll play with ScalaJS and Kotlin/JS to check if it's just JVM-specific, or if I'll also get a high level of type safety when integrating with JS, but I'm more than convinced that I will.

That's the whole story. If you want stability, you wait. And it's relatively short compared to Java, where new features incubate much longer. You can use preview/experimental features, no one's stopping you, but then you assess and account for the risk. You have guarantees with LTS, here you don't and you can't complain about that. Even non-LTS, they do care anyway. And the mentioned incident with 3.6.0, such things rarely happen, and if they do, the risk is immediately mitigated. After 3.6.0, there was immediate information not to use it and a safe 3.6.1 came out a few days later. Currently, on 2.13 we always use the latest version. But we wait at least one month. During this time, all tooling and libs get updated and if any issues appear, they'll be caught and a corrected release will be published if needed. As I mentioned, for 5 years we've never had even the smallest compatibility problem with Scala. Upgrades of many our products are always smooth.

Actually, in my example with foo: number receiving a string, I'm pretty sure there won't be a runtime exception due to TS type erasure. Your array example could indeed throw because arrays exist in JS runtime. Regarding "gradual ability" - I understand the concept, but I'm focused on building reliable solutions and can't afford bugs and their consequences in production. Issues need to be caught as early as possible. And I totally agree with "it's terrifying in that I do the work to write the types, and they aren't 'real' and things explode". It frightens me too. You mentioned ReScript. I've seen it and it looks much more interesting than TS, but it doesn't have enough popularity. I'm curious if there might be something that provides better type guarantees than TS, or if it's exactly the same in this regard.

@987Nabil @hmemcpy I really like your approach for some satellite projects. For our core enterprise system, we need to stay more conservative to manage risk.

I totally agree with point a. As for point b, interestingly, at our company we only had issues with Java projects migrations. Moving from 8 to 11 needed lots of attention. The issue also affected libraries, because generally speaking, there's this whole thing with the Java 8 to 9 transition. It affected also Scala applications too - wherever we had some "low-level" code written "directly in Java", we needed to fix some "Java code". But at the same time, migrating most (98%) of Scala projects from JVM 8 to 17 went smoothly because Scala acted as kinda anti-corruption layer. Everything just kept working. And we jumped only to 17 not 21 because of AWS. And when AWS offered 21 runtime, we had to check every Java dependency to be sure we can go further and some declare support up to 17 (while I believe it would be ok with 21 but you know we can't risk). So you see, ironically, only Java is blocker for us :) As for Scala itself, we haven't had the smallest compatibility issue in the last 5 years. Though I only know Scala since 2.13. I'll soon share my experience of migrating tons of projects from 2.13.x to 3.3.x. I think it'll be relatively easy and problem-free too. That's because when writing enterprise code, we don't use macros or other overly advanced features. We write functional code, but keep it relatively simple to keep the learning curve low. From this perspective, Scala 3 seems like a slightly improved Scala 2 (we definitely won't use Optional Braces etc.). In this light, where we mostly had problems with Java migrations rather than Scala, those memes about Scala you mention seem like urban legends and negative PR from people who've never actually used it in practice, but just repeat what they've heard. Regarding your situation and the declining interest, and how there was hype but the time wasn't used well and the opportunity was missed, the boat has sailed - yes, it's sad because Scala is a great language and deserves another chance with Scala 3. It's a shame things are the way they are. I can only wish you luck in finding the right Scala job, because we need your energy in this community.

Enterprise Java adoption proceeds slowly despite bi-annual releases. Many companies still stuck with 8 or 11, some might use 17 or 21, rather they're not jumping on 23 for real production. They stick with LTS versions waiting for 25. Ofc it's up to the project leads, but at least with Scala, they have the the same LTS possibility - a key improvement from Scala 2 to 3.

@Krever01 I must admit, this isn't the first time! :D Similarly with the self-updating documentation in Docusaurus, where real code snippets from working sources are included.

Hmm... I'm not certain about the runtime exception part. It would rather not happen. From my understanding, parsing would succeed and code would continue running with incorrect types - whether using `JSON.parse` or `AxiosPromise`. This would happen because TS interfaces only exist at compile time and are erased during compilation to JS. Unlike JVM languages where such type mismatches throw runtime exceptions, in TS we end up with plain JS at runtime, that is blind here. We need then some runtime validation library. And mentioned Zod is indeed a good solution, but it's essentially compensating for TS type erasure by adding runtime checks that Java/Scala/Kotlin get built-in. From ergonomics perspective, using Zod schema feel more noisy and less convenient than clean TS interfaces. But we need to compensate for TS type system limitations - at least Zod allows one to infer types. Using runtime validation seems necessary here for proper type safety. A DX trade-off one have to accept given TS type system limitations.

I was about to bite my tongue here. All this goes against what John is saying. And this case we discuss here shows, that new features make sense, also from an industry perspective, as they can improve the DX of libraries like ZIO and others. This can enhance the ergonomics of the entire Scala ecosystem and significantly improve the overall DX of Scala, keeping in mind industrial adoption. At the same time, we need to remember a crucial point. Libraries still have to use 3.3.x LTS, not 3.6.2 or newer from the "next preview" line, and nobody's talking about aggressive evolution here. Just like in Java, new features are gradually sprouting up, delivering new experimental/preview options in subsequent releases. These things John writes are taken out of context and presented as if there's some serious problem where new releases break tools or libraries, but that's not the case. It allows them to prepare for the next LTS release, because for now, enterprises will continue using Scala 3.3.x LTS anyway.

A practical question about TS type safety. Let's say we have some DTO. The interface has defined types with an optional field `foo` declared as `number`. When an API responds and the JSON contains a string instead of a number for `foo` after deserialization - what happens? Does the program crash or continue running with the wrong type? Might be a silly question, but just curious to see what actually happens in TS in such a scenario?

@adamhearn_ @fbrasisil Hey, directly for enterprise named tuples (wish they are not experimental), for-comprehension improvements, for sure. Via libraries, I think, clause interleaving for the path-dependent API creators.

John, we've met in person and I've always respected your work. But labeling practitioners as "fanboys you love" while dismissing their experiences feels off. I'm an industry professional with decades of programming across different languages. My journey with Scala spans 5 years and continues to be overwhelmingly positive, bringing fresh perspectives to my craft. This isn't fanboyism - it's professional appreciation. And should I work with Kotlin or Rust in the future, I'll approach them with the same enthusiastic professionalism. That's what we do as engineers - we adapt and grow without blind loyalty to any single tool.

@jdegoes Java and Scala both offer preview features shaping their futures. Building industrial solutions, avoid experimental features. Wait for official acceptance, even if it takes years. Scala 3's LTS provides the stability. We do well. Insights from years of industrial experience 🤷‍♂️