Lisette — Rust syntax, Go runtime
67 points by telemachus
67 points by telemachus
The exact variation I didn't want.
what's your complaint? say more
Rust's syntax looks horrendous. The runtime is the good thing about Rust. Go's existing syntax is fine, the problem is that the language lacks a lot of features.
Different strokes I guess! I quite like Rust's syntax in contrast to Go. I've really come to appreciate languages with clear delimiters and punctuation.
As a rust programmer, I spent some time really digging into writing some go the other day. It's pretty damn ugly. That's my subjective opinion, but objectively the exact same rust code ran about 30% fewer lines of code, which means go is introducing 50% extra unnecessary noise. That's huge.
So weird. Go's design is awful in a lot of ways but the good thing about it is the runtime.
Yeah, we like Go because of its GC, exceptionally well tuned green threads, fast compile times, extensive and focused library. But not the language, sorry. It's getting better, though, but Google now seem to hate change, so…
The runtime and the tooling and the performance and the standard library are all pretty good. The error handling is one of the least bad as well. It has some warts, but it gets better every release. If I find a more productive language, I’d happily switch but for now Go is an order of magnitude better than everything else as far as general purpose development goes. If you need to trade everything for performance or correctness, it’s not the right tool for the job, however.
Horrendously good! I like it, it's nice and clear about what exactly is happening at every moment. Each to their own.
That's one of the things I find least good about it. With most common code in Rust, I find myself needing to reason through a stack of macros, conversions, operator overloads, and other cleverness.
I apologize, but your claim that Rust commonly involves sifting through a pile of "macros, conversions, operator overloads, and other cleverness" is just... not true. Whatever you're trying to do is either not common, or you're simply lying.
All rust's features are in the syntax. Rust's runtime is minimal (to the point some say that Rust doesn't have a runtime)
Language features are not syntax features. For example, being able to perform a series of operations, each of which could return an error, and immediately return any error that occurs without having to manually plumb it through is really nice, but putting ? at the end of every statement looks awful. do notation would be better.
but putting ? at the end of every statement looks awful. do notation would be better.
I think this is a question of tradeoffs, as with many things. What you gain in fewer ? sprinkled about you lose in specificity, as you no longer have an indication as to which specific statements are falliable. Whether that's a "good" tradeoff or not will probably depend on what you're writing. Bit reminiscent of the "explicit allocation" philosophy, if anything.
I'm guessing they don't want the inherent resource-inefficiency of garbage collection (The whole "It's advised to double the RAM provisioned to leave room for 'floating garbage'" thing.) but they find having to actually do the requisite legwork to memory-safely avoid it annoying.
In other words, the core, commonly identified “hard part” of Rust - ownership and borrowing - is essentially applicable for any attempt to make checking the correctness of an imperative program tractable.
Algebraic data types · Pattern matching • No nil · Hindley-Milner type system
It's much more than just syntax. This is the sober way to write Go.
I looked at this and a little voice said "it's the CoffeeScript of Go!" And to be clear I'm not immediately sure if that's good or bad.
Looks like this one, perhaps a bit further along.
https://github.com/borgo-lang/borgo
If I were to use one of these, I’d like it to also accept lowercase function names.
Looks good on paper, but I suspect it all breaks down as soon as you need to deal with go libraries or e.g. JSON, producing values that you couldn't produce with this nice syntax.
JSON works today: #[json] on a struct generates Go struct tags, with options like omitempty, skip, snake_case, and custom tag names. More on attributes here.
Support for Go third-party packages is not part of this first release, but the tooling to generate bindings for Go packages (which enables imports from the Go stdlib) is already in place here. Extending it to support third-party packages is on the roadmap.
I'm wondering about the logistics of making this integrate with Go at the assembly/object file level rather than at source code level. What if it compiled to Go's assembly rather than to Go source code
I love Rust. So having more Rust but with less Rust in it is just awesome.
Does Lisette also solve data races?
Lisette inherits Go's concurrency model. The test runner on the roadmap will leverage existing Go tooling, including its race detector.
I understand that it's not meant to be "a better version of Go" like TypeScript or CoffeScript are better versions of JavaScript. I guess it's meant as a way to bring Rust's very-well designed parts into another ecosystem that does not need to work with the same compromises and design constraints that Rust has (such as zero-cost abstractions)
So while it sounds weird at first, that idea actually makes a lot of sense. And could potentially be extended to other ecosystems such as JavaScript, JVM, etc.
Looks like a fun project! Might give it a spin :)
As for the comments I find it crazy, that grown men have such strong opinions regarding syntax. I grew out of that phase after about 8-9 years of coding :P