Threads for asb

  1. 1

    There’s a fairly active debate over on Reddit /r/programminglanguages on the degree to which this technique is useful.

    1. 4

      Will the addition of multicore and algebraic effects make OCaml gain more traction?

      Where does it stand compared to F#, Haskell, Scala or Rust right now?

      1. 9

        Will the addition of multicore and algebraic effects make OCaml gain more traction?

        It’s difficult to make predictions, especially about the future, but in my opinion, I very much doubt these things would have any effect on traction. In my experience people will not use OCaml because they don’t know, or don’t want to know functional programming, or simply don’t want it for various personal or organizational reasons. It’s almost never about the lack of any particular feature. In fact, people who reject OCaml outright very rarely have any idea what feature OCaml has or lacks.

        Where does it stand compared to F#, Haskell, Scala or Rust right now?

        I am not sure comparing any of those languages makes sense.

        F# is .NET tech, yes you can run it on Linux or whatever, but realistically speaking, if you are not into Windows/.NET you would never use this. Also F# has the fewest features of the bunch, which is not necessarily a bad thing, but you mentioned fancy features like algebraic effects whereas F# is late 80s level of sophistication. F# doesn’t even have ML-style modules. And btw, this is not a me taking at jab at F#, 80s level of sophistication is great when the industry is still stuck in the 60s. Of course, F# is great if you are stuck in the .NET ecosystem.

        Haskell is a non-strict language. OCaml makes it much easier to reason about performance, and to get good performance. Haskell has many features OCaml will never have (too many to list here), but now they have linear functions, and are discussing ways of adding dependent types. Very cool stuff, but unrelated to the reason people use OCaml.

        Scala is in the Java ecosystem. Just like with F#, Scala is a non-option if you are not already in the Java ecosystem. And if you are, all the other languages you mention will not be an option, so it’s all moot.

        Rust is not a functional language and has a very different applicability domain compared to any of the languages mentioned so far which makes any comparison difficult and pointless. It’s the only one specifically targeting low-level stuff. Yes, I am very aware of MirageOS, it’s a very niche thing, and has far less applicability than Rust in general. E.g. people use rust to run code on microcontrollers today. Feature wise, its type system is the most limited compared to all languages discussed above. I very much doubt Rust will ever get algebraic effects, because algebraic effects are hard without a GC. And I have no idea if OCaml will ever get linear types, or if they even want them. Linear types are difficult to mix with effects.

        Algebraic effects and linear types are very different things, but both can be employed to tame IO-effects, and both OCaml (with effects) and Rust (with linear types) do exactly that. So since they solved “the IO problem”, I very much doubt they would be interested in adding more features, especially Rust.

        For the record, I am working on a language that has both effects and linear types.

        1. 2

          For the record, I am working on a language that has both effects and linear types.

          Sounds interesting - have you published anything about it so far?

          1. 3

            Not yet.

        2. 7

          One of the killers of D’s momentum over a decade ago was the conflict between two (three?) possible standard libraries.

          While a lot of other problems have been solved, Ocaml still suffers from this one. Until the whole mess with multicore/lwt/async sorts itself out (which will also impact any standard library), and the community completely settles on a single standard library, I do not think there is that much hope for increased traction. Also: documentation that isn’t just type signatures, which (especially) many third-party libraries suffer from.

          For better or worse, Rust is a better option for the time being, mostly due to better tooling and a vastly larger library ecosystem. I’ve been down this road several times, and ecosystem size almost always wins out, unless you’re tinkering.

          1. 7

            Until the whole mess with multicore/lwt/async sorts itself out (which will also impact any standard library), and the community completely settles on a single standard library …

            Effects mean you don’t need monadic libraries like lwt and async now, and most “concurrent” code can just be written as plain OCaml, so things will likely converge. Porting code is straight-forward and can be done incrementally. See e.g. the migration instructions at lwt_eio (which allows running Lwt code under the (effects-based) Eio event loop).

            You can even run both Lwt and Async code together, along with new effects based Eio code, in a single domain. See e.g. https://github.com/talex5/async-eio-lwt-chimera!

            1. 1

              For context, u/talex5 is the main dev of Eio. I think a lot of us (OCaml users) are looking forward to a world without monadic IO libraries, and Eio is exactly that, along with clean primitives for byte streams, structured concurrency, etc. If there’s a time where OCaml can gain more interest, I think OCaml 5.0 (or 5.1) is exactly that time.

        1. 3

          Catching up with things I’ve been hoping to progress at work, as my son was only in school for half days last week (first week in reception) which was quite disruptive.

          I’m hoping to finish off a post for my blog covering what’s new for RISC-V in LLVM 15.

          1. 6

            Posting for a couple of reasons:

            • These monthly updates are a great move for Arch (they’ve been posted regularly for almost 12 months now).
            • The babysteps towards enabling buildbots are exciting. Although the need for maintainers to have final approval is obvious, it may come as a surprise just how centralised the current package update process is. Hopefully in the future fixes or updates can be submitted for PKGBUILDs via pull requests, with CI creating the package and testing, pending final approval from the maintainer.
            1. 5

              The babysteps towards enabling buildbots are exciting. Although the need for maintainers to have final approval is obvious, it may come as a surprise just how centralised the current package update process is. Hopefully in the future fixes or updates can be submitted for PKGBUILDs via pull requests, with CI creating the package and testing, pending final approval from the maintainer.

              I do actually need a lot of help to pull this off though :)

              The latter point is interesting, but I’m of the opinion that the gitlab CI is good enough for linting and testing merge requests. The issue with gitlab CI is how you do something more abstract like a complete rebuild of readline dependencies, or allow maintainers to build towards temporary staging repositories before doing the main integration work towards testing.

              Currently I’m just messing around hoping people get inspired.

              1. 2

                Yes, I’d imagine allowing such a flow for the “easy” things first would be the low-hanging fruit. Minor tweaks like version bumps, cherry-picking an upstream bugfix, adding a missing dependency. I don’t think this kind of thing is support by PRs/MRs right now but I’d love to be wrong.

                I’d guess tooling beyond standard GitLab CI would be needed for larger scale rebuilds - if nothing else, I imagine you’d probably want to a bit more gating on the ability to burn that much CPU time. And perhaps those larger rebuilds are too interactive by nature…

              2. 4

                It’s weird that this is not mentioned in the Archlinux news, or on Planet Archlinux. I would love these to appear in my RSS feeds.

                1. 3

                  That’s a good point - it looks like there are some issues with the RSS feed right now. Once that’s fixed, it would be great if it showed up on Planet ArchLinux.

              1. 1

                I’ve finally pulled together everything for my blog, Muxup.com. See my post detailing some elements of the implementation (I know, creating a special snowflake static site generator and then writing about it is a bit of a meme at this point….). I imagine I’ll be doing more tweaks over the weekend. I’d really welcome any feedback or suggestions to tweak the design (I’m pretty pleased, but I’m no designer and it’s been a lot of trial and error).

                1. 4

                  To add to the comment about Helix vs Vim on large files - I’ve found Helix’s tree-sitter to be very slow for large markdown files https://github.com/helix-editor/helix/issues/3072#issuecomment-1207319836

                  1. 3

                    To be fair, Helix uses the same tree-sitter library for markdown that Neovim uses, the one from MDeiml. So I’d assume that if Helix is experiencing slowness while opening large markdown files, so will Neovim.

                    I’m sure tree-sitter has been a helpful tool for people but in my anecdotal experience, almost all the tree-sitter libraries I’ve used so far (HTML, CSS, shell scripts, markdown) are too buggy to be used as a daily driver.

                    1. 2

                      I’m sure tree-sitter has been a helpful tool for people but in my anecdotal experience, almost all the tree-sitter libraries I’ve used so far (HTML, CSS, shell scripts, markdown) are too buggy to be used as a daily driver.

                      I’ve also had this experience. It’s not that I can’t use them, but there’s weird inconsistencies. For example, tree-sitter’s TypeScript TSX highlights components normally, but highlights regular elements like <p /> the same color as imports (for me it’s red, in Solarized Light, whereas components are normally highlighted blue), which is really odd and makes no sense to me. So now my render functions in React look like some kind of weird American Flag Tribute (never forget in 4 days) to TypeScript.

                      In terms of a “daily driver”, I still use Vim plugins like vim-javascript and vim-json for highlighting, but tree-sitter has allowed me to remove a ton of syntax highlighting plugins that I just don’t need to have hanging around, which has been beneficial. But yeah, wouldn’t say it’s ready to replace your entire syntax highlighting stuff.

                      1. 1

                        tree-sitter’s TypeScript TSX highlights components normally, but highlights regular elements like the same color as imports

                        This is very likely to be an issue with your colorscheme and not with tree-sitter/the grammar. I would be very surprised to hear that tree-sitter/the grammar gives your editor the same tokens for these two very syntactically different constructs.

                    2. 2

                      That’s great feedback. Thanks for the link. I’ll test it.

                    1. 1

                      Off tomorrow for Brussels for a meetup with my work colleagues in the Igalia compilers team. Looking forward to meeting many of my co-workers in person for the first time.

                      1. 3

                        I’m talking at the first Cambridge RISC-V meetup later this week, so doing some work to prepare that.

                        On the WebAssembly side, I’m about to post an RFC on the approach to represent table types in C/C++ (as was requested on my current draft patch.

                        1. 4

                          Recovering from COVID :/ With a young child at nursery, I suppose the surprising thing is it’s taken so long to catch us.

                          1. 5

                            I’m starting at Igalia today. So a mixture of going through all their internal documentation and onboarding process, getting to know people, and hopefully starting to get up to speed on my first technical contributions (Clang/LLVM and WebAssembly).

                            1. 1

                              congrats! given wasm I assume some webkit work?

                              1. 2

                                I’m fairly focused on the toolchain side initially, but with so much JS engine work going on within the compilers team at Igalia, there should be opportunities to get involved there too later on.

                            1. 1

                              I’m gearing up to start a new job on Monday and now have account access. So now I’ve done an initial pass through the internal wiki+handbook, I’m fighting the urge to spend the rest of the weekend reading up on everything and trying to relax instead.

                              1. 7

                                I’ve just moved on from lowRISC, a not-for-profit in the open source silicon space I co-founded almost seven and a half years ago. I’ve got the next thing lined up, but have a bit of space in-between. So this week I’m mostly pottering about, updating the various scripts I use for personal time and task tracking, and thinking about spinning up a blog.

                                1. 6

                                  It’s also worth checking out the interactive table restyler on userchrome.org, which generates appropriate userChrome.css directives and shows a live preview based on the options you choose.

                                  1. 31

                                    That’s cool and all, but knowing Mozilla, an about:config option called “legacyUserProfileCustomizations” is gonna disappear.

                                    Related: In Firefox 90, they removed the “Compact” density option, which I kind of rely on to be comfortable with Firefox. They added an about:config option, “browser.compactmode.show”, to add it back. In Firefox 91, if you have the option enabled, they renamed the option from “Compact” to “Compact (not supported)”. I know it’s only a matter of time before they remove it entirely. And I’m kind of panicking about that, because I really, really don’t want more vertical space to be wasted by padding in the tab bar on small laptop screens. If anything, I find the “Compact” option too big. I wish Mozilla would stop changing things for the worse, and I wish Mozilla would stop taking away configuration options.

                                    1. 18

                                      What is wrong with them? Every major release, they’ve taken away functionality that I depend on.

                                      1. 12

                                        Every major release, they’ve taken away functionality that I depend on.

                                        I feel the same. I even often joke that Mozilla is spying on me with the sole goal of knowing what features I rely on and yanking them away from me :).

                                        What is wrong with them?

                                        Nothing is wrong with them. We just aren’t part of their main demographic target.

                                        1. 11

                                          I absolutely dread every single firefox update for the same reason - something I rely on or have burned in have and muscle memory get altered or removed.

                                          It feels completely hopeless to me as well because I can’t see another acceptable choice. I can’t support Google’s browser engine monopoly and every other browser I research has some other issue that makes me reject it in comparison.

                                          It feels like abuse by endless paper cuts, unwanted and unnecessary changes forced on me with no realistic choice to opt out. These changes seem to be accelerating too and meanwhile firefox market share declines further and further.

                                        2. 10

                                          That’s cool and all, but knowing Mozilla, an about:config option called “legacyUserProfileCustomizations” is gonna disappear.

                                          The reason it was made an option is to slightly improve startup time since it won’t have to check for this file on the disk. Comparatively few people use it, which is hardly surprising since it’s always been a very hidden feature, so it kind of makes sense: if you’re going to manually create CSS files then toggling an about:config option is little trouble.

                                          Apparently, the name “legacy” is in there “to avoid giving the impression that with this new preference we are adding a new customization feature”. I would be surprised if it was removed in the foreseeable future, because it’s actually not a lot of code/effort to support this.

                                          That being said, instead of relegating userChrome to a “hidden feature”, it would seem to me that properly integrating support for these kind of things in Firefox would give a lot more benefits. In many ways, almost everyone is a “power user” because a lot of folks – including non-technical people – spend entire days in the browser. For example, I disable the “close tab” button because I press it by accident somewhat frequently which is quite annoying. While loads of people don’t have this problem, I suspect I’m not the only person with this small annoyance considering some other browsers just offer this as a setting, but I am one of the comparatively small group of people who has the know-how to actually fix it in Firefox.

                                          The technical architecture to do a lot of these things is right there and actually works quite well; it just doesn’t fit in the “there is one UX to satisfy everyone, and if you don’t like it then there’s something wrong with you”-mentality 🤷

                                          1. 18

                                            All preference changes through about:config are officially unsupported and come with zero guarantees. This includes creating custom chrome folders.

                                            There actually is a maintenance and complexity cost for keeping these things alive. We’ve done a lot of hardening lately that was cumbersome to pull off in light of those customizations. In essence, we are disabling some protections when we detect profile hackery. I want to repeat: despite our team working around and “acknowledging” the existence of those hacks, they are still unsupported and we can’t promise to always work around custom profile quirks.

                                            The best way to be heard and change things in an open source project is to show up and help drive things. I know this isn’t easy for big project like ours…

                                            1. 4

                                              This used to be a longer comment but I edited it and now it only shows this note 😳. I was needlessly nasty. Sorry, man, rough day.

                                              1. 1

                                                No harm done 👍

                                              2. 2

                                                I, too, prefer the “Compact” theme. Is there still anything that can be done to keep it going forward?

                                              3. 2

                                                I’ve heard this startup time justification before, but surely the additional hassle of implementing, testing, and documenting a new configuration parameter isn’t worth saving a single stat call on startup? It’s hard to imagine that even shows up in the profile.

                                                1. 1

                                                  If everything else has already been tightly optimized, the stat call being performed on a spinning rust drive could be shown as being a major performance bottleneck when profiling startup performance.

                                                  1. 6

                                                    When I rebuild LLVM, ninja does a stat system call for every C++ source and header file on the disk, about 10,000 of them in total. If I have no changes, then it completes in so little time that it appears instantaneous.

                                                    If the cost of a stat system call is making a user-noticeable difference to start times, then you’re in an incredibly rare and happy place.

                                            1. 12

                                              Gitless has no staging area

                                              I frequently use git add -p to stage chunks of diffs, so that I can make separate commits of unrelated changes in a single file. I would miss that feature greatly.

                                              1. 9

                                                Gitless has a --partial flag that can be used to interactively select segments of a file to commit.

                                                1. 6

                                                  As durin42 mentioned elsewhere, hg gets arround this (without having a staging area) by having support for interactive commit selection with hg commit --interactive.

                                                  1. 3

                                                    For non-trivial changes, how do you know for sure that your code still compiles afterwards? Is this not a problem in practice?

                                                    1. 7

                                                      For non-trivial changes, I don’t know. But if it gets to the point where I have non-trivial changes in my working copy, I’ve already lost.

                                                      In my experience, a common pattern is:

                                                      • start editing some function
                                                      • realise this function would be easier/safer/simpler with a change to the helper function it’s based on.
                                                      • go off and edit the helper function, write some tests, make sure it’s solid
                                                      • come back and finish the outer function, to make sure that the changes to the helper function actually accomplish the thing I needed
                                                      • git add -p the changes to the helper function and the tests, which I’m confident can stand alone because the existing tests still pass, plus my new ones
                                                      • commit the changes to the outer function

                                                      …times as many stack-levels of yak-shaving as you can stand.

                                                      1. 1

                                                        Once you have made small commits, you can do an interactive rebase to build every version and make edits if necessary. With e.g. Gerrit and Jenkins you can automatically get feedback whether each commit builds/passes tests.

                                                        1. 1

                                                          You can use git stash -k to stash unstaged changes, run your compiler / test suite, and commit them if they all pass.

                                                        2. 1

                                                          I think I could make do with their --partial flag, but the lack of git rebase -i is a bit of a deal-breaker for me.

                                                        1. 3

                                                          I’ll agree that the push to Apache seems to be coming from a few unnamed corporates rather than “the LLVM community” as a whole. But Theo is being quite unfair with the assertion that proper signoff won’t be sought from contributors. As Chris Lattner says “Here we are discussing what the best end game is – not the logistics of how to get from here to there.”

                                                          Step 1: decide to investigate changing license

                                                          Step 2: decide what license to change to <– we are here

                                                          Step 3: decide a plan for getting sign-off from contributors on the licensing change, and dealing with missing contributors or those who do not want to support the license move (e.g. rewrite or revert the change)

                                                          Step 4: enact the plan

                                                          1. 1

                                                            From the outside, it does seem a bit odd to only talk about “where you want to get” (apparently in a years time it seems like the answer to this just ended up being “apache 2.0”) without considering how you would get there (or if you even can).

                                                            Overall it seems like kind of a bummer[1] though. I would think using a license to cover copyright, and a patent grant to cover patents, would be the clearest solution – apache 2.0 mixing the two always struck me (non-laywer) as a bit dubious. Further, a CLA seems like it would result in the least change (no new license), and would put the burden on corporate contributors – who are the ones raising the issue in the first place.

                                                            For example, doesn’t react (someone in the office who is familiar with it mentioned it as an example) use a BSD license with an explicit patent grant / CLA process?


                                                            [1]: I assume it would mean that clang would never be included as the default copiler in openbsd if it were apache-2.0?

                                                            1. 1

                                                              Yeah, I’d honestly be very surprised if they do manage to switch. There are ~700 contributors to llvm alone, and I’d be surprised if they could get them all to respond, let alone agree to a license change.

                                                              That said, it’d be quite a shame if it did happen. I’m super excited to see llvm + clang in OpenBSD.

                                                            1. 1

                                                              I’ve been through a lot of todo management tools (even wrote my own minimal solution) and I have to say my favourite todo tool is taskpaper.vim. It’s easy to overlook it as being just a syntax file for the taskpaper format, but actually the few keybindings it provides to mark tasks as done and archiving them are all you need. Key features it offers that are surprisingly hard to find elsewhere:

                                                              • Simple text-based format
                                                              • Ability to keep notes alongside a given task
                                                              • Ability to easily have different task lists for different projects
                                                              • Nested tasks
                                                              1. 3

                                                                I feel that having Cloudflare host a subset of DNS Linode servers would be great to add extra resiliency. Putting all DNS in the hands of an external provider and retiring Linode’s own servers seems a shame though.

                                                                1. 7

                                                                  Inspired by the weekly threads here on lobste.rs and in the Rust community, I’ve actually started a “What are you working on” thread on the lowRISC mailing list. lowRISC is our project to produce a completely open source System on Chip implementing the RISC-V architecture.

                                                                  Last week I was at DAC, talking to various vendors and delivering a section of the RISC-V tutorial. Our section made use of the untethered lowRISC release and associated documentation.

                                                                  Thanks to hard work from my colleague Wei, lowRISC contributor Stefan, and others we are now approaching the point where we can make a new code release including trace debug support. The previous untethered release still had support for the host-target interface (HTIF) in the kernel but had a small program to map the HTIF calls to underlying hardware peripherals (e.g. UART, SD card). This week, I want to look at ensuring we have a kernel that properly supports communicating with the platform peripherals directly.