* No user macros at all. Six fixed format! / println!-family macros expand at parse time. - Meta programming is incredibly important in rust.
* (unsafe is) Forbidden at the language level. No unsafe keyword in Gossamer source. std is safe-Rust too. - No low level programming then.
* No move semantics. Non-trivial values are heap-allocated, reference-counted, and shared by reference; primitives are copied the same as Rust. - Again, no low level programming.
Calling this rust flavored (or even a systems programming language) seems a bit bold.
It has a Rust-like syntax, enums, matching, traits, etc etc. Yes, it also loses a lot of special characteristics of Rust, but it has to be different somewhere. Moreover a lot of people like Rust as a high level language, i.e. ignoring the lower level capabilities and lifetimes, and this seems to be a direct response to that feeling.
Google called Go a "systems language". I agree its not the right term, but people do use it to describe a language used in infrastructure software like Docker or Kubernetes.
To me it makes a lot of sense as a starting point. The world does not need another Rust since we have a perfectly good one. People who like Rust's type system but don't care to think about ownership when writing application code, and who appreciate the language asyncing all the things invisibly have plenty to like here.
I do agree though any serious language MUST have an FFI capability, and macros or at least some form metaprogramming of seem like tablestakes. Green threads are not impressive if they are not preemptive. But its not describing itself as finished, its 0.19. Rust looked completely different at that stage in its development - I think it still had green threads itself at that point.
The syntax looks like rust, but esp w/the memory management model (reference counting), it’s going to have more overhead than rust when it’s running, more like Swift or at worse, Python.
If you are interested in Gossamer, you may also be interested in Lis, which is Rust flavored and compiles to go: https://github.com/ivov/lisette
From their readme:
Safe and expressive:
- Hindley-Milner type system
- Algebraic data types, pattern matching
- Expression-oriented, immutable by default
- Rust-like syntax plus |> operator and try blocks
- Go-style interfaces, channels, goroutines
Quietly practical:
- Interop with Go ecosystem (WIP)
- Linter, formatter, 250+ diagnostics
- Fast incremental compiler, readable Go
- LSP for VSCode, Neovim, Zed, Helix, GoLand
I would also like to toss my project into the ring, which also allows mixing most real-world Rust & Go packages together, on runtime & syntax compatible level. https://github.com/deepai-org/omnivm
Pardon the sloppy readme - it actually does work :)
Three things stick out to me on https://gossamer-lang.org/docs/migration/rust/
* No user macros at all. Six fixed format! / println!-family macros expand at parse time. - Meta programming is incredibly important in rust.
* (unsafe is) Forbidden at the language level. No unsafe keyword in Gossamer source. std is safe-Rust too. - No low level programming then.
* No move semantics. Non-trivial values are heap-allocated, reference-counted, and shared by reference; primitives are copied the same as Rust. - Again, no low level programming.
Calling this rust flavored (or even a systems programming language) seems a bit bold.
It has a Rust-like syntax, enums, matching, traits, etc etc. Yes, it also loses a lot of special characteristics of Rust, but it has to be different somewhere. Moreover a lot of people like Rust as a high level language, i.e. ignoring the lower level capabilities and lifetimes, and this seems to be a direct response to that feeling.
Google called Go a "systems language". I agree its not the right term, but people do use it to describe a language used in infrastructure software like Docker or Kubernetes.
To me it makes a lot of sense as a starting point. The world does not need another Rust since we have a perfectly good one. People who like Rust's type system but don't care to think about ownership when writing application code, and who appreciate the language asyncing all the things invisibly have plenty to like here.
I do agree though any serious language MUST have an FFI capability, and macros or at least some form metaprogramming of seem like tablestakes. Green threads are not impressive if they are not preemptive. But its not describing itself as finished, its 0.19. Rust looked completely different at that stage in its development - I think it still had green threads itself at that point.
does rust have FFI, then? (aka stable ABI)
Totally agree, misleading.
The syntax looks like rust, but esp w/the memory management model (reference counting), it’s going to have more overhead than rust when it’s running, more like Swift or at worse, Python.
Originally I replied here that I thought you were both missing the point (but I was wrong).
I wrote: It has a garbage collector and goroutines, so clearly it is not trying to be a systems programming language.
Then ... I saw that it does indeed pitch itself as a systems programming language. So, I guess you both are right.
If Gossamer were to drop that claim, then I'd say it looks impressive to me. I have often wanted this particular mix of language features.
This language reminds me of Borgo https://borgo-lang.github.io
All three points are erased by its ability to call Rust functions…
It’s not a bad approach, in that for most general programming one doesn’t need those things. Granted, macros can be convenient.
Any language with FFI support can call rust functions.
If you are interested in Gossamer, you may also be interested in Lis, which is Rust flavored and compiles to go: https://github.com/ivov/lisette
From their readme:
I would also like to toss my project into the ring, which also allows mixing most real-world Rust & Go packages together, on runtime & syntax compatible level. https://github.com/deepai-org/omnivm
Pardon the sloppy readme - it actually does work :)
You were so preoccupied with whether or not you could, you didn't stop to think if you should.