← Back to context

Comment by weinzierl

13 hours ago

Rust's appeal (to me) is safety, performance, DX in that order.

Where does Goose sit when classified along these dimensions?

Sure, performance is right there on the packaging but no word about UB in the README. I read "Goose has syntax familiar to C and Rust" as DX in the same ballpark, but is it a performance first or safety first language.

If it is the former it occupies the same crowded niche as C++ and its many cousins and will have a hard time.

If it's the latter it will have much more room to prosper. We don't have enough languages in the niche that Rust and Ada fill right now.

9 comments

weinzierl

Reply
Aardappel  11 hours ago

Goose has no "unsafe" feature, and no undefined behavior, and is fully memory safe.

It is obviously has a lot of potential to be very fast.

It even does pretty good on DX. There is no borrow checker to fight. Algorithms that need indices in Rust are strongly typed references in Goose. Generally pleasant easy to read and write code.

The biggest thing against DX may be exactly where performance comes from: you need to think a bit on where to store your data :)

vanderZwan  13 hours ago

Well, "safety" is a lot of things so you have to be a bit more specific than that about your use-cases. And I can't really answer it either way - I think WvO has to chime in about that himself - but I can point to some things that might give you some idea of what to expect. Here's what WvO wrote a few weeks ago when he shared Goose on twitter:

> Goose: my latest programming language. Safer, faster and less memory than Rust/C++ for algorithms where tightly packed, flat data structures matter.

> It can represent more kinds of data structures as flat, pointer-free bytes than any language I know.

https://xitter.cf/wvo/status/2107979660558766351

So one way to answer might be: how often do you reach for unsafe when using Rust? If you don't I guess Rust is safer. If you do… it gets trickier.

As for UB, I guess you could try looking through the spec and/or the reference? Like, the code is mostly generated by Claude after WvO wrote a specification. If it were anyone else I'd be worried, but given WvO's cv I actually suspect that means the spec leaves basically no ambiguity.

However, Goose compiles to C. Does that by definition mean UB sneaks in, or is there a "UB free" C subset? I don't write C, so I don't really know.

  • jibalt  3 hours ago

    Certainly there's a UB free C subset ... everything specified by the C Standard or designated as implementation-defined is UB free by definition.

    UB in C potentially destroys the universe so C programmers do their best to avoid it. A backend that generates C code is a lot more easily constrained than arbitrary manual code. While it's conceivable that a C backend could produce UB code, it would be a severe bug and isn't likely. It most certainly isn't "by definition" ... that suggests some serious conceptual error.

  • weinzierl  12 hours ago

    I guess my question is if you can trigger UB in regular Goose and if you can, would it be considered a bug. I realize that this doesn't necessarily have a simple yes or no answer but I still think it'd help to know if Goose is more on the C++ side or the Rust side.

    The complete omission of UB in the README could be one of two things. Either that the topic is not important or that it is considered a given and not worth mentioning.

    • vanderZwan  12 hours ago

      Hmm, well the benchmarks always use an explicit "faster than idiomatic C/C++ and safe Rust". Similarly it also notes that in theory you could write equally fast C/C++ (since Goose compiles to C), but it would be an unreadable, unsafe mess.

      Note also the fact that e.g. array indexing has bounds checks without escape hatches for the programmer, but the compiler can elide quite a few of them, and the language has tools to help the programmer write code that is guaranteed to be check-free.

      I think that suggests the ambition is to compete with Rust in the domain of combining safety with not compromising on performance.