João D. Costa

It's been a while since I posted anything here, so I think it's better to just leave a pinned tweet. I might still post some important announcements, but if you want to follow me, do so at @jd557@blog.joaocosta.eu (or just blog.joaocosta.eu) where I share all my updates.

@Anh32920995 @jdegoes Indeed, the issue seems to be fixed in 3.6 by github.com/scala/scala3/p… I don't see that widenPrefix method in 3.3.5, so I'll assume that the bug is not present in the LTS series.

@jdegoes Is that issue re-producible? If yes, please post steps. You're using windows? Why do you use 3.5.1 but not 3.3.5 nor 3.6.3? Those Scala people don't have enough money to take care of all the releases.

Scala 3 compiler now crashing on very simple code. 😞 (I'm not new to compiler crashes, of course!).

Published a port of github.com/nayuki/QR-Code… to Scala, cross-compiled to JVM/JS/Native. It's now easier than ever to generate QR codes in Scala. 🙂 Check it out at index.scala-lang.org/jd557/qrgen

@velvetbaldmime How long have you been using westerm? I tried it ~2 months ago, but gave up due to issues with JLine (SBT and scala CLI bugged out) Did you do something special, or does it "just works" now?

The absolute killer feature of WezTerm for me were panes and splits inside SSH – I do not enjoy tmux, even though plenty others do, and wezterm provided that native tiling experience I cherished when connecting to remote machines and my local linux desktop. Then that broke for some reason and I never really recovered from that.

At this point I'm not sure how exactly I should be using new terminals to get excited about GPU rendering or other new things they offer. Here's me scrolling through sourcefiles of my project in neovim with telescope. Ghostty on the left, Wezterm on the right.

@lukasz_bialy A bit off-topic, but: > That's a take I'd like to discuss. I think it would be great to also have this discussion on a proper forum, like users.scala-lang.org. This topic is quite nuanced, but having to reply with a limited char count makes that hard to express 😅.

That's a take I'd like to discuss. Why the hell aren't more people / companies interested in Scala Native?

@kubukoz @lukasz_bialy @hmemcpy I think your Playdate example is a great example of that. You probably won't be able to compile a game with GraalVM to run there. I understand that SN is also still very limited on that aspect and needed a bunch of hacks on top, but it's getting better every day.

@kubukoz @lukasz_bialy @hmemcpy I should have rephrased that: I don't think the goal is to minimize the GC impact, the goal would be to target systems where the running a JVM is not viable. In which case you are probably very memory limited, so you just can't allocate at will and let the GC deal with it later.

@kubukoz @lukasz_bialy @hmemcpy To be fair, I think the main reason people don't use SN is because they can use Scala on the JVM instead. It's hard to predict what would be the differentiating feature that would trigger a switch, with "low-GC" code being one possibility (e.g. for embedded systems).

@lukasz_bialy @hmemcpy is that something people are visibly missing from SN though? Sure it's cool, but I don't think GC is the reason people don't use SN

@ghostdogpr @lukasz_bialy Arguably you can do the same things with GraalVM, but I think in the long run Scala Native has more potential.

@ghostdogpr @lukasz_bialy For me, at its current state, the main use cases are: 1. Small tools/scripts with instant startup 2. Being able to generate Windows binaries While Java claims jars to be easy to distribute, sometimes it's hard to beat an .exe in a USB drive.

@lukasz_bialy This is not just dependent on Native, though. Projects like the Scala Toolkit and Scala CLI, along with libraries like Cue4s are essential on making Scala a viable language for "native scripts".

@lukasz_bialy I can't speak for the "more people", but regarding companies, I don't think it's yet stable enough to be used in production. I do use some scala-cli scripts compiled with SN at work, and I imagine that will be the "gateway drug" for most companies.

@velvetbaldmime Nevermind, I skimmed the inline version. I thought you were doing compile time unrolling, which would be kind of crazy, but funny 😅

@JD557 Hm but that's exactly what my optimised version is doing (the one with inline which turns it into a while loop) - that's sort of the point, for loops are bad in a tight.. Loop :) We're getting the same results.

Correction: I've messed up the loop boundaries (of course). Thanks to @JD557 for pointing it out. This puts the `for ... do` version into the "embarassing" range, but keeps the inline loop one in the same place. These benchmarks are almost meaningless, keep that in mind.

@velvetbaldmime I haven't checked the bytecode, but I wouldn't be surprised if this made it much easier for LLVM to apply autovectorization.

@velvetbaldmime ``` def hello(u: Int) = val r = scala.util.Random.nextInt(10_000) val a = Array.ofDim[Int](10_000) var i = 0 while (i < 10_000) var j = 0 while (j < 100_000) a(i) = a(i) + u j += 1 a(i) += r i = i + 1 println(a(r)) ```

@velvetbaldmime FYI, I think you messed up on the inner loop... based on benjdd.com/loops2/, I think the inner loop is supposed to go up to 100_000.

Couldn't stay away, of course. Here's the same benchmark using two different styles of loops with dramatic difference. I get silly numbers on my Apple M2 Pro, and Python takes like 2 minutes, so not sure I can trust anything... Repo: github.com/keynmol/1-bill…

@velvetbaldmime @lukasz_bialy > I bought twitter premium just post this. Think what you will about what it says about my business savviness.. You should have posted on twotm8 and just shared the link here On a more serious note, 💯 post.

I can hardly say because I don't have entrepreneurial spirit at all, which is a shame. But one thing I notice is that a lot of tools and libraries in our ecosystem are designed to be good for programmers, not makers. Things are composable and predictable, which is fantastic and genuinely an improvement over a lot of ecosystems I worked in. But to get things to an app-building state you must often know the correct plugins (sometimes lots of them!), folder arrangements, and the invocations required to do the most basic things. Without sbt-assembly/sbt-native-packager/sbt-native-image, sbt package produces something that pretty much no one ever needs – a library JAR, not runnable without a classpath. Part of this mess is that JVM ecosystem itself is somewhat hostile to entrepreneurship, instead focusing on a decent experience for library authors and service builders. You don't have Scala.js without plugins, you don't get formatting without plugins, you barely get rewrites and linters without plugins. Very composable, very well, very great for maintainers. And yet entirely reliant on users to know what plugins they need and how to configure them – to be a programmer within the ecosystem. Scala-CLI gets you closer, where scala-cli package is actually meaningful, but if you dare to have frontend AND backend, you lose IDE support and you have to resort to a bunch of tricks that, again, you have to know about, and you have to write code to make them work. I've been trying to solve this by producing lots of templates, but it's not going to be solved this way. All that said, it's not just a tooling problem – the biggest app-building ecosystems (JS, PHP, Python, etc.) are also some of the biggest ecosystems in tech in general – leading to greater probability of formation of a entrepreneurial core, which builds/modifies tooling and drives introduction of language features that make solo app building better. And additionally, Scala’s benefit is being just better in the long run – solo app building requires break neck speed because you have to earnestly attempt to fill a market niche before you learn what customers you can get and what they want. Scala (even used in its roughest, most unsafe form) is still very restrictive and slows down this break neck pace – for good reason, as it prevents you from introducing tech debt early on, as the cost of fixing it becomes greater with time. Problem is, at the very early stages the cost of introducing this delayed tech debt is acceptable to most, so you are happier choosing a language that doesn’t have your back as much as Scala does. And as we know, rewrites almost never happen (statistically) so you end up with wonky apps written in whatever language allowed the author to explore the space the quickest at the time. And again, statistically, the apps are likelier to come out of the largest ecosystems with literal millions of developers. The batteries included initiatives driven by things like scala-cli and toolkit are a good step in the right direction. The —power flag is an unnecessary distraction, one that prioritises maintainers’ needs over users’ convenience, forgoing the fact that without users there’d be no need to maintain the very thing you’re trying to protect. Increasing general Scala adoption in various areas (CLI tools, native libraries, frontend, OS scripting, etc.) is a slow but sure way to demonstrate to existing Scala developers that it's not a one trick pony. When I introduced ammonite at work many years ago, 90% of our developers (senior and junior alike) haven't even heard of it. All they knew was Akka HTTP, Spark, and Cats Effect, because it helped them build HTTP services and data pipelines, the niches Scala was confined to. Personally I’ve identified the rough shape of a stack I would use if I were to build anything useful for once: Scala CLI, NGINX, Vite, TailwindCSS, Laminar, and Smithy4s – the latter being my guilty pleasure, a bet that the app will outgrow its original “2 HTTP endpoints and a basic frontend” ambition. github.com/indoorvivants/…. But IDE support is a problem – I can’t imagine an ambitious individual, far removed from Scala ecosystem, battling metals and workspaces trying to get frontend and backend to be editable within same window. --- I bought twitter premium just post this. Think what you will about what it says about my business savviness..

you can just build things apparently

Just released Minart 0.6.2 with experimental support for vector graphics and faster convolutions. github.com/JD557/minart/r… Here's a quick demo of Scala-kun (github.com/windymelt/scal…) made with vector shapes and motion blur: gist.github.com/JD557/4855c0ea…

@Krever01 Not to put down your achievement, but I was a bit surprised that your name is Wojciech 😯 Voytek=Wojciech sounds a bit obvious in hindsight. Since I couldn't put those two together, I think I'll skip the IQ test 😅

Saw some people doing IQ tests. I don't have time to do it right now but I can't miss an opportunity to brag. C'mon, the test cost me something like 20€. You know how much stuff one can buy for 20€ as a student in Poland?!

@kubukoz @kkondzielski As an extra, here's some screenshots to show what I mean. Firefox on Android vs Chrome on Android (icons and visiting an external page).

@kubukoz @kkondzielski And, at the end of the day, you want to make sure your app keeps working even for those using some weird default browser that came with their budget phone. But maybe things will improve in the future, I do like the idea of PWAs instead of wrapping stuff in Electron. 6/6

Wow, are we getting back into the android land after abandoning it for so long? #makeScalaOnAndroiodThingAgain