4 ms·

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 c

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

sanderjd 2y ago
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 2y ago
  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 2y ago
    It's been a few years since I tried Kotlin/Native but even then it was pretty good.
  - sanderjd 2y ago
    Neat. I didn't know that.
- valenterry 2y ago
  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 2y ago
    > 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 2y ago
      I think it absolutely works in practice. You have to pick the right libraries though. I would start with https://github.com/com-lihaoyi 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 2y ago
        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 2y ago
        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.
fstarship 2y ago
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 2y ago
  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 2y ago
    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.
madeofpalk 2y ago
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.

sanderjd 2y ago

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 2y ago
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 2y ago
  It's been a few years since I tried Kotlin/Native but even then it was pretty good.
- sanderjd 2y ago
  Neat. I didn't know that.
valenterry 2y ago
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 2y ago
  > 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 2y ago
    I think it absolutely works in practice. You have to pick the right libraries though. I would start with https://github.com/com-lihaoyi 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 2y ago
      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 2y ago
        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.

fstarship 2y ago

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 2y ago
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 2y ago
  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.

madeofpalk 2y ago

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.