Rust is imperative too, though.
Yes. You have two choices: Interface implemented once, or virtual on all your public members.
I personally think Interface is the sane choice.
Would be nice if the .NET devs let us mock POCO's though...
For whatever reason, C# devs seem incredibly resistant to even just looking at F#.
VS Tooling lacking versus C#/VB, no support for code generators, no support for Roslyn, no support for GUI frameworks, no support for EF tooling, many .NET vendors don't support projects if using F#, community likes to create their own wrappers instead of embracing standard .NET projects, ....
I kinda like the language (its what I want basically) but the operational aspects are what I actually need and want first and foremost.
I think what it comes down to is that the creator/BDFL of Nim has an eclectic set of things that he simply doesn't care about and will never add to the language even though they are basically table stakes nowadays.
It's tooling isn't great though. I think its syntax is a lot nicer than OCaml's for example.
There is this wonderful language that is up and coming called Roc that look promising.
https://www.youtube.com/watch?v=6qzWm_eoUXM
language examples here -> https://www.roc-lang.org/tutorial
Disclaimer: I'm the author of said language :)
How do your references work? Is `&T` a type? Can you store it in a structure, or return it? Can you have a reference to a reference? If you can have a function `f(&T, &T) -> &T`, how do you distinguish whether the reference it returns lives as long as the first or second argument? If references can't be stored in structs, how do you do non-owned iterators, or string slices?
> Is `&T` a type?
Inko's syntax for references is `ref T` for immutable references/borrows, and `mut T` for mutable ones. Unlike Rust, you can't implement methods/traits _only_ for references, instead you can only implement them for the underlying "base" type. So `impl ToString for String { ... }` is valid, but `impl ToString for ref String { ... }` isn't.
> Can you store it in a structure, or return it?
Yes.
> Can you have a reference to a reference?
No, `ref ref T` is "collapsed" into just `ref T`, and the language has no notion of pointers and pointer-pointers.
> If you can have a function `f(&T, &T) -> &T`, how do you distinguish whether the reference it returns lives as long as the first or second argument
Inko doesn't have a borrow checker, so it doesn't. Instead it relies on runtime reference counting to prevent dropping of values that still have references to them. Over time I hope to implement more compile-time analysis to reduce this cost as much as possible, but borrow checking/lifetime analysis like Rust isn't something Inko will have.
Or to put it differently, I want the compiler to catch say 80-90% of the obvious "this ref outlives its pointee" errors without complicated borrow checkers. For the remaining 10-20% the runtime check should suffice.
Not to be snarky (for once) but
- More powerful type system: that goes against the whole implementation culture behind Go and their wider philosophy
- ML-inspired instead of imperative: goes even more counter to the above
I have never tried Go and I will probably never care to try it, but I have never seen a language which manages to both be (1) simple in the Go-sense and (2) look remotely anything like an ML language.
Didn't they implement generics already?
https://go.dev/blog/why-generics
It seems like their implementation has enough power to do this in most cases, although "Option" is not built in.
If there would be something just like Go, but with a bit more powerful typesystem like Rust has (Option<T> instead of `err != nil`, and so on), and a simplified ML-like language instead of an imperative one... that would be my dream.