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

151–160 of 168 posts

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

#151

Post by simonask »

seabrookmx wrote: post #143
simonask wrote: post #137

Earlier quoted context omitted.

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

Rust also has a much steeper learning curve. I can onboard an average developer that's familiar with Typescript and have them be productive in C# in a week. This one is more subjective, but I also think C# has a more mature and painless web stack. I love both languages but for me they each fill a different role.

I think this just says that TypeScript and C# are more similar languages than either is to Rust, which I would agree with. Rust's learning curve is not steep at all if you're coming from C or C++.

C# also has a pretty steep learning curve if you have to care about the things where Rust excels, like correctness or maximum efficiency (which typically does not include web stuff). I would even say that Rust is the easiest language in which to approach that level of correctness and efficiency.

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

#152

Post by rednafi »

phplovesong wrote: post #147
rednafi wrote: post #30

Go syntax and the Go runtime would be the perfect combo for me. Oh well... I love Rust for what it is, but for most of my projects, I can’t justify the added complexity. Sure, there are a bunch of things I miss from the Rust world when I’m working on large-scale distsys services in Go, but introducing Rust in that space would be a recipe for disaster. I guess the Go team knows that if they start adding everyone’s fav…

Are you a bot?

Nah made the same comment on r/golang

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

#153

Post by melodyogonna »

justaboutanyone wrote: post #116
melodyogonna wrote: post #108

Earlier quoted context omitted.

The compiler will be open-sourced in a few months.

At this point, it might be moot. Too many people are assuming it's still a closed-source thing and will dismiss it. Due to the closed source nature, every mojo announcement I see I think "whatever, next" If the actual intent is to open-source, just do it, dump out whatever you have into a repo, call it 'beta'

It does matter. It already has a pretty active community and thousands of people who follow the development closely, however, most won't commit until the entire language is fully opened... including me.

Valuable technologies are not so easily dismissed

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

#154

Post by melodyogonna »

adsharma wrote: post #111
melodyogonna wrote: post #108

Earlier quoted context omitted.

The compiler will be open-sourced in a few months.

There is a question of what benefit would it bring even if its open sourced? Static python can transpile to mojo. I haven't seen an argument on what concepts can only be expressed in mojo and not static python? Borrow checker? For sure. But I'm not convinced most people need it. Mojo therefore is a great intermediate programming language to transpile to. Same level of abstraction as golang and rust.

Python has a performance problem. Most people may not need it, but many people do. Languages like Rust and Go are heavily adopted by Python programmers either trying to understand low-level concepts or looking for something more performant.

And this is before we talk about the real selling point, which is enabling portable heterogenous compute.

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

#155

Post by ncruces »

thomashabets2 wrote: post #100
Matl wrote: post #81

Earlier quoted context omitted.

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

I agree that this is the big problem with Rust's async story. But like I said, in my opinion this compares with Go not having an async story at all.

Other languages have ill considered shortcomings. Rust has ambitious shortcomings.

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

#156

Post by [deleted] »

melodyogonna wrote: post #154
adsharma wrote: post #111

Earlier quoted context omitted.

There is a question of what benefit would it bring even if its open sourced? Static python can transpile to mojo. I haven't seen an argument on what concepts can only be expressed in mojo and not static python? Borrow checker? For sure. But I'm not convinced most people need it. Mojo therefore is a great intermediate programming language to transpile to. Same level of abstraction as golang and rust.

Python has a performance problem. Most people may not need it, but many people do. Languages like Rust and Go are heavily adopted by Python programmers either trying to understand low-level concepts or looking for something more performant. And this is before we talk about the real selling point, which is enabling portable heterogenous compute.

[deleted]

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

#157

Post by Defletter »

simonask wrote: post #150
Defletter wrote: post #149

Earlier quoted context omitted.

These don't seem like insurmountable challenges though. Unnamed impl blocks could work entirely within requirements. There could also be a lint to warn about any fields that are below trait definitions. struct Example { number: i32, } impl Example { fn boo() { println!("boo! Example::boo() was called!"); } } trait Thingy { fn do_thingy(&self); } impl Thingy for Example { fn do_thingy(&self) { println!("doing a thing!…

I mean, these are in the same file almost all the time anyway, and in that case all it gives you is an extra level of indentation. I don't think it's nicer at all.

It's comments like this that remind me of the conciseness-at-all-costs dogma: that people genuinely treat indentation as some kind of eldritch horror; that they would genuinely prefer "impl X" becoming "impl Y for X" (thus making it difficult to parse at a glance because the target keeps shifting places) over it. It's bewildering.

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

#158

Post by ModernMech »

melodyogonna wrote: post #108
ModernMech wrote: post #91

Earlier quoted context omitted.

Hold up... did I miss something, is Mojo open sourced now? Edit: No it is still not open source. There are still same promises of open sourcing eventually, but there is no source despite the URL and the website claiming it's an open language. What's "open" here is "MAX AI kernels", not Mojo. They refer to this as "750k lines of open source code" https://github.com/modular/modular/tree/main/max/kernels This feels icky…

The compiler will be open-sourced in a few months.

I think they should say that on their /opensource/mojo website if that's the plan. Rather, they are trying to gesture at "750k lines of open source code", when that code is only meant to be fed into their closed source MAX engine. That's a sleight of hand, bait and switch misdirection, and that's what feels icky to me.

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

#159

Post by osigurdson »

ninkendo wrote: post #142
osigurdson wrote: post #84

Earlier quoted context omitted.

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.

To be fair, Go’s async story only works because there’s a prologue compiled into every single function that says “before I execute this function, should another goroutine run instead?” and you pay that cost on every function call. (Granted, that prologue is also used for other features like GC checks and stack size guards, but the point still stands.) Languages that aspire to having zero-cost abstractions can’t make…

I'm not sure this is 100% correct. I haven't researched it but why would they perform such a check at runtime if it is 1)material and 2) can be done at compile time. However, even if it is, Go is only trying to be medium fast / efficient in the same realm as its garbage collected peers (Java and C#).

If you want to look at Rust peer languages though, I do think the direction the Zig team is heading with 0.16 looks like a good direction to me.

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

#160

Post by adsharma »

melodyogonna wrote: post #154
adsharma wrote: post #111

Earlier quoted context omitted.

There is a question of what benefit would it bring even if its open sourced? Static python can transpile to mojo. I haven't seen an argument on what concepts can only be expressed in mojo and not static python? Borrow checker? For sure. But I'm not convinced most people need it. Mojo therefore is a great intermediate programming language to transpile to. Same level of abstraction as golang and rust.

Python has a performance problem. Most people may not need it, but many people do. Languages like Rust and Go are heavily adopted by Python programmers either trying to understand low-level concepts or looking for something more performant. And this is before we talk about the real selling point, which is enabling portable heterogenous compute.

This is why transpilers exist.

py2many can compile static python to mojo, apart from rust and golang.

Is it comprehensive? No. But it's deterministic. In the age of LLMs, with sufficient GPU you can either:

  * Get the LLM to enhance the transpiler to cover more of the language/stdlib
  * Accept the non-determinism for the hard cases
The way mojo solves it is by stuffing two languages into one. There are two ways to write a function for example.

I don't think the cost imposed by a transpiler is worse. In fact, it gets better over time. As the transpiler improves, you stop thinking about the generated code.

Post reply on HN