Live data from Hacker News

Lisette a little language inspired by Rust that compiles to Go

lisette.run

71–80 of 168 posts

Re: Lisette a little language inspired by Rust that compiles to Go

#71

I've chatted a bit with the author, but not actually tried the language. It looks very interesting, and a clear improvement. I'm not particularly quiet about not liking Go[1]. I do think there may be a limit to how far it can be improved, though. Like typed nil means that a variable of an interface type (say coming from pure Go code) should enter Lisette as Option >. Sure, one can match on Some(Some(h)) to not requir…

From your blog entry:

> Go was not satisfied with one billion dollar mistake, so they decided to have two flavors of NULL

Thanks for raising this kind of things in such a comprehensible way.

Now what I don't understand is that TypeScript, even if it was something to make JavaScript more bearable, didn't fix this! TS is even worse in this regard. And yet no one seems to care in the NodeJS ecosystem.

That's why I created my own Option type package in NPM in case it's useful for anyone: https://www.npmjs.com/package/fp-sdk

Re: Lisette a little language inspired by Rust that compiles to Go

#72
post #57

This is great news for those of us looking for baby names. So far my list includes: Pascal, Ada, Dylan, Crystal, Lisa, Julia, Ruby, and now Lisette.

Horrible news for me, I quite like the idea and syntax, but it also reminds me of my wife which I am currently divorcing.

Not sure I'd like the constant reminder.

Re: Lisette a little language inspired by Rust that compiles to Go

#74
post #66

I've chatted a bit with the author, but not actually tried the language. It looks very interesting, and a clear improvement. I'm not particularly quiet about not liking Go[1]. I do think there may be a limit to how far it can be improved, though. Like typed nil means that a variable of an interface type (say coming from pure Go code) should enter Lisette as Option >. Sure, one can match on Some(Some(h)) to not requir…

> Basically, why try to make Go more like Rust when Rust is right there? The avg developer moves a lot faster in a GC language. I recently tried making a chatbot in both Rust and Python, and even with some experience in Rust I was much faster in Python. Go is also great for making quick lil CLI things like this https://github.com/sa-/wordle-tui

No doubt a chatbot would be built faster if using a less strict language. It wasn't until I started working on larger Python codebases (written by good programmers) that I went "oh no, now I see how this is not an appropriate language".

Similar to how even smaller problems are better suited for just writing a bash script.

When you can have the whole program basically in your head, you don't need the guardrails that prevent problems. Similar to how it's easy to keep track of object ownership with pointers in a small and simple C program. There's no fixed size after which you can no longer say "there are no dangling pointers in this C program". (but it's probably smaller than the size where Python becomes a problem)

My experience writing TUI in Go and Rust has been much better in Rust. Though to be fair, the Go TUI libraries may have improved a lot by now, since my Go TUI experience is older than me playing with Rust's ratatui.

Re: Lisette a little language inspired by Rust that compiles to Go

#75
post #7

There are several languages that compile to Go, trying to be a better a Go. Off the top of my head: XGo ( https://github.com/goplus ), Borgo ( https://github.com/borgo-lang/borgo ), Soppo ( https://github.com/halcyonnouveau/soppo )...

Both Borgo and now Lisette seem to act as though (T, error) returns are equivalent to a Result sum type, but this is not semantically valid in all cases. The io.Reader interface's Read method, for example, specifies not only that (n!=0, io.EOF) is a valid return pattern, but moreover that it is not even an error condition, just a terminal condition. If you treat the two return values as mutually exclusive, you either can't see that you're supposed to stop reading, or you can't see that some number of valid bytes were placed into the buffer. This is probably well known enough to be handled specifically, but other libraries have been known to make creative use of the non-exclusivity in multiple return values too.

Re: Lisette a little language inspired by Rust that compiles to Go

#77
post #71

I've chatted a bit with the author, but not actually tried the language. It looks very interesting, and a clear improvement. I'm not particularly quiet about not liking Go[1]. I do think there may be a limit to how far it can be improved, though. Like typed nil means that a variable of an interface type (say coming from pure Go code) should enter Lisette as Option >. Sure, one can match on Some(Some(h)) to not requir…

From your blog entry: > Go was not satisfied with one billion dollar mistake, so they decided to have two flavors of NULL Thanks for raising this kind of things in such a comprehensible way. Now what I don't understand is that TypeScript, even if it was something to make JavaScript more bearable, didn't fix this! TS is even worse in this regard. And yet no one seems to care in the NodeJS ecosystem. That's why I creat…

How would TS fix null in JS without violating its core principles of adhering to EcmaScript standards and being a superset of JS?

Re: Lisette a little language inspired by Rust that compiles to Go

#78
post #71

I've chatted a bit with the author, but not actually tried the language. It looks very interesting, and a clear improvement. I'm not particularly quiet about not liking Go[1]. I do think there may be a limit to how far it can be improved, though. Like typed nil means that a variable of an interface type (say coming from pure Go code) should enter Lisette as Option >. Sure, one can match on Some(Some(h)) to not requir…

From your blog entry: > Go was not satisfied with one billion dollar mistake, so they decided to have two flavors of NULL Thanks for raising this kind of things in such a comprehensible way. Now what I don't understand is that TypeScript, even if it was something to make JavaScript more bearable, didn't fix this! TS is even worse in this regard. And yet no one seems to care in the NodeJS ecosystem. That's why I creat…

Your readme would really benefit from code snippets illustrating the library. The context it currently contains is valuable but it’s more what I’d expect at the bottom of the readme as something more like historical context for why you wrote it.

Re: Lisette a little language inspired by Rust that compiles to Go

#79
post #71

Earlier quoted context omitted.

From your blog entry: > Go was not satisfied with one billion dollar mistake, so they decided to have two flavors of NULL Thanks for raising this kind of things in such a comprehensible way. Now what I don't understand is that TypeScript, even if it was something to make JavaScript more bearable, didn't fix this! TS is even worse in this regard. And yet no one seems to care in the NodeJS ecosystem. That's why I creat…

Your readme would really benefit from code snippets illustrating the library. The context it currently contains is valuable but it’s more what I’d expect at the bottom of the readme as something more like historical context for why you wrote it.

Yup, in my TODO list (I've only recently published this package). For now you can just check the tests, or a SO answer I wrote a while ago (before I published the idea as an npm package): https://stackoverflow.com/a/78937127/544947

Re: Lisette a little language inspired by Rust that compiles to Go

#80
post #77
post #71

Earlier quoted context omitted.

From your blog entry: > Go was not satisfied with one billion dollar mistake, so they decided to have two flavors of NULL Thanks for raising this kind of things in such a comprehensible way. Now what I don't understand is that TypeScript, even if it was something to make JavaScript more bearable, didn't fix this! TS is even worse in this regard. And yet no one seems to care in the NodeJS ecosystem. That's why I creat…

How would TS fix null in JS without violating its core principles of adhering to EcmaScript standards and being a superset of JS?

Maybe spit warnings when undefined is used? In the same way it does for when you use typeScript in a type-loose way.

But yeah it's a fair point. Sometimes I think I should just write my own lang (a subset of typescript), in the same fashion that Lisette dev has done.

Post reply on HN