Felix 🇺🇦🚴♂️🇪🇺Lisette - A little language inspired by Rust that compiles to Go
It looks nice, yes—this could be a better version of Go. It has elements of Rust and Vlang. A very interesting compromise.
Psyhackological@leobm why not go all-in into Rust?
@psyhackological I only partially understand the
hype surrounding Rust. It’s certainly a nice language, with good error handling and so on. But it’s also very complex; Go is much simpler and perfectly adequate for 90% of the requirements one has for a programming language. I’m only a limited fan of Rust; if I needed full control over memory, I’d probably go with #ziglang instead.
hype surrounding Rust. It’s certainly a nice language, with good error handling and so on. But it’s also very complex; Go is much simpler and perfectly adequate for 90% of the requirements one has for a programming language. I’m only a limited fan of Rust; if I needed full control over memory, I’d probably go with #ziglang instead.
@psyhackological With Rust, I still feel like I’m spending more time wrestling with the type system than actually coding and getting things done. I often have similar feelings with Haskell, and sometimes with Scala too. Maybe I’m just not smart enough for Rust 🤷🏻♂️
@leobm type system is actually Rust's super power and also in Go it shouldn't be neglected (or Haskell / Scalla). 90% of problems (and bugs) in my daily job comes from improper type value and missed validation. The only thing I can complain (and Rust Foundation team are aware of) are lifetimes. There is no struggle in Go as it has built in GC in each binary. Rust must be "tip top" however it's possible to create memory leak.
@psyhackological I’ve come to realize that a type system isn't always the silver bullet it’s made out to be. At the end of the day, you're almost always starting with strings or binary data. You can define beautiful types and structures, but they often fail to catch real-world errors, which then just pop up at runtime anyway. In my experience, most errors occur because you have incorrect/unexpected input data.
For me, types are mostly useful for large-scale refactoring or IDE code completion.
@psyhackological Otherwise, I’ve actually found static typing to be a bit of a hindrance lately, especially when dealing with highly dynamic data. Dynamic languages are just more flexible. For instance, #Erlang’s pattern matching helps me way more than a formal type system ever could. Or look at #Clojure with tools like Malli or core.spec—combined with REPL-driven development where you test functions live
@psyhackological in the editor—it’s just a different level of flow. I’m torn: I appreciate the theory of static types, but I keep being reminded of how elegant and flexible dynamic languages can be.
@psyhackological I actually find e.g. #Rakulang's approach quite interesting too. Gradual dynamic typing. For example, using `subset`
```raku
subset Age of Int where 0..120;
my Age $my-age = 25; # OK
my Age $old-age = 150; # Error: Type check failed
subset Username of Str where /^ \w ** 3..15 $/;
my Username $user = “r2d2_detective”; # OK
my Username $bad = “yo”; # Error
```
@psyhackological
```raku
subset
NonEmptyList of List where *.elems > 0;
sub process-data(NonEmptyList $data) {
say “process ” ~ $data.elems ~ “...”;
}
process-data([1, 2, 3]); # Okay
process-data([]);
```
or things like multi-dispatch e.g.:
```raku
proto fib (Int $n --> Int) {*}
multi fib (0) { 0 }
multi fib (1) { 1 }
multi fib ($n) { fib($n - 1) + fib($n - 2) }
```
@psyhackological I just want to say that I very rarely get a TypeError because I pass a string into a place where a number or something similar is expected. Simply because the
context often makes it clear what’s expected. I think that’s why type systems are overrated. Type systems are great for defining a specific intention or structure. But there are other ways to do that, too.
context often makes it clear what’s expected. I think that’s why type systems are overrated. Type systems are great for defining a specific intention or structure. But there are other ways to do that, too.