Hacker News Reader

Comment by MichaelNolan | Hacker News Reader

Gleam is such a beautiful language. I wish I had the opportunity to use it more. If it could compile (transpile) to a native target like rust or go, it would be truly perfect.

View on HN

I am working on a language called blasphemy which intends to do this.

Looking forward to be able to claim to be “proficient in blasphemy” on my cv! /s

I have project language called spite. You can write apps in it or out of it.

What do you mean by native target in this instance? Since you mentioned Rust, which is a systems language that compiles to native with no runtime, and Go, which has a garbage collector and runtime, as examples I'm a little confused.

I would love to see support for wasm and wasi.

You just described Lisette. Its very close to gleam, and compiles to Go.

I feel like Go would be a great backend target for Gleam

Go's garbage collection isn't well suited for an immutable language like Gleam, so the performance would likely be disappointing compared to other targets.

The concurrency model in Go is also poorly suited to the BEAM's process model. Goroutines share a heap so you can't do a lot of things safely that processes can do. Having independent memory space for a process allows you to free it safely when work is done without GCing everything and you can also safely share data because you have a copy not a ref.

There is this: https://github.com/ergo-services/ergo which i keep meaning to take a look at, but never seem to quite get around to…

It looks reasonable but I’d have to see how they actually do memory management.

author here, thanks for the mention.

PS: i'll be publishing Ergo Framework for Rust soon (same actors, same network, fully interoperable peers)

An JavaScripts is? Rust is probably a more performant target regardless

Surprisingly yes! JavaScript's allocator and garbage collection system is quite well suited to immutable programming.

Rust is a very poor compile target as the compiler is slow and not commonly available, and the aspects of Rust that make it good for humans to write make it a poor choice for compilers to target. With humans the produced code is verified, but with a compiler the compiler is what is to be verified, so the inflexibility of Rust are largely a hindrance compared to other native compilation targets.

What lower-level language do you think aside from rust which can be more helpful for the purposes of being a compile target, nim/D both support garbage collection and non garbage collection, so would languages like these be more preferable

I really love gleam and its community and I would really really love if gleam could be more like golang though, which can help it in compiling to machine code

gleam language but with the developer experience of golang (cross portability/small binaries/fast compiled language which is fast to compile) is honestly one of my fever dreams and I would love to know if it can ever be a reality!

For that sort of compilation target more flexibility is beneficial, so C, Wasm, LLVM IR, Cranelift IR etc are better than Go, Nim, and D in my opinion.

> cross portability/small binaries/fast compiled language which is fast to compile

You don't need native compilation to build fast single file executables for a program, there's ways one can achieve this with Gleam today. Bundling the BEAM into your Gleam application executable with something like Gleepack is one option, and this will produce smaller executables than Go will by default for many applications.

I don't get the impression that javascript is among Gleam's targets because of performance.

- server target: BEAM

- client target: js

Once you've covered those bases, you're kind of done.

If the server needs to do something special in an OS process... might as well let the OS mediate that interaction so that it can be fully generic, rather than trying to bend the language around whatever the unknown action might be.

For that there is Lisette. Close to gleam, compiles to Go.

I just learned about Lisette, and from there Gala. Any thoughts on Lisette vs Gala?

Never used gala, but it seems going a bit more down the deep end, frankly it has features is dislike / would never use.

Lisette has been pretty straight forward, with its good Go interrop and familiarity (i have ocaml experience). Tooling is GREAT for such a young language. Im also a huge fan of the recent addition of a "zero" value. No nils like you get in vanilla Go.

I tend to write libraries in Lisette i then import in my go "shell", thats more or less a main function with some setup.

Full (lisette->go->lisette) Go interrop is still a WIP, but im certain it will be improved upon soon.

Thank you for the reply! There's very little public discussion (at least that I can find) about people's experiences writing Lisette, the language, or how well agents do with it so far so I really appreciate it. Been debating past couple days if I spend some of my claude sub tokens to try a partial rewrite of some code.

Yeah, i think lisette just needs some time (its pre 1.0, so probably not used in prod), but that said i read Listte is actually already used for building compilers for other languages.

Some people like to live on the bleeding edge, and once again, that said, the Go runtime is just so good so you have a solid base, and can always eject from lisette by just keeping the generated Go source. That makes it a more safe language to choose.

It seems to me like both Gala and Lisette are fairly safe to invest in for small projects that you'd otherwise write Go in assuming you have the token budget and patience to be able to as ask an agent to make the generated Go more idiomatic afterwards / do a native Go rewrite if needed.

I'm still not sure if I would rather test out Gala or Lisette or both, I appreciate hearing you've had a positive experience with Lisette!

Not sure about gala, but lisette produces good and readable go-code. There is a prelude (option, reault etc) package you possible would want to get rid of if you ejected. But an LLM could easily do this manual task for you pretty easily.

Reply on news.ycombinator.com