Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Origins of Scala (2009)

artima.com

Post reply on HN
Print view View original

81–90 of 97 posts

Re: The Origins of Scala (2009)

#81

Post by pjmlp »

Rochus wrote: post #77
pjmlp wrote: post #74

Earlier quoted context omitted.

It is irritating that apparently C is fine having endless compiler extensions without which ISO C is equally unusable to implement an operating system[0], a sign of greatness, while the same argument is used to point out as design flaws when it isn't C we are talking about. [0] - Unless helped by an external assembler, just like on the UNIX rewrite, when K&R C was initially created.

I'm not advocating for C (I wouldn't implement an Oberon/Pascal/Modula inspired C replacement otherwise). C was mostly adopted by industry because it came with Unix and had to be used by the many Unix-based workstation vendors to adapt and extend the OS for their specific need/brand. That a significant OS can be written in C without extensions is demonstrated by the many Unix versions themselves. There is always a re…

Sure, if we ignore the Assembly buddy code used alongside C.

IBM's OS/400 made use of Modula-2 for some parts, for example.

Back to Niklaus Wirth, as mentioned initially, I think his ideas were great, until he went into minimalism, the first Oberon edition was the turning point, that other researchers luckily improved upon.

Ironically to his point of view, some of them, like Hanspeter Mössenböck, changed his focus into Java and .NET, and has contributions to MaximeVM and GraalVM, via his students thesis.

Re: The Origins of Scala (2009)

#82

Post by Rochus »

pjmlp wrote: post #81
Rochus wrote: post #77

Earlier quoted context omitted.

I'm not advocating for C (I wouldn't implement an Oberon/Pascal/Modula inspired C replacement otherwise). C was mostly adopted by industry because it came with Unix and had to be used by the many Unix-based workstation vendors to adapt and extend the OS for their specific need/brand. That a significant OS can be written in C without extensions is demonstrated by the many Unix versions themselves. There is always a re…

Sure, if we ignore the Assembly buddy code used alongside C. IBM's OS/400 made use of Modula-2 for some parts, for example. Back to Niklaus Wirth, as mentioned initially, I think his ideas were great, until he went into minimalism, the first Oberon edition was the turning point, that other researchers luckily improved upon. Ironically to his point of view, some of them, like Hanspeter Mössenböck, changed his focus in…

I'm not sure what you're getting at with this recurring assembler argument. The Oberon system and also AOS/Bluebottle are full of inline assembler and SYSTEM tricks with pointer arithmetic, etc.; the Lisa OS is also full of assembler. Even Wirth himself wrote parts of the Ceres system in assembler.

Re: The Origins of Scala (2009)

#83

Post by pjmlp »

Rochus wrote: post #82
pjmlp wrote: post #81

Earlier quoted context omitted.

Sure, if we ignore the Assembly buddy code used alongside C. IBM's OS/400 made use of Modula-2 for some parts, for example. Back to Niklaus Wirth, as mentioned initially, I think his ideas were great, until he went into minimalism, the first Oberon edition was the turning point, that other researchers luckily improved upon. Ironically to his point of view, some of them, like Hanspeter Mössenböck, changed his focus in…

I'm not sure what you're getting at with this recurring assembler argument. The Oberon system and also AOS/Bluebottle are full of inline assembler and SYSTEM tricks with pointer arithmetic, etc.; the Lisa OS is also full of assembler. Even Wirth himself wrote parts of the Ceres system in assembler.

Indeed they are, however when it is C, it is an advantage, gladly ignored that ISO C on its own requires an external Assembly tool to do its job, when it is something else, it is thrown around as proof they aren't as good as C for systems programming, the irony of two weighs, two measures.

"You need Assembly to do XYZ that C can do", yeah right.

Re: The Origins of Scala (2009)

#84

Post by pjmlp »

blandflakes wrote: post #59
osdev wrote: post #36

Scala is a great language, and functional programming (not pure functional) made me a much better programmer. And functional error handling is a fantastic way to model success and failure, whether you’re using Either or the newer Result type. I have to both agree and disagree with some of the commenters here regarding why scala declined in usage. There are several reasons. 1. People just got fed up with the push towa…

> However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected. My employer has decided to abandon Scala, and they proposed Java as the language to head toward. I don't think Java's strides are fast enough to provide modern table stakes. In 2025, the big ones to m…

Depending on the market, C# isn't always an option.

One example out of many, https://www.aicas.com

This isn't like Meadows, this is a real-time VM with AOT compilation and soft-realtime deadlines, there are others.

Or stuff like https://www.azul.com/products/prime/cloud-native-compiler, again there are others offering the same.

Kotlin will always be a second language on the JVM, it isn't what Oracle, IBM, and others think about when designing runtime features, and eventually like all guest languages will face the problem to either exposed the platform features, or have multiple ways, with different semantics, to achive the same.

Virtual threads, versus co-routines, structured concurrency, SIMD/Vector, value class/records,....

Re: The Origins of Scala (2009)

#85

Post by pjmlp »

hocuspocus wrote: post #73
blandflakes wrote: post #60

Earlier quoted context omitted.

Kotlin is pretty nice. I think the build tool in Scala being so esoteric didn't help with adoption; I remember avoiding Scala for a few years because dealing with sbt left a horrible taste in my mouth.

Scala CLI should have happened 5 years before, but honestly sbt has improved a lot, the DX is mostly fine since the 1.0 release and it's maintained plugin compatibility for 8+ years. Gradle is worse on several dimensions, which didn't really hurt Kotlin's adoption, nor seems to fundamentally bother Android developers (ok, they have little choice here).

Gradle is only still around thanks to Android, thankfully I have moved away from Android projects.

No need to read about how Kotlin is going to take over the world, while comparing it to samples written in Java 8, or the whole tooling infrastructure mess that needs to be changed, sorry improved, for each Google I/O, or stable Android Studio releases that crash on first use after upgrade, while "fixing" Gradle DSL changes.

Re: The Origins of Scala (2009)

#86

Post by blandflakes »

hocuspocus wrote: post #79
blandflakes wrote: post #78

Earlier quoted context omitted.

I'm not advocating for Gradle either, but you already pointed out why the build tool being bad is relevant for Scala and not for Kotlin - Android developers have enough other reasons that they're going to use Kotlin, even though Gradle sucks. Scala developers... don't, and so just another straw stacked on a camel's back, so to speak.

I'm not saying it played no role, but I think sbt's negative impact is overblown. Maven is old and the DX isn't particularly stellar either. User friendly build tools are a relatively recent development in the programming language landscape. Hell, until uv, Python managed to be much worse than anything on the JVM. I work at a company that used to do a lot in Scala, and I've seen the decline first hand. Lack of invest…

I also work at a company that used to do a lot in Scala, and have seen the decline firsthand. Who's anecdata is better?

I think a lot of posters make the mistake of saying "$otherLanguage has it worse." That's irrelevant! If otherLanguage is an incumbent, they can afford to have it worse. I don't think it's debatable that sbt harmed adoption in the first place and continued to represent a barrier to Scala's adoption for years, and it doesn't matter how good maven is or isn't.

The degree to which is certainly always going to be up for debate; as mentioned before, there are many factors, but sbt was not a nonfactor.

Re: The Origins of Scala (2009)

#87

Post by blandflakes »

pjmlp wrote: post #84
blandflakes wrote: post #59

Earlier quoted context omitted.

> However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected. My employer has decided to abandon Scala, and they proposed Java as the language to head toward. I don't think Java's strides are fast enough to provide modern table stakes. In 2025, the big ones to m…

Depending on the market, C# isn't always an option. One example out of many, https://www.aicas.com This isn't like Meadows, this is a real-time VM with AOT compilation and soft-realtime deadlines, there are others. Or stuff like https://www.azul.com/products/prime/cloud-native-compiler , again there are others offering the same. Kotlin will always be a second language on the JVM, it isn't what Oracle, IBM, and others…

It frankly doesn't matter in which markets C# isn't an option - if you're in one of those, well... then obviously don't consider C#. That doesn't somehow indict C# as a language which better makes it possible to write concurrent code. For a very large proportion of the population, you're picking a language and running some services on a cloud provider or machine you control.

The problem I'm citing in Java is not the performance, it's the semantics and having to explain what an InterruptedException is to every generation of programmers, including those who came before me. If you think virtual threads somehow do anything about what's difficult about concurrency on the JVM, we're talking on different wavelengths. Structured Concurrency is the TINIEST of baby steps and doesn't really do anything to change the experience, and it's only just now in preview, in the most recent LTS JVM? Hardly a solution.

It doesn't matter whether the JVM is developed with Kotlin in mind, as long as Kotlin continues to offer a better way to leverage what the JVM does have to offer. It's not some killer argument that Kotlin somehow can't be useful if the host platform isn't specifically developing their roadmap (especially because you can... just write Java, if you need it?).

Scala's demise likewise has nothing to do with whether the JVM is supporting Scala, and any suggestion that Java's language features have eliminated Scala's value proposition are similarly misplaced.

Re: The Origins of Scala (2009)

#88

Post by Rochus »

pjmlp wrote: post #83
Rochus wrote: post #82

Earlier quoted context omitted.

I'm not sure what you're getting at with this recurring assembler argument. The Oberon system and also AOS/Bluebottle are full of inline assembler and SYSTEM tricks with pointer arithmetic, etc.; the Lisa OS is also full of assembler. Even Wirth himself wrote parts of the Ceres system in assembler.

Indeed they are, however when it is C, it is an advantage, gladly ignored that ISO C on its own requires an external Assembly tool to do its job, when it is something else, it is thrown around as proof they aren't as good as C for systems programming, the irony of two weighs, two measures. "You need Assembly to do XYZ that C can do", yeah right.

> when it is something else, it is thrown around as proof they aren't as good as C for systems programming

That's not my position, and not my argument in this thread. My argument was, that Wirth created his own world and never cared about industry requirements, so industry cared for themselves.

But let me address your concerns. C is an ugly language with a silly syntax (e.g. for arrays, or function types), and the preprocessor is a nightmare, and the weak type checking overlooks a lot of errors (but at least we get warnings, and weak types are very useful when I use C as an IR). But the standard version (ANSI) lets me do all things I need for system development; I don't use inline assembler.

So let's look at Modula-2 (since you seem to see it as Wirth's response to industry needs). First, we have to differ between Wirth's Modula-2, and ISO Modula-2, which is a completely different language (more industry friendly, containing things Wirth was strictly against, and he even refused to participate). So let's stick with Wirth's Modula-2. The first thing that annoys me is the requirement of the original 1982 specification to capitalize all keywords. The second thing is the removal of any type checking for all operations essential for low-level system programming (a pattern Wirth continued in Oberon). ADDRESS is declared as POINTER TO WORD, and the specification doesn't define whether pointer arithmetics has byte or WORD resolution. Type casting is very limited (i.e. restricted to SYSTEM.TRANSFER or variant records without tag, but not in expressions). There is no conditional compilation and only limited compile-time evaluation. There is no explicit "extern" declaration; the use of definition without implementation modules is inofficial and compiler dependent. Some of these issues were "fixed" in ISO Modula. But if I compare Modula-2 e.g. with Ada, which is indeed a true system language explicitly designed for critical industry needs, even ISO Modula is still very limited.

Re: The Origins of Scala (2009)

#89

Post by blandflakes »

palata wrote: post #80
blandflakes wrote: post #58

Earlier quoted context omitted.

It competes in some ways and not in others. It does a pretty good job of providing similar benefits as many Scala ecosystems, but providing approachability over purity. Kotlin becoming The Official Android Language helps it quite a bit, though the future gets interesting if Google successfully abandons the JVM entirely to rid themselves of Oracle. I'm skeptical that Kotlin targeting multiple runtimes is a winning pro…

> I'm skeptical that Kotlin targeting multiple runtimes is a winning proposition Kotlin multiplatform being adopted by Google for huge projects like Google workspace makes it sound like it may actually be a winning proposition, if you ask me. Kotlin is replacing the more-than-a-decade old, battle tested, Java-to-ObjC translation at Google. I find that very impressive. > also Rust is probably the better choice than Sc…

> Kotlin multiplatform being adopted by Google for huge projects like Google workspace makes it sound like it may actually be a winning proposition, if you ask me. Kotlin is replacing the more-than-a-decade old, battle tested, Java-to-ObjC translation at Google. I find that very impressive.

When it comes to Google, I'll believe it when I see it. How's Fucshia?

> For sharing code between e.g. Android and iOS, Kotlin multiplatform seems to become the better solution. If you use Rust, you still have to call it from Swift and you just introduced a 3rd language.

I'm not positing Rust for this or any multiplatform thing, I was suggesting that Scala Native is eclipsed by Rust in its relatively narrow niche (and actually in addition to Rust, graal native-image).

Re: The Origins of Scala (2009)

#90

Post by pjmlp »

blandflakes wrote: post #87
pjmlp wrote: post #84

Earlier quoted context omitted.

Depending on the market, C# isn't always an option. One example out of many, https://www.aicas.com This isn't like Meadows, this is a real-time VM with AOT compilation and soft-realtime deadlines, there are others. Or stuff like https://www.azul.com/products/prime/cloud-native-compiler , again there are others offering the same. Kotlin will always be a second language on the JVM, it isn't what Oracle, IBM, and others…

It frankly doesn't matter in which markets C# isn't an option - if you're in one of those, well... then obviously don't consider C#. That doesn't somehow indict C# as a language which better makes it possible to write concurrent code. For a very large proportion of the population, you're picking a language and running some services on a cloud provider or machine you control. The problem I'm citing in Java is not the…

It matters, because these arguments are always done as if programming languages exist in a vacuum.

Any guest language on the JVM will trip on the InterruptedException just as well, it is called leaky abstractions for a reason.

People reach out to guest languages, as they think they don't have to learn the underlying platform, then they discover the hard reality to master two ecosystems.

Improvements on the platfrom language eventually always drive the guest languages away, because all guest languages either lose their value proposition, or use the platform to bootstrap their own ecosystem.

Turns out when they take second option, they open the door to having libraries that only work in one platform, and the usual #ifdef like complexity.

Kotlin has a better future than Scala, beyond the JVM, because papa Google has ensured it happens, at least as long as they care about Android.

Post reply on HN