Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisette a little language inspired by Rust that compiles to Go

lisette.run

Post reply on HN
Print view View original

81–90 of 168 posts

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

#81

Post by Matl »

thomashabets2 wrote: post #67
smw wrote: post #49

Earlier quoted context omitted.

Rust's async story is much less ergonomic than go's -- mostly because of lack of garbage collection. That might be a good reason by itself?

Does Go actually have an async story? I know that question risks starting a semantic debate, so let me be more specific. Go allows creating lightweight threads to the point where it's a good pattern to just spin off goroutines left and right to your heart's content. That's more of a concurrency primitive than async. Sure, you combine it with a channel, and you've created an async future. The explicit passing of conte…

For one, I am glad I don't have to color my functions like your typical async.

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

#83

Post by masklinn »

uecker wrote: post #68
masklinn wrote: post #44

Earlier quoted context omitted.

> Yes, it's also a systems language without a runtime. But that's not the novel part. Low level strong correctness was absolutely a novel part. In fact it’s exactly why many people glommed onto early rust, and why it was lowered on the stack. Although learnability and weirdness budgets were also extremely novel in low level contexts which had been subsumed by C and C++. > horrors in C++ Yes, horrors in C++. Half bake…

Memory safety is not the same a scorrectness and more advanced type is also not the same thing as correctness.

50 years of computing have proved pretty conclusively that less than that is wishful thinking at best. Large C++ programs, even with massive amounts of resources and tooling, can’t even get memory management correct.

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

#84

Post by osigurdson »

thomashabets2 wrote: post #67
smw wrote: post #49

Earlier quoted context omitted.

Rust's async story is much less ergonomic than go's -- mostly because of lack of garbage collection. That might be a good reason by itself?

Does Go actually have an async story? I know that question risks starting a semantic debate, so let me be more specific. Go allows creating lightweight threads to the point where it's a good pattern to just spin off goroutines left and right to your heart's content. That's more of a concurrency primitive than async. Sure, you combine it with a channel, and you've created an async future. The explicit passing of conte…

Go's async story is great, as there is no function coloring at all. That being said, I don't like Go's syntax very much. The runtime is great though.

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

#85

Post by uecker »

masklinn wrote: post #83
uecker wrote: post #68

Earlier quoted context omitted.

Memory safety is not the same a scorrectness and more advanced type is also not the same thing as correctness.

50 years of computing have proved pretty conclusively that less than that is wishful thinking at best. Large C++ programs, even with massive amounts of resources and tooling, can’t even get memory management correct.

That Rust gives you correctness is very misleading claim.

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

#87

Post by ivov_dev »

kbolino wrote: post #75
baranul wrote: 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…

You are right, and thank you for pointing this out. I've opened an issue:

https://github.com/ivov/lisette/issues/12

I have a few approaches in mind and will be addressing this soon.

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

#88

Post by zozbot234 »

sa-code wrote: post #66
thomashabets2 wrote: post #45

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

> moves a lot faster in a GC language

Only in the old "move fast and break things" sense. RAII augmented with modern borrow checking is not really any syntactically heavier than GC, and the underlying semantics of memory allocations and lifecycles is something that you need to be aware of for good design. There are some exceptions (problems that must be modeled with general reference graphs, where the "lifecycle" becomes indeterminate and GC is thus essential) but they'll be quite clear anyway.

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

#89

Post by symaxian »

knocte wrote: post #71
thomashabets2 wrote: post #45

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…

You can enable null safety in TypeScript, seems like a pretty good fix to me.
Post reply on HN