1.  

    What other common runtimes are significantly faster than Go, and in which dimensions? As far as I’m aware, Go’s runtime, which is optimized for latency, is as fast or faster than anything on the market, but I’d be happy to see data suggesting otherwise!

    1.  

      I’ve used Amethyst, SizeUp, Divvy, Spectacle, and now Moom — I’ve found Moom to be the best of the bunch.

      1.  

        It’s hard to describe how much of a game changer this is for Alloy. Before this, dealing with time was painful. It was just dreadful. I only used Alloy to model static data models because of this. Now, it’s wrapped up in a nice bow with very Alloy-like sharp terminology and semantics.

        Great decision from the Alloy maintainers to include these features - this issue might have caused Alloy to fade into obscurity.

        And, thank god for @hwayne. Something about his POV and message resonates much more with “working” programmers it seems like. I think this will end up doing a lot of good for humanity in the long run. Yea, formal methods are always going to be based in theory, but there are plenty of ways to apply them at work. And you can’t have as much fun with them by yourself, so we need more adopters on the job.

        1.  

          I forget if I’ve mentioned it on here before, but HapticKey is worth trying. It uses the magnets in the touchpad to emulate feedback on the Bar, it work better than you’d expect.

          1.  

            I have yet to have it take on at work at all. Even lighter weight things like property-based testing are outside of the comfort zone of a lot of people. I will say, what has piqued the most curiosity is when you show someone relevant to something they’re working on, instead of speaking philosophically / abstractly.

            For example, today I was able to draw up a quick proof in Isabelle to show that introducing a feature flag to a code path wouldn’t break the existing behavior when the flag was disabled. Simple example, but it was received well.

            1.  

              What is it licensed?

              1.  

                Ditto to all of this. I spend a lot of time in and around WebGL graphics. One of our in-house apps makes my old MacBook and the laptops of all my colleagues sound like the decks of aircraft carriers. It’s completely silent on my new M1 MacBook Pro.

                I was frankly a little nervous about getting this machine. I need it to run everything from Blender, a .NET server with a proxied webpack dev server on top, various node servers, to a headless WebGL engine. I was pleasantly surprised to find it does all but the last those things without breaking a sweat. Things that run natively feel instantaneous. Things that run on Rosetta 2 still feel snappier than before. Industry adoption for Apple Silicon is moving apace. I’m pretty sure I’m just a dependency upgrade away from getting the last item on my list working and I can finally shed my old machine for good.

                The most revolutionary thing about the experience of using the new MacBook Pro isn’t the features or build quality per se (although they’re both excellent). It’s that the performance bottleneck in my day-to-day work is squarely back on the network. I haven’t felt that way in a while.

                1.  

                  There is nothing special about . . .

                  I’ve always likened Mac vs. non-Mac trackpads to driving an e.g. BMW 335i vs. a Chevrolet truck. It’s just a more precise and overall nicer user experience.

                  1.  

                    I can’t even get my colleagues to read my informal correctness proofs, so not sure how I’d sell them on formal methods…

                    1.  

                      I keep trying to introduce this on a team wide scale at the $WORK but so far its really just crazy ol kstatz12 tinkering in his imagination closet

                      1.  

                        The appearance of the page has a great deal to do with it. It is not a website for technical people, but a useless, baseless-feeling marketing page.

                        Contrast with e.g. ganeti, which is a no-bullshit site, or even openstack, which manages to be fancy-looking without giving a strong useless, baseless-feeling marketing page feel.

                        I just gave danube’s site a second look and, really, it is disgusting. I can’t help but close the page almost immediately. The more I scroll, the more the annoyed I am. Just my very subjective view, but a view I suspect is not uncommon.

                        1.  

                          far fewer people will be creating packages rather than using them

                          Just to make this explicit, I’m speaking from a context which includes open-source software (maybe 10-20% of all software produced in the world) and closed-source software written and maintained at market-driven organizations (maybe 80% of all software).

                          In this context it’s my experience that essentially every programmer is both a consumer and producer of packages. Even if a package has only a single consumer it is still a member of the package ecosystem, and the needs of it’s (singular) author and consumer are relevant! So I don’t agree that far fewer people are creating packages than consuming them. In fact I struggle to summon a single example of someone who consumes but doesn’t produce packages.

                          20% of packages constitute 80% of package usage

                          I agree that the packages-vs-consumers curve is pretty exponential. I agree that tooling can and should support the needs of those relatively few packages with vastly more consumers than producers. But I don’t think it’s as extreme as you’re describing here. I think the “long tail” of packages consumed by a single-digit number of consumers represents the 80% of overall package consumption, the 80% of the area under the curve.

                          1.  

                            I don’t think it’s really competing with the simple editors, rather it seems to be a hedge against vscode.
                            On my laptop, opening a small python script, just took 13 seconds to load from scratch, so I guess that is the target to beat.

                            1.  

                              The latency is there, you just got used to it. Linux is pretty bad, unless you’re using the PREEMPT_RT patches.

                              You can easily measure how bad it is by running cyclictest from rt-test, with SMP enabled and SCHED_FIFO policy. It will set alarms and then measure the difference between the requested time and the time it runs at.

                              Minimum is irrelevant, average has some limited value, max is the column you want to look at. Unit is µs.

                              With mainline kernel, you’ll see max cross into ms range in a matter of minutes, if not seconds. Leaving it running (its cpu usage is low) for a day or two, you’ll see max get into tens of milliseconds.

                              linux-rt patchset does help, but only for scheduler latency. The userspace Linux input stack is another layer of bad.

                              Latency is something that needs to be a core design target. Like security, it cannot be tacked in.

                              To put things in perspective, AmigaOS (1985) input.device task ran with priority 20, making it the highest priority task in the system, which is realtime with hard priorities; if a higher priority task becomes runnable, it will run immediately.

                              1.  

                                It’s not electron

                                It’s written in Kotlin mainly, a little bit of Rust for native parts, Skiko (Skija + AWT) The UI framework is similar to Compose, but we started when Jetpack Compose wasn’t there :)

                                Source

                                1.  

                                  The inward/outward comparison is apt.

                                  I ended up in acme after 15+ years of emacs, partly out of curiosity after watching an rsc screencast and partly because I needed a break from my yearly cycle: juggle elisp packages to add features, tinker, tinker too much, declare configuration bankruptcy and repeat again.

                                  I’m old enough that being able to quickly reuse existing tools is more valuable than the satisfaction of reimplementing them or integrating them into an editor. I do use other editors occasionally, and they are shiny and feel cool and certainly better at some tasks. But I end up back in the pale yellow expanse of tag bars and columns, because there’s another tool I need to interact with and I know I can get it done with files and pipes.

                                  I sometimes think about how much time and effort goes in to editors and tooling integration, and wonder how we got to such a point.

                                  1.  

                                    What’s the chance that this is not electron or similar?

                                    1.  

                                      Not free, but I recently saw some people recommending https://hookshot.app

                                      1.  

                                        I believe based on the footer this should have the self-submission flag?

                                        1.  

                                          Wow, first I heard of this. Looks like it’d be fine to use something like the HD600’s with.