1. 23
  1.  

  2. 7

    Name is very close to ‘Vala’ project.

    1. 1

      At first I thought that’s what this was. But this is actually quite a bit neater

      1. 1

        Yes I had to re-read the title 3 times to convince myself it didn’t say Vala :)

      2. 5

        Related story and discussion from some days ago. :)

        Vale seems promising, hopefully it will find its niche.

        1. 4

          I especially like what they call higher RAII. Or hot potato object, as I call it (I’ve had that idea too). Instead of having an object with an implicitly called destructor, you have an object that must be destructed and a function that will consume it – effectively a destructor you are not syntactically allowed to forget to call explicitly.

          As mentioned, a normal function is more flexible in that it can take parameters and return something, i.e. fail. But there is more to it:

          • Non-lexical lifetimes: You are free to place the destructor call where you want. This is where the syntactical scope ends (it can not end any other way). Yes, it can overlap other scopes and begin and end in multiple places.
          • Verifiable destruction order: Instead of having to store references in objects just for destructors’ sake, the destructors can take them as arguments. As long as object dependencies are made explicit this way, they become impossible to destroy in the wrong order, i.e. passing an object after we have ended its scope.
          1. 3

            On the guide page, code snippets render with proportional font if remote fonts are disabled.

            1. 1

              There are some promising ideas in here that I hope continue to be fleshed out.

              1. 1

                https://verdagon.dev/blog/generational-references

                genFree increments the generation number

                What happens when the generation number overflows?

                1. 1

                  That spot in the address space becomes unusable, I think.

                  It’s a 64 bit counter, so you get about a century before it overflows even if you’re incrementing one at a couple GHz.

                  1. 1

                    Probably a good solution.

                    So long as nobody chews up bits for flags or something and never runs on an 32 bit word machine and CPU speeds dont do anything amazing in the next 40 years like they did in the previous (they probably won’t)… should be OK.

                    Seems like not a thing to worry about…. but I have been bitten before. :-) (Timer tick counters was the specific thing that bit me)

                    Here is another fun one… https://dev.to/matheusgomes062/a-bug-was-found-in-java-after-almost-9-years-of-hiding-2d4k

                    1. 1

                      They mention the generation counter being “8 bytes” explicitly in the linked post, so I don’t think it depends on CPU word size. I don’t think it’s too bad? My understanding is that the counters would saturate when they hit max value, rather than rolling over and creating a use-after-free bug or anything like that.

                      Relatedly, I think it’s best to not have multi-year uptime on any process because everything should reboot regularly anyway. a) to verify/ensure it’s still possible and b) because nothing lasts a decade without at least one interesting CVE being announced that needs a patch and reboot.

                      1. 1

                        Relatedly, I think it’s best to not have multi-year uptime on any process because everything should reboot regularly anyway.

                        Unless it’s job is controlling something… in which case it better be up and working for as long as whatever whatever it’s controlling is up and working…

                        a) Start up and shutdown is about recovering resources so you can do something different… Clean shutdowns are a waste of time and effort.. crash only is the way to go.

                        b) Not everything is connected.

                        c) I think it’s best to design for a multi-year uptime, otherwise you just creating a stick to whack yourself in the face which bad actors may find and create a face whacking CVE with.

                        1. 1

                          Unless it’s job is controlling something… in which case it better be up and working for as long as whatever whatever it’s controlling is up and working…

                          Well, okay. That’s firmware, not software. And it had fucking well better not be connected to the internet. :)

                          1. 2
                            1. 1

                              Yes