Live data from Hacker News

Lisette a little language inspired by Rust that compiles to Go

lisette.run

131–140 of 168 posts

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

#131
post #80
post #77

Earlier quoted context omitted.

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.

You can already do this with strict type checking enabled and the NonNullable type.

You can't enforce it in any normal codebase because null is used extensively in the third party libraries you'll have to use for most projects.

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

#133

Earlier quoted context omitted.

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 p…

I've also found that traversing a third-party codebase in Python is extremely frustrating and requires lots of manual work (with PyCharm) whereas with Rust, it's just 'Go to definition/implementation' every time from the IDE (RustRover). The strong typing is a huge plus when trying to understand code you didn't write (and I'm not talking LLM-generated).

[dead]

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

#134

Earlier quoted context omitted.

> 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" bec…

> Only in the old "move fast and break things" sense No, definitely not only in that sense. GC is a boon to productivity no matter how you slice it, for projects of all sizes. I think the idea that this is not the case, perhaps stems from the fact that Rust specifically has a better type system than Java specifically, so that becomes the default comparison. But not every GC language is Java. They don't all have lax t…

Rust does have GC in external crates, one was used for implementing Lua in Rust.

A Lua interpreter written in Rust+GC makes a lot of sense.

A simplified Rust-like language written in, and compiling to, Rust+GC makes a lot of sense too.

A simplified language written in Rust and compiling to Go is a no-go.

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

#135

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…

Golang does have a lot of weird flaws/gotchas, but as a language target for a compiler (transpiler) it's actually pretty great!

Syntax is simple and small without too many weird/confusing features, it's cross platform, has a great runtime and GC out of the box, "errors as values" so you can build whatever kind of error mechanism you want on top, green threading, speedy AOT compiler. Footguns that apply when writing Go don't apply so much when just using it as a compile target.

I've been writing a tiny toy functional language targeting Go and it's been really fun.

Go's defer is generally good, but it interacts weirdly with error handling (huge wart on Go language design) and has weird scoping rules (function scoped instead of scope scoped).

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

#136

Something that I don't understand about Rust, or these rustylangs, is the insistence of separating structs and methods. Don't get me wrong, I like named-impl blocks, but why are they the only option? Why can't I put an unnamed-impl block inside the struct? Or better yet just define methods on the struct? What's the point of this and why do these rustylangs never seem to change this?

There are several reasons.

1. Struct fields are really important in Rust because of auto-traits. Your life as a Rust programmer is easier if all fields fit on the screen, because one of them may be the reason your struct is `!Sync` or whatever.

2. Impl blocks can have different generic bounds from the struct itself, which is a nice shorthand for repeating the same generic bounds for a series of related methods. So you need to be able to write multiple per type anyway. It would he confusing if there was an “implied” impl block to look for as well.

3. It helps emphasize that Rust is a language that wants you to think about the shape of your data.

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

#137

Well that's why I decided to go C# for general purpose stuff

Ditto. C# gets a bad rap due to its Windows-exclusive history, but it's now cross platform and has most of the features PL nerds are looking for. Strict nulls, pattern matching, a really mature and easy to use async ecosystem (it invented async/await), even a lot of the low level stuff is there (unsafe{} blocks ala rust and manual memory management where needed).

C# is nice, but it is nowhere near Rust in terms of safety or expressiveness. Thankfully they are finally adding discriminated unions (sum types) and other sorely missing features.

Unsafe in C# is much more dangerous than unsafe in Rust, precisely because it doesn’t actually color a function. It just allows its body to use pointers. This is why you have methods in the CLR called “DangerousFoo()”, and the compiler does nothing to prevent you from calling them.

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

#140

Looks great. But I can't help wondering: If it is similar to Rust why not make it the the same as Rust where it feature-matches? Why import "foo.bar" instead of use foo::bar? Why Bar.Baz => instead of Bar::Baz =>? What are you achieving here? Why make it subtlety different so someone who knows Rust has to learn yet another language? And someone who doesn't know Rust learns a language that is different enough that the…

It does not matter, you (rust devs) won't use anything else either way and other people just don't care
Post reply on HN