1. 8

    I’ve never used go, but I have to agree that Rust is a very hard language to learn.

    For me the pain points were the size of the language (lots of commonly-used data structures: Box, RefCell, Cell, Rc, Arc, …), error handling and the borrow checker.

    Over time I’ve gotten used to it, but I totally sympathize with new users and sometimes I still get caught out.

    Switches must be exhaustive.

    I think that’s a good thing. You can always wimp out using the _ pattern if need be.

    It’s been a long time since I’ve had to think about actual memory management, so having to wrap everything in an Arc (and make sure it’s owned rather than borrowed) in order to make it work with async has been frustrating.

    It’s true that Rust forces you to think about memory, but on the other hand it does give you some control over the performance trade-offs. For example, Arc has reference counting overheads, which may or may not be acceptable, depending on what you are doing.

    I pretty much agree with al of the rest, although I have not used async much, so can’t comment on that.

    1. 67

      What should people use instead?

      Real secure messaging software. The standard and best answer here is Signal,

      Oh please. They aren’t even close to sharing the same level of functionality. If I want to use Signal, I have to commit to depending on essentially one person (moxie) who is hostile towards anyone who wants to fork his project, and who completely controls the server/infrastructure. And I’d have to severely limit the options I have for interfacing with this service (1 android app, 1 ios app, 1 electron [lol!] desktop app). None of those are problems/restrictions with email.

      I don’t know what the federated, encrypted ‘new’ email thing looks like, but it’s definitely not Signal. Signal is more a replacement for XMPP, if perhaps you wanted to restrict your freedom, give away a phone number, and rely on moxie.

      1. 14

        I think Matrix is getting closer to being a technically plausible email and IM replacement.

        The clients don’t do anything like html mail, but I don’t think I’d miss that much, and the message format doesn’t forbid it either.

        1. 27

          If you can’t send patches to mailing lists with them then they’re not alternatives to email. Email isn’t just IM-with-lag.

          1. 5

            Email can be exported as text and re-parsed by Perl or a different email client.

            Until that functionality is available, I won’t consider something a replacement for email.

            1. 4

              In all fairness: cmcaine says “Matrix is getting closer”.

              1. 3

                Matrix is a federated messaging platform, like XMPP or email. You could definitely support email-style use of the system it’s just that the current clients don’t support that. The protocol itself would be fine for email, mailing lists and git-send-email.

                The protocol also gives you the benefits of good end-to-end encryption support without faff, which is exactly what general email use and PGP don’t give you.

                1. 2

                  Adding patch workflow to Matrix is no different to adding it to XMPP or any other messaging solution. Yes, it is possible but why?

                  I can understand you like Matrix but it’s not clear how Matrix is getting closer to e-mail replacement with just one almost-stable server implementation and the spec that’s not an IETF standard. I’d say Matrix is more similar to “open Signal” than to e-mail.

                  1. 2

                    “Getting closer” is a statement towards the future, yet all of your counter arguments are about the current state.

                    1. 3

                      If I only knew the future I’d counter argument that but given that the future is unknown I can only extrapolate the current and the past. Otherwise Matrix may be “getting closer” to anything.

                      Do you have any signs that Matrix is getting e-mail patch workflow?

                2. 2

                  Mailing lists could move to federated chatrooms. They moved from Usenet before, and in some communities moved to forums before the now common use of Slack.

                  I’m not saying it would be the best solution, but it’s our most likely trajectory.

                  1. 6

                    Mailing lists existed in parallel with Usenet.

                    1. 5

                      Both still exist :)

                      I do think, actually, that converting most public mailing lists to newsgroups would have a few benefits:

                      1. It’d make their nature explicit.
                      2. It’d let us stop derailing designs for end-to-end encryption with concerns that really apply only to public mailing lists.
                      3. I could go back to reading them using tin.

                      Snark aside, I do think the newsgroup model is a better fit for most asynchronous group messaging than email is, and think it’s dramatically better than chat apps. Whether you read that to mean slack or any of the myriad superior alternatives to slack. But that ship sailed a long time ago.

                      1. 4

                        Mailing lists are more useful than Usenet. If nothing else, you have access control to the list.

                        1. 2

                          Correct, and the younger generation unfamiliar with Usenet gravitated towards mailing lists. The cycle repeats.

                        2. 4

                          Mailing lists don’t use slack and slack isn’t a mailing list. Slack is an instant messaging service. It has almost nothing in common with mailing lists.

                          It’s really important to drive this point home. People critical of email have a lot of good points. Anyone that has set up a mail server in the last few years knows what a pain it is. But you will not succeed in replacing something you don’t understand.

                          1. 4

                            The world has moved on from asynchronous communication for organizing around free software projects. It sucks, I know.

                            1. 3

                              Yeah. Not everyone, though.

                              Personally I think that GitHub’s culture is incredibly toxic. Only recently have there been tools added to allow repository owners to control discussions in their own issues and pull requests. Before that, if your issue got deep linked from Reddit you’d get hundreds of drive by comments saying all sorts of horrible and misinformed things.

                              I think we’re starting to see a push back from this GitHub/Slack culture at last back to open, federated protocols like SMTP and plain git. Time will tell. Certainly there’s nothing stopping a project from moving to {git,lists}.sr.ht, mirroring their repo on GitHub, and accepting patches via mailing list. Eventually people will realise that this means a lower volume of contributions but with a much higher signal to noise ratio, which is a trade-off some will be happy to make.

                              1. 2

                                Only recently have there been tools added to allow repository owners to control discussions in their own issues and pull requests. Before that, if your issue got deep linked from Reddit you’d get hundreds of drive by comments saying all sorts of horrible and misinformed things.

                                It’s not like you used to have levers for mailing lists, though, that would stop marc.org from archiving them or stop people from linking those marc.org (or kernel.org) threads. And drive-bys happened from that, too. I don’t think I’m disputing your larger point. Just saying that it’s really not related to the message transfer medium, at least as regards toxicity.

                                1. 3

                                  Sure, I totally agree with you! Drive-bys happen on any platform. The difference is that (at least until recently) on GitHub you had basically zero control. Most people aren’t going to sign up to a mailing list to send an email. The barrier to sending an email to a mailing list is higher than the barrier to leaving a comment on GitHub. That has advantages and disadvantages. Drive-by contributions and drive-by toxicity are both lessened. It’s a trade-off I think.

                                  1. 3

                                    I guess I wasn’t considering a mailing list subscription as being meaningfully different than registering for a github account. But if you’ve already got a github account, that makes sense as a lower barrier.

                      2. 5

                        Matrix allows sending in the clear, so I suppose this has the “eventually it will leak” property that the OP discussed?

                        (A separate issue: I gave up on Matrix because its e2e functionality was too hard to use with multiple clients)

                        1. 5

                          (A separate issue: I gave up on Matrix because its e2e functionality was too hard to use with multiple clients)

                          and across UA versions. When I still used it I got hit when I realized it derived the key using the browser user agent, so when OpenBSD changed how the browser presented itself I was suddenly not able to read old conversations :)

                          1. 2

                            Oh! I didn’t know that!

                      3. 5

                        Functionality is literally irrelevant, because the premise is that we’re talking about secure communications, in cases where the secrecy actually matters.

                        Of course if security doesn’t matter then Signal is a limited tool, you can communicate in Slack/a shared google doc or in a public Markdown document hosted on Cloudflare at that point.

                        Signal is the state of the art in secure communications, because even though the project is heavily driven by Moxie, you don’t actually need to trust him. The Signal protocol is open and it’s basically the only one on the planet that goes out of it’s way to minimize server-side information storage and metadata. The phone number requirement is also explicitly a good design choice in this case: as a consequence Signal does not store your contact graph - that is kept on your phone in your contact store. The alternative would be that either users can’t find each other (defeating the point of a secure messaging tool) or that Signal would have to store the contact graph of every user - which is a way more invasive step than learning your phone number.

                        1. 9

                          even though the project is heavily driven by Moxie, you don’t actually need to trust him

                          Of course you must trust Moxie. A lot of the Signal privacy features is that you trust them not to store certain data that they have access to. The protocol allows for the data not to be stored, but it gives no guarantees. Moxie also makes the only client you can use to communicate with his servers, and you can’t build them yourself, at least not without jumping hoops.

                          The phone number issue is what’s keeping me away from Signal. It’s viral, in that everyone who has Signal will start using Signal to communicate with me, since the app indicates that they can. That makes it difficult to get out of Signal when it becomes too popular. I know many people that cannot get rid of WhatsApp anymore, since they still need it for a small group, but cannot get rid of the larger group because their phone number is their ID, and you’re either on WhatsApp completely or you’re not. Signal is no different.

                          And how can you see that a phone number is able to receive your Signal messages? You have to ask the Signal server somehow, which means that Signal then is able to make the contact graph you’re telling me Signal doesn’t have. They can also add your non-Signal friends to the graph, since you ask about their numbers too. Maybe you’re right and Moxie does indeed not store this information, but you cannot know for sure.

                          What happens when Moxie ends up under a bus, and Signal is bought by Facebook/Google/Microsoft/Apple and they suddenly start storing all this metadata?

                          1. 5

                            Signal is a 501c3 non-profit foundation in the US, Moxie does not control it nor able to sell it. In theory every organization can turn evil but there is still a big difference between non-profits who are legally not allowed to do certain things vs corporations who are legally required to serve their shareholders, mostly by seeking to turn a profit.

                            And how can you see that a phone number is able to receive your Signal messages? You have to ask the Signal server somehow, which means that Signal then is able to make the contact graph you’re telling me Signal doesn’t have.

                            There are two points here that I’d like to make, one broader and one specific. In a general sense, Signal does not implement a feature until they can figure out how to do that securely and with leaking as little information as possible. This has been the pattern for basically almost every feature that Signal has. Specifically, phone numbers are the same: The Signal app just sends a cryptographically hashed, truncated version of phone numbers in your address book to the server, and the server responds with the list of hashes that are signal users. This means that Signal on the server side knows if any one person is a Signal user, but not their contact graph.

                            1. 3

                              In theory every organization can turn evil

                              Every organization can also be bought by an evil one. Facebook bought WhatsApp, remember?

                              The Signal app just sends a cryptographically hashed, truncated version of phone numbers in your address book

                              These truncated hashes can still be stored server-side, and be used to make graphs. With enough collected data, a lot of these truncated hashes can be reversed. Now I don’t think Signal currently stores this data, let alone do data analysis. But Facebook probably would, given the chance.

                              1. 6

                                Every organization can also be bought by an evil one. Facebook bought WhatsApp, remember?

                                WhatsApp was a for-profit company, 501(c)3 work under quite different conditions. Not saying they can’t be taken over, but this argument doesn’t cut it.

                          2. 3

                            The phone number requirement is also explicitly a good design choice

                            No, it’s an absolutely terrible choice, just like it is a terrible choice for ‘two factor authentication’

                            Oh but Signal users can always meet in person to re-verify keys, which would prevent any sim swap attack from working? No, this (overwhelmingly) doesn’t happen. In an era where lots of people change phones every ~1-2yr, it’s super easy to ignore the warning because 99% of the time it’s a false positive.

                            The alternative would be that either users can’t find each other (defeating the point of a secure messaging tool)

                            This is a solved problem. I mean, how do you think you got the phone numbers for your contacts in the first place? You probably asked them, and they probably gave it to you. Done.

                          3. -8

                            Careful there… you can’t say bad things about electron in here….

                          1. 29

                            for those people, encrypted email is LARP[0] security.

                            [0]: https://www.google.com/search?q=larp

                            Linking to a google search is both pedantic and unhelpful. Pedantic because it means that you care more about telling your readers “Why don’t you just figure it out” instead of providing the information directly (and you even took the extra time to make it a link!), and unhelpful because google search is now heavily impacted by previous user searches, localisation, etc…

                            For me, a french hobbyist using duckduckgo on a daily basis, LARP is an Algorithm and Problem solving software. I’m still not sure what the author mean here, but it definitely pissed me off.

                            1. 12

                              I thought about Live Action Role Playing, and interpreted LARP Security as a snobby way of saying “Security Theatre”. It’s not a term I would use myself.

                              1. 5

                                It’s probably just a setup for this zinger:

                                Users are encouraged to rotate their PGP keys in the same way that LARPers are encouraged to sharpen their play swords: not only does nobody do it, but the whole system would probably fall apart if everyone did.

                                1. 6

                                  Makes sense indeed. My point about linking to a google search rather than giving a real definition still stands though.

                                2. 3

                                  Phrases like that are one reason I suggested the “rant” tag for this post. It comes across as pretty hostile to me.

                                  1. 1

                                    I wasn’t sure what the author meant by this either.

                                  1. 46

                                    The link displayed in the bottom of the web browser window, when you hover over the link, can not be trusted.

                                    Google has been doing it for ages. You can reproduce it on Firefox: Just search for something on Google, then hover over the link. The link will say it goes directly to the website. Then right click the link and dismiss the menu. Now hover over it again. The link has changed to a Google tracker URL. It’s shady and it’s not okay, and in my eyes, it is a UI bug / exploit that needs to be fixed in the browsers. Links shouldn’t change right under your nose.

                                    1. 10

                                      This is a feature that all browsers had for ages: “Disable Javascript”.
                                      The whole concept of running arbitrary code on client side is a feature, and it means that you can run any arbitrary code on client side. The browser has no way of knowing which snippet is good or bad.
                                      You can argue that this specific case is obviously malicious, and should be treated explicitly, but you would have two major issues:

                                      1. You cannot treat this without breaking something else (changing href attribute is a valid usage)
                                      2. You will soon have to treat billions of other “malicious cases” (changing content based on user-agent, hiding content, …)

                                      And anyway, people will find a way to break through, for example by making calls to an analysis website on load, or event replace the current page with the target link passed through an analysis website.

                                      The only safe way to counter this is to disable javascript, or at least, ask the user for the right to run it (though this will only get in the way…).

                                      1. 2

                                        But the browser could kill the whole pattern by changing the order of execution. Currently execution flow looks like

                                        1. Detect click from operating system
                                        2. Run javascript
                                        3. If click is on a href, go to link

                                        Just change the order of 2 and 3. The browser controls the javascript vm. There is no reason it needs to let it run between detecting the click and checking for href’s.

                                        Legitimate patterns that need the onclick to run before going to a link can still work, they just need to follow the link in js instead of doing it through the href element, which will avoid the browser displaying the contents of the false original link at the bottom of the page.

                                        1. 3

                                          Running the code after following the link means giving the priority to the element themselves rather than the code. That would indeed fix the issue for “malicious” links, but it would kill a whole lot of other (legitimate) stuff.

                                          Take as an example someone filling a form, and submitting it from a link. The onClick event can be used to check user input before submitting anything, and cancel the submission if, eg. one field is not filled, or incorrect.
                                          By running the JS after following the link, you simply prevent the process. And I can barely imagine a (valid!) use-case with onClick that would work as intended if the code is run after the link is followed.

                                          1. 1

                                            For forms, the url isn’t displayed by the browser so this change isn’t needed.

                                            But, let’s pretend that it was so we can use your example. The “fix” for making on-click continue to be useful would be as simple as removing the url from the html attribute, and instead passing it to the javascript, then the javascript could load the url (or send the post request) after validating the input. The only difference here is the url isn’t part of the element, so the browser doesn’t display it.

                                      2. 4

                                        You find this out the hard way when you want to simply copy a link from google, only to paste a load of tracking horseshit

                                        1. 3

                                          First, I agree with what you said, that this is not OK.

                                          But how would you fix this in a way that doesn’t break legitimate uses of onClick?

                                          1. 3

                                            Interestingly, there exists a ping attribute on the a element, which would facilitate click tracking without sneakily changing the link with JavaScript. Google uses it on their search results, but only if you’re using Chrome. On Firefox, it appears to use <a onmousedown> instead, which would be responsible for the swap. The ping attribute is supported on Firefox, but it’s not enabled by default. It is on Chrome, though. Hmm.

                                        1. 8

                                          No joke, I’m terrified that some major player in online music like Spotify, CD Baby, or Bandcamp will go out of business, and that thousands of bands will instantly vanish as if they never existed.

                                          I was foolishly ready to just go all-in on Spotify, until one day Dashboard Confessional’s entire back catalog vanished, with no explanation. That music was foundational to my childhood! Not being able to listen to it was completely unacceptable. It eventually returned, still with no explanation, but my trust did not. It’s one thing if a band never makes it onto Spotify for some reason, like Tool was missing for years, but it’s quite another thing when e.g. Lizzo’s early songs disappear without a trace from my playlists that I’ve carefully curated. Why can’t you listen to early Lizzo? It’s not like she’s unpopular! Where is Batches & Cookies? What do I do with this hole in my mix?

                                          Now I’m trying to back up all of my old CDs before they expire: https://www.vice.com/en_us/article/mg9pdv/the-hidden-phenomenon-that-could-ruin-your-old-discs Unfortunately, some of them already have scratches. I was trying to back up some of my LPs too, but that was much more of a chore and the recordings didn’t turn out that great.

                                          I’m trying to buy copies of the new music I care about, but it’s getting hard these days. Big names don’t have their music on Bandcamp, and there aren’t many other options for buying lossless files (which I insist upon, since preservation is my goal). Sometimes it’s still possible to buy CDs, but small bands don’t print them because the economics don’t make sense anymore. My insignificant band made the mistake of printing 1000 CDs in 2010, since that was the minimum amount to get a reasonable price on “real CDs”, and the odds that we ever sell them all is essentially zero. A run of 100 CD-Rs is doable, but those aren’t nearly as durable as pressed CDs, so why bother, if longevity is a priority?

                                          People need to own the books, music and other art that is an important part of their inner lives.

                                          1. 3

                                            No joke, I’m terrified that some major player in online music like Spotify, CD Baby, or Bandcamp will go out of business, and that thousands of bands will instantly vanish as if they never existed.

                                            A key point here is that Bandcamp at least sells you the totally unencumbered bits in whatever format you want. I download all my purchases in lossless. BIG fan of that platform.

                                            If they ever go away, you at least don’t lose the music you’ve already bought!

                                            1. 3

                                              Big names don’t have their music on Bandcamp

                                              This is mostly true, but I was delighted recently to realize that Death Cab for Cutie is on there. Some of the older Decemberists albums, too. If you’re looking for a big-name band, it’s a reasonable assumption that they aren’t on Bandcamp, but it never hurts to check.

                                              1. 2

                                                I think more and more artists are starting to see the benefits of Bandcamp.

                                              2. 2

                                                one day Dashboard Confessional’s entire back catalog vanished, with no explanation. That music was foundational to my childhood! Not being able to listen to it was completely unacceptable. It eventually returned, still with no explanation, but my trust did not. It’s one thing if a band never makes it onto Spotify for some reason, like Tool was missing for years, but it’s quite another thing when e.g. Lizzo’s early songs disappear without a trace from my playlists that I’ve carefully curated. Why can’t you listen to early Lizzo? It’s not like she’s unpopular! Where is Batches & Cookies? What do I do with this hole in my mix?

                                                It’s no consolation, but the internet is on position that songs disappearing from streaming services are only fault of the record companies that upload them in the first place.

                                                1. 3

                                                  But there’s no transparency! There’s no changelog of “Oh yeah, here we had to take down old Lizzo songs b/c her previous record company hates her now, but they’ll be back once her old contract runs out.” It could be the record company, or it could be technical difficulties, or it could be Lizzo doesn’t like the way she used to sound and doesn’t want you to hear her old stuff. It’s a total mystery. I think that bothers me at least as much as the music disappearing.

                                                  1. 2

                                                    It’s no consolation, but the internet is on position that songs disappearing from streaming services are only fault of the record companies that upload them in the first place.

                                                    Very true. Don’t kill the messenger and get angry at the streaming service, BUT it still does highlight the fact that music you care about could easily sink beneath the waves and become inaccessible to you.

                                                    So the question then is “How much do you care?”

                                                    For a lot of people the answer is “Not enough” but for some of us it’s worth the few hundred dollars and man days to fix the problem in a sustainable way.

                                                1. 1

                                                  I’ve started buying used CDs (and DVDs) for these same reasons. I have enough storage in my laptop to carry everything with me, but I’ve wanted a phone solution, are there similar apps for Android?

                                                  1. 3

                                                    I use an Android music player called Odyssey. It’s not quite the same thing as the iOS app in the article, because it doesn’t automatically sync music from cloud services, but because it’s Android you can just have a bunch of music on your SD card — stick the card in your PC’s SD card reader, or connect the phone to your PC via USB, or sync music over the network with something like Dropbox or SyncThing.

                                                    1. 1

                                                      Most android music players will offer up anything the music indexer finds on the internal storage or SD card. They just may take a while to appear.

                                                    1. 2

                                                      This workflow is quite similar to my own, just with an android phone instead of an iPhone.

                                                      I also second that Bandcamp is superb.

                                                      1. 3

                                                        My old X series tablet used to do this and various other ghosting. I think it was an X270T.

                                                        1. 1

                                                          My current Thinkpad X1 5th gen is not affected by the way.

                                                        1. 2

                                                          I’d like to try something like this out… is there a vim ‘theme’ that demonstrates the ‘color free editor setup’?

                                                            1. 2

                                                              It might be his vim-colors-plain theme:

                                                              https://github.com/nerdypepper/vim-colors-plain

                                                              1. 2
                                                                1. 2
                                                                  1. 1

                                                                    to add to some of the others

                                                                    Though I use vim-colors-plain. I’ve really enjoyed it.

                                                                    1. 1

                                                                      I wrote this for myself: everything is yellow, strings are red, comments are grey.

                                                                      I remember when I started dipping into that idea – a veteran programmer ridiculed the idea of syntax highlighting. “I know what my language does, I don’t need training wheels for my editor!”

                                                                      “What a ridiculous idea!” I thought. “Of course it’s better and easier with colours. I’ll try without them for some time just to make sure he’s wrong.” Fast forward a few weeks… he wasn’t really wrong. I’m not convinced syntax highlighting really does anything for clarity and ease of working with code. Syntax is usually instantly recognizable from the code layout alone.

                                                                      What I’d really like to see is an editor that can highlight stuff that make semantic sense, or are meaningful in runtime. Make my slow code red and fast code green, like a highlighting code profiler, for example. Find the code not covered by unit tests and turn it red. Highlight the variable that was written to, but never read in the last 20 runs, stuff like that.

                                                                      I can recognize syntax of my “native” programming language just fine – it’s the subtle semantics that elude me.

                                                                      1. 0
                                                                        :syntax off
                                                                        

                                                                        It disables syntax highlighting.

                                                                        1. 2

                                                                          Well, sure, but the example in the article doesn’t have all coloring disabled: https://files.nerdypepper.tech/bF.png

                                                                          1. 3

                                                                            By chance I’ve been doing almost exactly the same as the OP has with my Vim colours. I just can’t stand rainbow vomit in my editor.

                                                                            I use it with an xterm using solarized colours.

                                                                            As you can see, it’s not really release-ready.

                                                                            (The copyright comment is that of the theme template I started with).

                                                                            1. 1
                                                                        1. 1

                                                                          I looked into this device a couple of years back. I needed a way to take notes and read papers.

                                                                          Long story short: it’s too expensive. Even after the initial purchase, you still have to buy replacement nibs for the stylus. I was also worried about the software bit-rotting: I had no idea if the manufacturers would keep up with security patches.

                                                                          I ended up getting an Amazon fire HD 10 for reading, and a Rocketbook Everlast for note taking.

                                                                          Together, these were about a third of the price of the reMarkable tablet. Admittedly, I do have to refill the Frixion pen for the Rocketbook, but still…

                                                                          If anyone is thinking about doing the same, I highly recommend the Xodo android app for annotating PDFs. I also tried a few different styli for the Fire, but ended up finding it easier to use a finger.

                                                                          1. 7

                                                                            Rust is indeed fun!

                                                                            But:

                                                                            I also like this “barebones” feel I felt and loved with C

                                                                            I can’t really agree with that. Rust is a pretty big language compared to C.

                                                                            1. 2

                                                                              It is bigger, and has some higher-level features, but at the same time it still keeps all the good low-level aspects, e.g. you can micromanage every allocation and every byte of memory you use, if you want to.

                                                                              Generics add a lot to the language surface, but when I don’t need to worry about goto cleanup; I have some brain cycles to spare.

                                                                              C feels small in number of features, but actual productive work in C requires knowing plenty of things “between the lines”, like all the places where you can cause UB, macro hacks and footguns. You still have memory management (ownership), thread safety, but without type system helping.

                                                                              1. 2

                                                                                I think you and the above poster are talking about two different things.

                                                                                The above poster is referring to the sheer amount of content in Rust. It is not “barebones”: the language spec, the compiler and its capabilities, and the ecosystem are all very robust and sizeable.

                                                                                You are referring to low-level, or “bare metal” as some would call it. Yes, Rust can get close “to the metal” but the language is not barebones.

                                                                                1. 1

                                                                                  The above poster is simply misconstruing a point in the article in order to make their own point. I don’t think anybody would contend that Rust is somehow a minimalist’s language a la Scheme or Go.

                                                                                  1. 1

                                                                                    To clarify my position, there’s no doubt that Rust is a more productive language than C, but I wouldn’t call Rust a bare-bones language either.

                                                                                    Sure you don’t have to use all the language features and libraries, but that doesn’t make it barebones as a unit.

                                                                                    1. 1

                                                                                      I also like this “barebones” feel

                                                                                      You literally disagreed with the author feeling something

                                                                            1. 18

                                                                              I’ve worked on an open source project. Not so tiny, it used to be preinstalled with several major distros, and is still quite popular.

                                                                              Early 2018 we had a major CVE, with remote code execution. We had a patch ready within of 8 hours of discovery, had it tested and in our official releases within of a few days.

                                                                              Debian took over a month to patch it (and continued using an old version with major bugs, only patching security issues themselves). And they were the fastest. Alpine 3.7 was the first to ship the fix, and that took an eternity. Previous alpine versions (at the time still officially supported) never got the patch.

                                                                              Now, we’re moving towards snap/flatpak for desktop and docker for server, and building our own packages and bundles, because distro maintainers are basically useless, always ship ancient broken versions, users come to us to complain about stuff being broken (and distros refuse to ship bugfixes or versions from this decade), and the maintainers are never reachable, and even security updates are shipped at glacial speed.

                                                                              Honestly, distro maintainers are a massive security risk, and after this experience, I’m kinda mind blown.

                                                                              1. 9

                                                                                As an Arch packager, I can’t help but feel a little bit offended by what you said there. >:(

                                                                                1. 11

                                                                                  Arch is actually one of the few distrso where this issue never existed - but that’s because arch, being rolling release, actually just uses our upstream sources, and updates frequently and reliably.

                                                                                2. 7

                                                                                  because distro maintainers are basically useless

                                                                                  That’s quite an offensive statement.

                                                                                  1. 6

                                                                                    If major software that’s preinstalled and in the default start menu of Kubuntu is so outdated that it has remotely exploitable bugs, months after developers have released patches for all version branches, including the one used by Debian/Ubuntu/etc, then how can you really trust the packages installed on your system?

                                                                                    How many programs from the repos do you have installed which are not that common, or complicated to package. Are you sure they’re actually up to date? Are you sure there are no vulnerabilities in them?

                                                                                    Ever after this, I can’t trust distros anymore.

                                                                                    1. 3

                                                                                      And that makes distro maintainers basically useless?

                                                                                      1. 8

                                                                                        Yes. If there’s no practical value add, that statement is true.

                                                                                        It’s harsh to take, but yes, it’s okay to ask groups that insist on their status - especially in a role prone to gatekeeping - to stand for their value.

                                                                                        1. 3

                                                                                          If you can’t trust software distributed by your distro to be up-to-date and safe, what use does it have then? Stability is never more important than safety.

                                                                                          The whole point people use distributions, and especially reputable ones, is because they want to ensure (a) stuff doesn’t break, and (b) stuff is secure.

                                                                                          1. 2

                                                                                            If you can’t trust software distributed by your distro to be up-to-date and safe, what use does it have then?

                                                                                            Of course packagers try to keep stuff up to date and secure, but a) things move fast, and spare time and motivation can be at a premium; and b) there’s too much code to audit for security holes.

                                                                                            distro maintainers are basically useless

                                                                                            Come on now… I assure you, you’d be pretty upset if you had to build everything from source.

                                                                                            1. 4

                                                                                              Of course packagers try to keep stuff up to date and secure, but a) things move fast, and spare time and motivation can be at a premium; and b) there’s too much code to audit for security holes.

                                                                                              And this is where @arp242’s sentiment comes from. “In a world where there is a serious shortage of volunteers to do all of this, it seems to me that a small army of ‘packagers’ all doing duplicate work is perhaps not necessarily the best way to distribute the available manpower.”

                                                                                              1. 1

                                                                                                In a world where there is a serious shortage of volunteers

                                                                                                This is false. All too often it is difficult to find good software to package. A lot of software out there is either poorly maintained, or insecure, or painful to package due to bundled dependencies, or has hostile upstreams, or it’s just not very useful.

                                                                                                It’s also false to imply that all package maintainers are volunteers. There are many paid contributors.

                                                                                              2. 2

                                                                                                Come on now… I assure you, you’d be pretty upset if you had to build everything from source.

                                                                                                I don’t necessarily have to — the distro can provide a clean base with clean APIs, and developers can package their own packages for the distro. As some operating systems already handle it.

                                                                                      2. 3

                                                                                        Various distributions, including Debian, backport security fixes to to stable versions even when upstream developers don’t do it. It’s not uncommon that the security fixes are released faster than upstream.

                                                                                        Your case is an exception. Sometimes this can be due to applications difficult to package or difficult to patch or low on popularity.

                                                                                        Besides, it’s incorrect to assume that the package mantainer is the only person doing security updates. Most well-known distributions have dedicated security teams that track CVEs and chase the bugs.

                                                                                        1. 1

                                                                                          We already provide backported security fixes, as .patch simply usable with git apply, and provide our own packages for old and recent branches. It’s quite simple to package too. Popularity, well, it was one of the preinstalles programs on Kubuntu, and is in Kubuntus start menu (not anymore recently, but on older versions it still is).

                                                                                          The fact that many distro maintainers still take an eternity updating patches, and sometimes not even apply those, makes relying on distro packages quite an issue. I don’t trust distro maintainers anymore, not after this.

                                                                                        2. 3

                                                                                          Honestly, distro maintainers are a massive security risk, and after this experience, I’m kinda mind blown.

                                                                                          I think this is mostly because you have a one-sided experience of this and it’s most likely a bit more nuanced and down to several factors.

                                                                                          One of them being that the CVE system is broken and hard to follow. How did you disclose and announce the CVE and fix? Did the patches need backports for the given release and where those provided? I don’t know the CVE number, so this is hard to followup on. But the best approach is to announce on a place like oss-sec from open-wall and it should be picked up by all distribution security teams.

                                                                                          The other side of this, which is what distribution maintainer see, but few upstreams realize, is patching dependencies is where most of the work is done. Distributing your app as a snap/flatpak works great if you also patch the dependencies and keep track of security issues with those dependencies. This is where most upstreams fails, and this is where distribution maintainers and the distro security teams improve the situation.

                                                                                          1. 1

                                                                                            The other side of this, which is what distribution maintainer see, but few upstreams realize, is patching dependencies is where most of the work is done. Distributing your app as a snap/flatpak works great if you also patch the dependencies and keep track of security issues with those dependencies

                                                                                            That’s why, if you ever build such images yourself, you need to automate it, have it as CI, and update those dependencies at least daily, and generate a new image whenever new dependencies are available. Obviously, you need automated tests in your build procedure to ensure everything still works together, as sometimes some dependencies break important stuff even in patch releases.

                                                                                            How did you disclose and announce the CVE and fix? Did the patches need backports for the given release and where those provided

                                                                                            We provided patches for every version distros used, as nice patch files that could directly be applied with git apply, and in addition to the more common ways, we also directly contacted the package maintainers for our package for the important distros via email or instant messaging.

                                                                                            In general, personally, I’m not a fan of the stable model anyway, though. We’ve done great work to ensure the software stays 100% binary compatible for all its protocols since 2009, we support every supported version of debian and ubuntu even with our absolutely newest builds, and yet, in the end, it’s the distro maintainers shipping not only outdated versions (apparently some users prefer buggy old versions), but also take time to apply security fixes.

                                                                                            1. 2

                                                                                              That’s why, if you ever build such images yourself, you need to automate it, have it as CI, and update those dependencies at least daily, and generate a new image whenever new dependencies are available. Obviously, you need automated tests in your build procedure to ensure everything still works together, as sometimes some dependencies break important stuff even in patch releases.

                                                                                              Which again, few upstream do this, and they surely do not keep an eye on this at all. You sounds like a competent upstream and it’s nice when you encounter them :)

                                                                                              We provided patches for every version distros used, as nice patch files that could directly be applied with git apply, and in addition to the more common ways, we also directly contacted the package maintainers for our package for the important distros via email or instant messaging.

                                                                                              And this is how you should proceed. I would however contact the linux distro list if it’s a widely used piece of software multiple distributions package, and the CVE is critical enough. https://oss-security.openwall.org/wiki/mailing-lists/distros

                                                                                              In general, personally, I’m not a fan of the stable model anyway, though. We’ve done great work to ensure the software stays 100% binary compatible for all its protocols since 2009, we support every supported version of debian and ubuntu even with our absolutely newest builds, and yet, in the end, it’s the distro maintainers shipping not only outdated versions (apparently some users prefer buggy old versions), but also take time to apply security fixes.

                                                                                              The work is appreciated, but I’ll still urge you to not let one bad experience ruin the whole ordeal. Distribution security teams is probably one of the least resourceful teams and sometimes things do fall between two chairs.

                                                                                              1. 3

                                                                                                The work is appreciated, but I’ll still urge you to not let one bad experience ruin the whole ordeal. Distribution security teams is probably one of the least resourceful teams and sometimes things do fall between two chairs.

                                                                                                But given that the main argument of distros is security, that statement flies directly in the face of their promises.

                                                                                                1. 2

                                                                                                  But given that the main argument of distros is security, that statement flies directly in the face of their promises.

                                                                                                  I don’t think it’s the main argument, but surely one them. If you want to be completely covered you need a well paid team able to respond. You wont get this with community based distribution, we are unpaid volunteers, just like most upstreams. You’ll have to use something backed by a paid team if you expect premium service and full coverage.

                                                                                                  Anything else is only on a best effort basis. The CVE system is sadly hard to navigate, ingest and process. Some things are going to bubble up faster, and something is going to be missed.

                                                                                                  1. 2

                                                                                                    I have absolutely no issue with all your statements, but it is a cornerstone argument.

                                                                                                    I’m fine with community distributions, if they own it, and agree that paid distros are a good way to go. RHEL licenses are actually worth their money.

                                                                                                    I disagree with the reading of best-effort, though, because it goes both ways. If your work is impacting others, either through making them have more support requests or slowing down their iteration speed, you need to make sure you don’t add undue labor.

                                                                                          2. 3

                                                                                            With this attitude, which a lot of developers seem to have nowadays, it doesn’t make sense to have your software included in distributions. As a packager I’d call this a hostile upstream… Just distribute it as a flatpak and/or snap and be done with it.

                                                                                            Relevant here may be a blog post from an upstream fully embracing the distribution instead of fighting it: https://www.enricozini.org/blog/2014/debian/debops/

                                                                                            1. 3

                                                                                              It allows me to rely on Debian for security updates, so I don’t have to track upstream activity for each one of the building blocks of the systems I deploy.

                                                                                              That’s exactly what I used to believe in, too, but after this experience, the facade has cracked. I can deal with 90% of my packages being years out of date and full of bugs because the distro wants to be stable and refuses to apply bugfixes or update to newer versions, but if security updates aren’t reliably applied even if they have a CVE (and debian just ignores issues entirely if they have no CVE), then how can one still trust the distro for security updates? Having a remotely exploitable unauthenticated DoS if not even RCE in a publicly facing software for 30 days is absolutely not fine.

                                                                                              As a packager I’d call this a hostile upstream… Just distribute it as a flatpak and/or snap and be done with it.

                                                                                              We actively maintain all version branches, and provide even backported security patches as nice little .patch file even for all the major.minor.patch releases debian/ubuntu still use. You can build it nice and simple, you just have to apply one little patch. It’s not like this we’ve been actively hostile - what more should we have done, in your opinion?

                                                                                              1. 2

                                                                                                how can one still trust the distro for security updates?

                                                                                                Fair enough. If they are not applied. I personally know at least one Debian package maintainer (not me, I don’t like Debian) that takes excellent care of their packages, including in the stable releases. So it may depend on the maintainer. But maybe that is your point, that there is no universal standard for maintainers…

                                                                                                what more should we have done, in your opinion?

                                                                                                I don’t know this specific case. There are a number of other ‘historical’ cases where packagers gave up on packaging ‘upstream’ software, e.g. https://www.happyassassin.net/2015/08/29/looking-for-new-maintainer-for-fedora-epel-owncloud-packages/. I also wrote a blog post about it in 2016: https://www.tuxed.net/fkooman/blog/owncloud_distributions.html I guess the best one can do is follow these discussions and if possible make it easier for distributions to package the software. Especially the ownCloud case back then bugged me a lot. But as you can see from some other people in those discussions, we just gave up on ownCloud and used something else instead…

                                                                                          1. 2

                                                                                            The difference in trust between managed software repositories like Debian, Alpine Linux, Fedora, and so on; and unmanaged software repositories like PyPI, npm, Chrome extensions, the Google Play store, Flatpak, etc — is starkly obvious. Debian and its peers are full of quality software which integrates well into the host system and is free of malware. Unmanaged repositories, however, are constant sources for crapware and malware.

                                                                                            Interesting. I’d never made the distinction between managed unmanaged repos before.

                                                                                            Obviously a managed repo is preferred, but as he says, you need a dedicated team of (usually unpaid) porters on-hand to create and maintain binary packages. Not to mention the additional infrastructure. Whereas the unmanaged repos are effectively crowd-sourced…

                                                                                            Food for thought.

                                                                                            1. 1

                                                                                              I use one called poole. It seems to be unmaintained though: https://bitbucket.org/obensonne/poole/pull-requests/

                                                                                              I recently raised a PR to fix some Python3 stuff, but it has just sat there…

                                                                                              1. 3

                                                                                                Are there any alternative clients without Javascript?

                                                                                                1. 3

                                                                                                  It seems like this is just an email client, so you could presumably use any email client?

                                                                                                  1. 2

                                                                                                    Yes, this is the whole point. It’s an e-mail client that has UI affordances for instant messaging.

                                                                                                1. 2

                                                                                                  I have a system that I use in a Rocketbook Everlast. My system takes (what I believe to be) the best parts of Bullet Journal, but cans the parts I find inefficient and unnecessary.

                                                                                                  • Each week I split a page into three sections:

                                                                                                    • Work
                                                                                                    • BSD
                                                                                                    • Personal
                                                                                                  • Each section uses the bullet system similar to bullet journal:

                                                                                                    • . for a task.
                                                                                                    • o for an event
                                                                                                    • Add an additional * for emphasis (to prioritise).
                                                                                                    • / a . to indicate you started the task.
                                                                                                    • Convert a task or event to a x when the task or event is done
                                                                                                    • At any time you can strike out a line to cancel it.
                                                                                                  • At the beginning of a week, I review the previous week’s page and either:

                                                                                                    • Strike out a task that isn’t worth my time any more.
                                                                                                    • > (triangle) a task I’m going to carry forward to the current week (in bullet journal they call that migration).
                                                                                                  • Then I use the Rocketbook app to scan the page, pull the scan up on my computer and copy the migrated tasks onto a new week’s page.

                                                                                                  I also have a ribbon tied to the notepad for quick access to the current week’s page. This is particularly useful for a Rocketbook Everlast, which is effectively a ring buffer.

                                                                                                  I’ve used this system for about 6 months so far. I find the Monday morning ritual of reviewing my progress and adjusting my priorities to be a good way of getting my head in the right mode for the coming week. The review takes about 5-10 minutes.

                                                                                                  I found bullet journal to be too regimented for my taste, and setting up the journal looks like it takes an age. Also I want my notebook to be a place where I can scribble unstructured notes, trees, graphs and diagrams etc. With my system any blank page can be used for those kinds of notes, and planning only takes up a page here and there between other notes.

                                                                                                  1. -1

                                                                                                    I’ve been meaning to delete my keybase account for some time now. I don’t use it, and last time I tried to, it wanted to add a uid to my keys, which I didn’t want.

                                                                                                    1. 45

                                                                                                      RustTL;DR: It’s a very impressive language with a clear vision and priorities, but the user interface needs a lot of work. Also, the collection library is much better than Scala’s.

                                                                                                      • Generics with <>. It’s 2017 by now, we know it’s a bad idea. One of the reasons why the language suffers from abominations like the “turbofish” operator ::<>.

                                                                                                      • Strings don’t offer indexing, because it doesn’t make sense for UTF-8. Correct! But Strings offer slicing … WAT?

                                                                                                      • Misuse of [] for indexed access. Having both () and [] doing roughly the same thing, especially since [] can be used to do arbitrary things, doesn’t make sense. Pick one, use the other for generics.

                                                                                                      • Inconsistent naming. str and String, Path and PathBuf etc.

                                                                                                      • :: vs. . is kind of unnecessary.

                                                                                                      • Mandatory semicola, but with some exceptions in arbitrary places: struct Foo; vs. struct Foo {}

                                                                                                      • Arbitrary abbreviations all over the place. It’s 2017, your computer won’t run out of memory just because your compiler’s symbol table stores Buffer instead of Buf.

                                                                                                      • Can someone decide on a casing rule for types, please, instead of mixing lowercase and uppercase names? Some types being “primitive” is an incredibly poor excuse.

                                                                                                      • Also, having both CamelCase and methods_with_underscores?

                                                                                                      • Library stutter: std::option::Option, std::result::Result, std::default::Default

                                                                                                      • iter(), iter_mut(), into_iter() … decide prefix or postfix style and stick with it.

                                                                                                      • Coercions do too many things. For instance, they are the default way to convert i32 to i64, instead of just using methods.

                                                                                                      • Also, converting numbers is still broken. For instance, f32 to i32 might result in either an undefined value or undefined behavior. (Forgotten which one it is.)

                                                                                                      • Bitcasting integers to floats is unsafe, because the bits could be a signaling NaN, causing the CPU to raise an FP exception if not disabled.

                                                                                                      • Forward and backward annotations: #[foo] struct Foo {} vs struct Foo { #![foo] }. Also /// for normal documentation, //! for module level documentation. Documentation already uses Markdown, so maybe just let people drop a markdown file in the module dir? That would make documentation much more accessible when browsing through GitHub repositories.

                                                                                                      • Also, documentation can cause compiler errors … that’s especially fun if you just commented a piece of code for testing/prototyping.

                                                                                                      • Type alias misuse: In e.g. io crate: type Result<T> = Result<T, io::Error> … just call it IoResult.

                                                                                                      • Macros are not very good. They are over-used due to the fact that Rust lacks varargs and abused due to the fact that they require special syntax at call-site (some_macro!()).

                                                                                                      • Pattern matching in macros is also weird. x binds some match to a name in “normal” pattern matching, but matches on a literal “x” in “macro pattern matching”.

                                                                                                      • println! and format! are very disappointing given that they use macros.

                                                                                                      • Compiler errors … ugh. So many things. Pet peeve: “Compilation failed due to 2 errors” … 87 compiler errors printed before that.

                                                                                                      1. 8
                                                                                                        • Library stutter: std::option::Option, std::result::Result, std::default::Default
                                                                                                        • Type alias misuse: In e.g. io crate: type Result<T> = Result<T, io::Error> … just call it IoResult.

                                                                                                        How ya gonna square that circle?

                                                                                                        1. 2

                                                                                                          I think std::io::IoResult would be fine – it would solve the issue of having vastly different Results flying around, while not having single-use namespaces that are only used by one type.

                                                                                                          1. 2

                                                                                                            The general pattern is to import Io instead. When doing this, IoResult would be jarring.

                                                                                                            use std::io;
                                                                                                            
                                                                                                            fn my_fun() -> io::Result<T> {
                                                                                                            
                                                                                                            }
                                                                                                            
                                                                                                        2. 14

                                                                                                          It’s 2017,

                                                                                                          I have some news for you, @soc.

                                                                                                          1. 3

                                                                                                            Haha, good catch. Now you see how old this list is. :-)

                                                                                                            The only thing I got to delete since then was “get rid of extern crate”.

                                                                                                          2. 3

                                                                                                            What’s your preferred alternative to generics with <>?

                                                                                                            1. 6

                                                                                                              [], as it was in Rust before it was changed for “familiarity”.

                                                                                                              Unlike <>, [] has a track of not being horribly broken in every language that tried to use it.

                                                                                                              1. 5

                                                                                                                How is <> broken?

                                                                                                                1. 16

                                                                                                                  It complicates parsing due to shift and comparison operators.

                                                                                                                  1. 2

                                                                                                                    Ah, yeah, that makes sense.

                                                                                                                  2. 19

                                                                                                                    Pretty much no language has ever managed to parse <> without making the language worse. The flaws are inherent in its design, as a compiler author you can only pick where you place the badness; either:

                                                                                                                    • Add additional syntax to disambiguate (like ::<> vs. <> in Rust).
                                                                                                                    • Have weird syntax to disambiguate (like instance.<Foo>method(arg1, arg2) in Java).
                                                                                                                    • Read a potentially unlimited amount of tokens during parsing, then go back and fix the parse tree (like in C#).
                                                                                                                    • etc.

                                                                                                                    In comparison, here are the issues with using [] for generics:

                                                                                                                    • None.

                                                                                                                    For newly created languages (unlike C++, which had to shoehorn templates/generics into the existing C syntax) it’s a completely unnecessary, self-inflicted wound to use <> for generics.

                                                                                                                    More words here: Why is [] better than <> for generic types?

                                                                                                                    1. 2

                                                                                                                      Those are good reasons to not use <>, but as a Haskeller I personally find either style somewhat noisy. I’d rather just write something like Option Int. Parentheses can be used for grouping if needed, just like with ordinary expressions.

                                                                                                                      1. 2

                                                                                                                        Haskell feels like it is in the same category as D, they both just kicked the can a tiny bit further down the road:

                                                                                                                        Both need (), except for a limited special-case.

                                                                                                                        1. -1

                                                                                                                          I don’t see how Haskell kicked the can down the road. The unit type is useful in any language. Rust has a unit type () just like Haskell. Scala has it too.

                                                                                                                          I’m not sure what “special case” you are referring to.

                                                                                                                          1. 2

                                                                                                                            The fact that you still need () for grouping types in generics as soon as you leave the realm of toy examples – just as it is in D.

                                                                                                                            (Not sure what’s the comment on the unit type is about…)

                                                                                                                            1. 4

                                                                                                                              Ah, I understand what you’re saying now. But that’s already true for expressions at the value level in most programming languages, so personally I find it cleaner to use the same grouping mechanism for types (which are also a form of expressions). This is especially applicable in dependently typed languages where terms and types are actually part of the same language and can be freely mixed.

                                                                                                                              However, I can also appreciate your argument for languages with a clear syntactic distinction between value expressions and type expressions.

                                                                                                                2. 1

                                                                                                                  D’s use of !() works pretty well. It emphasizes that compile-time parameters aren’t all that crazy different than ordinary runtime parameters.

                                                                                                                  1. 1

                                                                                                                    I prefer my type arguments to be cleanly separated from value arguments (languages that fuse them excepted).

                                                                                                                    I find D’s approach slightly ugly, especially the special-cases added to it.

                                                                                                                    1. 1

                                                                                                                      I prefer my type arguments to be cleanly separated from value arguments

                                                                                                                      Well, in D they aren’t type vs value arguments, since you can pass values (and symbol aliases) as compile-time arguments as well. That’s part of why I like it using such similar syntax, since it isn’t as restricted as typical type generics.

                                                                                                                      I find D’s approach slightly ugly, especially the special-cases added to it.

                                                                                                                      The one special case is you can exclude the parenthesis for a single-token CT argument list and actually I thought I’d hate it when it was first proposed and I voted against it… but now that it is there and I used it, I actually like it a lot.

                                                                                                                      Sure does lead to a lot first timer questions on the help forums though… it certainly isn’t like any other language I know of.

                                                                                                                3. 2

                                                                                                                  Also, converting numbers is still broken. For instance, f32 to i32 might result in either an undefined value or undefined behavior. (Forgotten which one it is.)

                                                                                                                  Yeah, I kind of feel the same way. Even with try_from() dealing with number conversions is a pain in Rust.

                                                                                                                  1. 1

                                                                                                                    You saved me a lot of typing. 100% agree.

                                                                                                                    1. 1

                                                                                                                      Thanks! I’d love to know the reason why someone else voted it down as “troll” – not because I’m salty, but because I’m genuinely interested.

                                                                                                                    2. 1

                                                                                                                      2 pains I have with Rust right now:

                                                                                                                      • I would like to be able to connect to a database (Teradata specifically)
                                                                                                                      • I want to launch a subprocess with other than the default 3 stdio descriptors (e.g. exec $CMD $FD<>$PIPE in sh)
                                                                                                                      1. 2

                                                                                                                        I know it’s technically unsafe and that might preclude it from your use, but does CommandExt::pre_exec not fit your bill?

                                                                                                                        1. 2

                                                                                                                          That could work. I’m still new to Rust so I haven’t fully explored the stdlib.

                                                                                                                      2. 1

                                                                                                                        Ahahaha, this is a great list. I’m curious about a couple things though, since you’ve obviously put a lot of thought into it…

                                                                                                                        Bitcasting integers to floats is unsafe, because the bits could be a signaling NaN, causing the CPU to raise an FP exception if not disabled.

                                                                                                                        The docs for f32::from_bits() and such talk about precisely this, but I considering the misdesign of signaling NaN’s really don’t see how it could possibly be made better. Any ideas?

                                                                                                                        …They are over-used due to the fact that Rust lacks varargs…

                                                                                                                        What little experience I have with programming language design makes me feel like varargs are a hard problem to deal with in a type-safe language, at least if you want to allow different types for the args (instead of, say, forcing them all to be what Rust would call &dyn Display or something). Do you know of any language which does it Right?

                                                                                                                        1. 1

                                                                                                                          The docs for f32::from_bits() and such talk about precisely this, but I considering the misdesign of signaling NaN’s really don’t see how it could possibly be made better. Any ideas?

                                                                                                                          Rust could have disabled the trapping of signaling NaN’s on start up, but I think Rust fell into the same design mistake of C:

                                                                                                                          Scared of making the use-case of the 0.01% (people who want signaling NaN’s to trap) harder to achieve, they made life worse for the 99.99%.

                                                                                                                          varargs are a hard problem to deal …

                                                                                                                          Agreed, it’s safe to say that language designers hate them. :-)

                                                                                                                          … at least if you want to allow different types for the args

                                                                                                                          I think this is only partially the reason. You can still have only same-typed varargs at runtime, but allow recovering the individual types of the arguments in macro calls – which is exactly the case for format! and friends.

                                                                                                                          Do you know of any language which does it Right?

                                                                                                                          I think in the case of format strings, focusing on varargs is the wrong approach. If you imagine how you want an ideal API to look like, you probably want to interpolate things directly inside the string, never having to go through the indirection of some vararg method.

                                                                                                                          Instead of having the formatting parameters in one place, and the to-be-interpolated values in a different one, like in …

                                                                                                                          let carl = "Carl"
                                                                                                                          let num = 1.234567;
                                                                                                                          format!("{}'s number is {:.*}, rounded a bit", carl, 2, num)
                                                                                                                          // -> "Carl's num is 1.23, rounded a bit"
                                                                                                                          

                                                                                                                          … wouldn’t it be much nicer to write (this is Scala):

                                                                                                                          val carl = "Carl"
                                                                                                                          val num = 1.234567
                                                                                                                          f"$carl's num is $num%.2f, rounded a bit"
                                                                                                                          // -> "Carl's num is 1.23, rounded a bit"
                                                                                                                          
                                                                                                                          1. 1

                                                                                                                            Julia has nice string interpolation too. I honestly don’t understand why more programming languages don’t have it. Does everyone just forget how useful it is in bash when they come to design their language?

                                                                                                                      1. 1

                                                                                                                        Has anyone managed to get on the “general” mailing list for this project?

                                                                                                                        1. 1

                                                                                                                          Fixed :) Sorry for the noise.

                                                                                                                        1. 12

                                                                                                                          I’ve been evaluating sourcehut recently and I was involved in the Neovim/OpenBSD CI integration.

                                                                                                                          The testing infrastructure is really good and it’s really simple to fire up VMs running different BSDs and Linuxes. I much prefer it to travis, which is just a pain to set up.

                                                                                                                          The git side of things is very minimal, and you won’t see things like pull requests (they recommend using the email workflow). If you want PRs, then you can integrate sr.ht with GitHub. Personally I prefer the PR workflow and my guess is that the majority of others would too. Nonetheless, I moved one personal project (for which I don’t expect collaboration) to sr.ht and it all seems to work fine. Perhaps a little slow to push, but that’s geography for you.

                                                                                                                          I’ve not played with the mailing lists or todos much yet.

                                                                                                                          I’d say I’m likely to donate, as I’d like to see a BSD-friendly github alternative succeed.