Freeze javascript tuples on creation

[BradBot1]

Since gleam's (and erlangs) tuples are immutable utilising Object.freeze() on any tuple declaration would enforce the same expected immutability on JavaScript

[lpil]

Are there performance implications to this? If it improves performance that would be a good motivator for us to do this.

[BradBot1]

It doesn't seem to have a any large impact on array performance: perf testing. But there is definatley a runtime benefit to knowing that created tuples enforce the expected immutability.

This cannot be said for Objects where there is a clear negative performance impact: perf testing

[yoshi-monster]

There is a not insignificant performance overhead in calling Object.freeze, too. Gleams semantics already guarantee that a tuple cannot be changed (or at least that you cannot observe it). If you modify a tuple from FFI code, you're lying to the compiler. This is inherent to FFI code.

---

Unrelated: I've seen people link to perf.link a bunch recently. Just clicking the run button a bunch of times yields vastly different results, and they don't show any relevant statistical properties. Looking at their code this impression is confirmed: while they do have some good ideas (moving work into threads), they also don't really understand what to do with those threads (spawning one every millisecond), how to take statistically significant measurements, or what the limitations in precision means for their test methodology. I would not trust them at all.

[BradBot1]

I'd prefer to do more concrete tests but I mainly commune on GitHub via my phone, so it's just not possible. I've found running tests several times and averaging yields good enough results. I'll also only ever use it as a way to backup claims with common online consensus such as that object.freeze is bad for objects. I'd love it if you know of an alternative that is effective as my prior choice (jsperf.com) is always down so I can't trust that examples that I send can be observed