[rTX5CMRXIfFG]

I'm not sure what you're getting at here but none of the features you mentioned are groundbreaking anymore? At least in Swift:

result/sum types = enums whose cases have associated values

inferred typing = Swift "type inference"

Not object oriented or overly prescriptive with functional programming. = Uh, yes

Those features map to Kotlin too

[madeofpalk]

I don't think you're disagreeing with parent. I also think these features are not groundbreaking and should be considered table stakes for any new/sane language.

[fstarship]

I am aware of 3 “rust inspired scripting” languages that have dynamic types.

Rhai Rune Dyon

Mun is not dynamic, however it does not have string support afaik.

Kotlin and Swift may be better candidates than these scripting languages for my imagined usecase.

Come to think of it, maybe I don’t have a point other then there is so many scripting language’s inspired by rust that is dropping a major convenience feature, that I am surprised is negotiable (inferred typing ).

[zozbot234]

Rust itself has dynamic types via the Any trait and &dyn Any variables. They are not the default of course, but they're available should you really want them. IIRC C# works similarly, only its feature is called Dynamic instead, or something like that.

[skitter]

They're rather different: In Rust types only exist at compile time; dyn Any is a normal trait object, so you can only call the trait's methods. With C#'s dynamic, you can call arbitrary methods and access any fields with type checking of those accesses being delayed until runtime, which works because types exist at runtime too.

Rust's dyn Any corresponds better to C#'s Object; dynamic exists to interface with dynamic languages and is rarely used.

[sanderjd]

Yeah I think Kotlin is quite close to the OP's description. But it is perhaps more focused on object orientation than they would like, and also only runs on the JVM.

But if I were to create a self-contained (that is, non-JVM) "Rust-like but with GC", I think it would look a lot like Kotlin.

[karmakaze]

I haven't tried it but Kotlin/Native targets platforms like iOS, macOS, Linux, Windows, etc. There's also Kotlin/JS for JavaScript, and a WASM target with limitations.

[lolinder]

It's been a few years since I tried Kotlin/Native but even then it was pretty good.

[sanderjd]

Neat. I didn't know that.

[valenterry]

Rather Scala but leaving out a few parts. Kotlin is very very OOP focussed and comes with a lot of baggage from Java.

Rust-like but with GC is already Scala. The reason is that Scala (unlike Kotlin) focusses on immutability, which makes it more similar to Rust. It's actually even easier to use (no borrow checker) but at the cost of performance.

After Rust, I would see F# as the next closest language, quite far before Kotlin.

[sanderjd]

> Rust-like but with GC is already Scala.

Maybe like a third of Scala. But yeah, Scala has a lot of good parts, it's also just a huge surface area. I agree that you could pluck a subset out of Scala and make it this "Rust-like but with GC" language.

But it's nigh-impossible to actually make that "only use this subset" idea work in practice, because it just ends up being a bikeshed.

But you're right that the same can be said of the OO focus of Kotlin.

[valenterry]

I think it absolutely works in practice. You have to pick the right libraries though. I would start with https://github.com/com-lihaoyi which basically follows that style.

> But you're right that the same can be said of the OO focus of Kotlin.

The difference is that Scala focuses on immutability, which makes the experience much closer to Rust than to Java. Whereas Kotlin does it exactly like Java does. Were Kotlin to focus on immutability like Scala does, than I would recommend Kotlin over Scala for what OP asked for.

[Mawr]

A language is a shared way to communicate. If you start picking and choosing the parts of a language you like, you can no longer communicate effectively with the rest of its speakers, er, coders.

That's why C++ is so badly designed, you can do anything in it, so people do and no two C++ codebases are the same. Your codebase at work is written one way, the libraries it uses in another, your personal projects use something else entirely. It's a huge mess where nothing is compatible with each other and the mental load of switching between projects is untenable.

[valenterry]

That's kind of true, but it's not black and white.

For example, look at Golang. The syntax is very plain and it's by design so that everything looks the same.

Then take a look at Lisp. On the surface the syntax looks all the same but in reality, everyone can write their their own macros and people usually do. Then, you can barely understand what's going on if you are new to the codebase - but on the other hand, the flexibility is enormous.

Scala is somewhere in between. When you hire someone for Golang, you don't really need to make anything clear in terms of code style (I believe). In Scala (or Lisp) you should definitely clarify the style that you use. It's actually normal (I've hired pretty big number of Scala developers over my career and I have also rejected job offers due to the style the company uses which doesn't match what I like).

C++ probably is alike, but I don't really any C++ experience.