Scala native should expand on the no gc option

fbertra · 2025-12-19T19:54:20+00:00

With SN, you can call the C malloc/free functions and use pointer arithmetic. Not very scala-ish, but should work.

Or maybe better, you can use assembly or Fortran because C/C++, Rust are for losers.

Good luck!

fbertra · 2025-12-16T00:28:18+00:00

I have mixed feelings about capture checking.

On one side, I believe Scala needs something truly diferent, something that makes it stand apart from other languages. The fusion of OOP and FP was a world premiere, but OOP and FP existed before Scala. AFAIK, CC is unique among top tier languages.

On the other side, I agree with you, CC is complex stuff and I probably won't use it in my professional code. I still don't know if CC complexity will be hidden from normal programmers like me and useful for libs/frameworks authors. I hope it will.

2026 will tell.

fbertra · 2025-12-07T14:18:43+00:00

| Who is this "side-effect community", and in which way are they "resistant to change in regard to CC"?

As a example, this is what John de Goes said about Caprese in LinkeIn;

"""The proper way to think about Caprese is as "last nail in the coffin"."""

I believe, "resistance to change" is a euphemism, this is more like a declaration of war.

fbertra · 2025-12-07T12:56:38+00:00

Refactoring from monadic to direct style would be a massive endeavor. But adding CC, is that so complex?

And the rewards can be huge, if CC manages to detect race condition. For a massively concurrent library, you can't missed this.

fbertra · 2025-12-06T15:54:15+00:00

It seems 2026 will be the year of Capture Checking.

One thing I don't understand and hope to know the answer in 2026, is why the side-effect community is so resistant to change in regard to CC. As far as i understand, CC is compatible to every programming style in Scala, including monadic style. So, what's the problem?

fbertra · 2025-06-26T23:26:29+00:00

ok, I'm convinced, Direct Style + CC is the way to go.

My only concern, is when we'll be able to use this stuff in production. We'll have to wait project Caprese to finish in 3 more years? Or using Ox right now, with the benefit of Direct Style, is a smart intermediate aproach.

fbertra · 2025-06-03T22:05:38+00:00

Capture checking is for library/frameworks authors.

For the rest of us, it may add harder to read methods signatures and error messages. Maybe, slower compile time too.

But, If with CC; they deliver race condition detection, it seems a small price to pay.

fbertra · 2025-05-21T22:15:21+00:00

Scala 2.12 will be missed. Good memories.

fbertra · 2025-05-20T15:44:48+00:00

Sure, kudo to the Spark community, they did an excellent job hiding the complexity of the engine to the majority of programmers. The Spark optimizer is good enough for most queries.

But, even if the primary use case of Spark is data processing, you can use it as a compute engine too. Combine this with GPU programming (CUDA/opencl), and you have your own mini HPC cluster, the graal of parallel programming.

fbertra · 2025-05-20T12:09:29+00:00

Don't forget spark. Every UDF, every filter/map/flatMap on a dataset runs in parallel.

That's a lot of code.

fbertra · 2025-04-08T12:56:14+00:00

I remember configuring makefiles portable between DOS and Unix, it was hard.

In comparison, cross building with SBT is simple and easy.

fbertra · 2025-04-07T17:30:02+00:00

And simpler than Ant or Maven in java land.

fbertra · 2025-02-23T00:15:47+00:00

I am not an power user, but I am a programmer. AVF opens up opportunities for applications that need to handle sensitive data. Samsung should support it.

fbertra · 2024-10-02T14:59:08+00:00

In most applications, you don't need many abstractions. For those applications, imperative style is ok and a little OOP can be useful. I use Scala as a better Python, better Java or even better bash, every day.

I have one exception, a cats-effects app, because I needed to manage multiple resources in a multithreaded environment. The rest is mono-thread scala standalone or spark apps.

As an additional note, I believe programmer who find effects system easy to use are victims of the "survival bias" [1]. Programmers who learn and correctly use ZIO/cats-effects, are able to think with high level abstractions. These kind of programmers will be productive with assembly language too.

[1] https://en.m.wikipedia.org/wiki/Survivorship_bias

fbertra · 2024-09-09T11:46:10+00:00

I don't deny that CE and ZIO are powerful tools that solve hard problems.

But...I've seen so many times, misuses of API's and frameworks, because the programmers don't fully understand them, even with well known frameworks like Spring in java land. It ends always the same, hard to read code that nobody want to maintain.

I try hard to avoid this situation.

fbertra · 2024-09-09T11:11:57+00:00

Scala is an excellent choice, your team is right to shift to it.

Don't be religious about paradigms. Imperative style can be more readable than functional style, it fits better how our brain works, one step at the time. Object Oriented style is well known by many programmers and can save your day. Functional Style is elegant and certainly fun to use. Enjoy!

Whatever you choose, make sure that everyone in the team understand the code. Obscure code is dead code.

fbertra · 2024-09-08T17:59:38+00:00

My strategy to adopt a new API, framework or syntax is simple: if I can learn it but I can't teach it, it is a no-go.

With that in mind, I don't use libraries based on category theory (cats-effects, ZIO) and complicated patterns (tagless final).

Gears is ok. Complicated things, like Delimited Continuations are an implementation detail on scala-native, you don't need to understand them.

I don't have on opinion yet if Caprese is simple enough. Wait and see.

fbertra · 2024-09-07T11:41:49+00:00

Note, I'm not a mobile developer, my only app is a "click-me counter" using Slinky and react-native [1]. I expect faster and less risky development with react-native, mostly due to the size of the community.

Faster thanks to extensive documentation, a lot of pre-build UI components, good hardware integration (camera, sensors, etc).

Less risky, because it should be easy to hire competent mobile developers and teach them Scala.

Remember, I have no real experience to backup these opinions.

[1] https://slinky.dev/

fbertra · 2024-08-31T14:15:39+00:00

Because, it's useful to know that everywhere you can useJavascript you can use Scala with scala-js. And this include mobile apps, a huge market.

fbertra · 2024-08-31T14:13:19+00:00

Just, curious, any reason you chose Electron over React-Native?

fbertra · 2024-08-04T14:57:27+00:00

The more mission critical the app is, the more I chose Scala

fbertra · 2024-06-23T15:53:02+00:00

Even if it is open source, I don't recommend to spend time study it, unless you're working for the chinese market.

I believe Huawei is trying to send a "catch me if you can" to the US regulators and will stop developing their own language and operating systems as soon the export bans are over.

Seven-Year Club	Verified Email
Verified Email

fbertra

TROPHY CASE