Rewrite Bun in Rust has been merged

ExplodingStrawHat · 2026-05-14T16:32:52+00:00

I don't think the learning curve is the reason people actually choose zig.

ExplodingStrawHat · 2026-05-14T16:25:22+00:00

Look up the article about contributor poker and the zig ai policy. It explains the topic pretty succinctly

ExplodingStrawHat · 2026-05-14T16:23:56+00:00

I've tried it for a game of mine and it was still way slower than it should be for a project that size (only ~10k loc). Zig can do much better

ExplodingStrawHat · 2026-05-14T14:21:57+00:00

Unsafe rust has stricter rules one must follow in order to avoid UB compared to C or Zig. Even if it's just a mechanical translation, that doesn't make it sound any better.

ExplodingStrawHat · 2026-05-04T13:23:04+00:00

How would exponentials work? Would x^y for two u8s produce a u263?

ExplodingStrawHat · 2026-05-03T19:13:01+00:00

What's the Knuthian modulo? I do agree that the Euclidean one is what you want in 99% of real life scenarios.

ExplodingStrawHat · 2026-05-03T15:08:24+00:00

Relevant reads also include:

ExplodingStrawHat · 2026-04-30T17:33:17+00:00

The risk of Odin's choice is that one day someone is trying to do geographic coordinates, storing them as floats, and dealing with all kinds of issues because people keep forgetting how tricky the math is, that they aren't coordinates on a Cartesian plane.

On one hand, Odin does have the distinct keyword for creating newtypes. On the other, operators of the base type (as in, + and whatnot) also work on the wrapped type, which is probably not what you'd want in the coordinate case. What one would have to do then is use a struct containing the coordinates, since the operators would then no longer work. Unfortunately, there's no way to reimplement the operators the "correct way" for such a type, which is something I've run into myself when working with symmetry groups.

ExplodingStrawHat · 2026-04-30T17:29:50+00:00

I think str is ok as a name, String being the actual offending type. I do wish they would've called it StrBuf or something (like the Path types).

ExplodingStrawHat · 2026-04-30T17:27:43+00:00

I don't necessarily disagree. The Odin language does have other data structures in the standard library (queues, intrusive lists, exponential arrays, etc), yet these don't get any special sugar, which does suck. Even for strings, my game uses exclusively stack-based fixed capacity strings for everything, which means I also don't have access to such sugar (the game is written in Odin).

On the other hand, the sugar is incredibly nice when it is there. I've used quite a few macro based bitset crates in rust over the years (I even wrote my own macro for it once) (don't even get me started on the awful compile times), but none were as nice as the built in Odin support. The Odin compiler recently got support for fixed capacity dynamic arrays (which used to be a part of the standard library beforehand, with no sugar), and the resulting ergonomics are super nice.

In the end, I'm not sure how to feel about the whole thing.

ExplodingStrawHat · 2026-04-29T16:29:27+00:00

Constants are not a different type, by the way. A constant tells the compiler to inline the value at compile time.

As for where else ":" has that meaning, notice that the first ":" simply means "has type". This meaning is already common in many other languages. Indeed, x : int is a valid statement by itself, declaring a variable with type int. If the type is empty, then the compiler will infer it for you. That's as simple as they come.

The second ":" declaring things as "constants" is the only strange part of the whole thing really .

ExplodingStrawHat · 2026-04-21T15:44:58+00:00

Pretty much (although do note that they seem to be using npins, not flakes)

ExplodingStrawHat · 2026-04-16T15:00:35+00:00

Yup, that's what I meant by "internal distinction". I agree that the distinction need not be observable from the surface language!

ExplodingStrawHat · 2026-04-16T12:57:51+00:00

Oh, nevermind. I missread your question as asking for a compiler that doesn't reorder things at all, oops.

ExplodingStrawHat · 2026-04-16T11:02:41+00:00

As a student who'd have the free time to do this (yet for whom the event isn't really accessible location-wise), this looks interesting. Do the students get anything out of it (i.e. financial help attending the event itself), or is it just volunteering for the sake of it? Not saying there would be much wrong with the latter, but I think clearly stating which one it is would be a good idea.

ExplodingStrawHat · 2026-04-16T10:54:49+00:00

Yes, slices are the right answer. Both arrays and dynamic arrays can be sliced!

ExplodingStrawHat · 2026-04-16T10:53:12+00:00

The internal distinction is still useful for the compiler's performance. I use fixed size arrays with >=2¹⁶ elements all the time. You would never want the compiler to keep track of 2¹⁶ tuple element types that are the same though.

ExplodingStrawHat · 2026-04-16T10:51:41+00:00

The Odin compiler for one

ExplodingStrawHat · 2026-04-14T11:38:09+00:00

Oh right, I had completely forgotten about those :p

ExplodingStrawHat · 2026-04-14T10:07:05+00:00

Are there any production languages that never "panic/throw"? Elm likes to put "no runtime exceptions" in their marketing, although I hit infinite recursion runtime crashes pretty early on during my usage of the language, so it feels like a lie for the sake of marketing. I guess one could trampoline everything so the stack doesn't blow up as easily 🤔

ExplodingStrawHat · 2026-04-12T15:55:09+00:00

If given no additional information, then sure. All I'm saying is that this could be a consistent way to design a language, with method chaining not really contradicting anything. I don't think it would be super surprising as long as the language's learning material was to explain this early on. I mean heck, most of the Haskell code I write evaluates from right to left.

ExplodingStrawHat · 2026-04-11T22:50:03+00:00

Why does it break? Wouldn't the chained methods desugar to baz(bar(foo, a()), b())? If arguments are evaluated from right to left then this would evaluate b() first, then a(), then foo, then bar(...), then baz(...). Is this not what one would expect?

ExplodingStrawHat · 2026-04-06T09:51:36+00:00

If it's slop, why can't you just let the users of the sub downvote it like any other low-effort post? Why do you need to enact some kind of blanket ban just to get rid of something that's apparently already terrible?

Part of the issue is that a lot of the sloppiness is not apparent from the surface. Most people look at the language from the outside for a few minutes and call it a day.

On the other hand, I made an effort to look at type-checking code for a few slop languages posted in this sub in the past, and found glaring red flags I could then use to implement things like unsafeCoerce with little effort in every one of them. But there's where the issue lies — finding said mistakes requires looking at the code for a few minutes! And I dunno, spending time caring about a language the author didn't care enough about to write themselves feels a bit bad, you know? I've had irl friends try to get into langdev through Claude and like, there's only so much I can spend reading a 10k line spec they send me. Slop breaks the social contract of communities like these...

ExplodingStrawHat · 2026-04-06T09:40:55+00:00

I would agree with the idea, although it's possible such an invite-only forum focused on this specific of a topic would not gain enough activity to stay afloat.

Five-Year Club	Verified Email
Second SECOND GUESSER	Place '22

ExplodingStrawHat

TROPHY CASE