1. 6

    Is it me or is GitHub really going into their product arms recently? Like over the last two years; they’ve pushed out more non-VCS specific features into their platform that (if embraced) makes it hard to move away / compare against other options.

    It feels a bit icky to me.

    1. 9

      Also today: https://dependabot.com/blog/hello-github/

      Personally, I don’t really see the issue. It is making the platform better, and I don’t really see a “lock-in”: git is still open and distributed, and I can git push to $any server just as easy as GitHub.

      1. 5

        Git, as it stands, is decentralized, totally.

        The Wiki is marginally as well, since it’s Git backed.

        I’m talking about the VCS features (the pipelines, status reporting in merge requests, issue management, following other projects, “trending” repositories, a pseudo social graph, etc). A lot of it are marginally useful and some others feels like straight up noise.

        Granted, this is def a side effect of them having to doubly prove their worth outside of just hosting a crap ton of data.

        1. 14

          GitHub has certainly become more of a “package deal” in the last few years. I fine things like code reviews quite useful. Others like Projects strike me as less useful, at least to me.

          Thus far, GitHub has fairly reasonable. For example the “funding button” you can now create is controlled by a YAML file, and the default includes options for patreon, open collective, and a number of others, as well as providing a “custom” option. It’s not “you must use GitHub funding”.

          Could this change in the future? I guess. But I don’t think that we should live in fear of “what could potentially happen” (while also, of course, not being naïve, but thus far there are no strong red flags at GitHub).

          I don’t think it’s in GitHub/Microsoft’s interests anyway. GitHub earns most of its money from Enterprise sales, and these kind of features strike me as a kind of “marketing”. I also think that Microsoft in particular learned that corporate assholery is a good way to antagonize developers (then again, they still made plenty of money, a does e.g. Oracle).

      2. 6

        Let’s look at some definitions of the Embrace, Extend, Extinguish strategy.

        Embrace: Development of software substantially compatible with a competing product, or implementing a public standard.

        Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the ‘simple’ standard.

        Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.

        Given these definitions I don’t think it’s quite embrace extend extinguish due to how it doesn’t yet create interoperability problems. However I do think it is reasonable to be concerned, given how closely it does track to EEE.

        1. 7

          I don’t think it’s quite embrace extend extinguish due to how it doesn’t yet create interoperability problems

          Git is just git, and that seems fine. But can you easily port your GitHub issues and CI pipelines to another forge or hosting platform, even a straight-up clone like GitLab? As far as I know, there’s no feature in either GitHub or any of their competitors to support that. But in principle, I believe it’s just a scrape-and-parse job, without any legal impediments. I agree, not much EEE going on there.

          Although I don’t use it at all myself, I think the real value that GitHub provides is the “social network” aspect of the platform. The “network effects” are, I suspect, what really keeps individuals and open-source projects on it despite being free to walk away any time. Similar to Medium, especially now with this funding / sponsorship feature.

          1. 6

            But can you easily port your GitHub issues and CI pipelines to another forge or hosting platform, even a straight-up clone like GitLab? As far as I know, there’s no feature in either GitHub or any of their competitors to support that.

            https://docs.gitlab.com/ee/development/github_importer.html

            https://meta.discourse.org/t/introducing-github-issues-to-discourse/46671

            These are just the ones I knew existed.

            1. 1

              I tried this and it doesn’t work as well as it looks, especially if you want to keep bidirectionality.

              1. 3

                It doesn’t allow you to synchronize them. It’s just there if you want to ditch GitHub entirely.

          2. 6

            Their strategy is to offer extra features above their commodity GIT hosting services. Proprietary features make it harder to switch if other services don’t have those features. But crucially, GitHub adding these features does not mean others can not either. It’s not anti-competitive yet.

          3. 4

            They have Microsoft money and resources now. Additionally, their competitor Gitlab has been advertising itself as a “full developer pipeline” for a while now.

          1. 51

            Go has community contributions but it is not a community project. It is Google’s project. This is an unarguable thing, whether you consider it to be good or bad, and it has effects that we need to accept. For example, if you want some significant thing to be accepted into Go, working to build consensus in the community is far less important than persuading the Go core team.

            This is, essentially, not that different from how most projects work. Even projects which have some sort of “community governance” seldom have voting rounds where everyone can vote. Only contributors/core members can vote.

            Accepting all PRs is clearly not a good idea, so you need to do some gatekeeping. The biggest source of disagreement seems to be on exactly how much gatekeep is needed. The Go authors have pretty clear visions on what should and should not be in the language, and gatekeep a bit more than some other languages. Putting stuff in the language can also be problematic (see: Python’s := PEP drama).


            On the specific point of generics (sigh, again), I think the premise of that tweet is wrong. It suggests that the overwhelming majority of the community is just screaming for generics, and the Go Overlords stubbornly keep say “no”. That’s not really how it is. In the most recent Go survey 7% gave “lack of generics” as a response to “what is the biggest challenge you face today?” which is hardly overwhelming (although it’s not a clear “would you prefer to see generics in Go”, so not a complete answer).

            Anecdotally, I know many Go programmers who are skeptical or even outright hostile to the idea of adding generics to the language, although there are obviously also many Go programmers who would like to see generics. Anecdotally, I’ve also noticed that preference for generics seems negatively correlated to the amount of experience people have with Go. The more experience: the less preference for generics. I’ve seen people with a C# or Java background join our company and strongly opine that “Go needs generics, how could it not have them?!”, and then nuance or even outright change their opinion over the months/years as they become more familiar with the language and why the decisions were made.

            The author of that tweet claimed in the Reddit thread:

            I am suggesting that implementation of generics will be easy . All am suggesting is we (community) should implement prototype or so proof of concept and present it to committers .

            Which seems to suggest that this person is not very informed on the topic. The Go authors have been writing and considering generics for at least 10 years, and thus far haven’t found an approach everyone likes. You can reasonably agree or disagree with that, but coming in with “oh it’s easy, you can just do it” is rather misinformed.

            The Elm guy had a good presentation a while ago (“The Hard Parts of Open Source”) where he shared some of his experiences dealing with the Elm community, and one of the patterns is people jumping in on discussions with “why don’t you just do […]? It’s easy!” Most top-of-the-head suggestions to complex problems you can type up in 5 minutes have quite likely been considered by the project’s authors. They are not blubbering idiots, and chances are you are not genius-level smart either.

            This is also the problem with a lot of the “conversation” surrounding generics in Go. People like this guy jump in, haven’t seem to informed themselves about anything, and shout “why don’t you just …?!”

            Sidenote: I stopped commenting on anything Go-related on /r/programming as there are a few super-active toxic assholes who will grasp at anything to bitch about Go (even when the thread isn’t about Go: “at least it’s not as bad as Go, which [. rant about Go ..]”. It’s … tiresome.

            1. 26

              I think the premise of that tweet is wrong. It suggests that the overwhelming majority of the community is just screaming for generics, and the Go Overlords stubbornly keep say “no”. That’s not really how it is.

              Be wary of selection bias here: if someone really thought generics was important they wouldn’t be in your community to be asked the question. If the goals of the language are to serve the people already using it, thats a fine thing, but if it’s to grow then that’s harder to poll for.

              1. 9

                Every community is biased in that sense. People who dislike significant whitespace aren’t in the Python community, people who dislike complex syntax aren’t in the Perl community, etc.

                I don’t think the Go team should poll what random programmers who are not part of the Go community think. I don’t even know how that would work, and I don’t think it’s desirable as the chances of encountering informed opinions will be lower.

                1. 6

                  Anecdotally, I’ve also noticed that preference for generics seems negatively correlated to the amount of experience people have with Go. The more experience: the less preference for generics.

                  This part was also concerning to me. If Go is “blub”, then of course people who are more used to not having generics wouldn’t necessarily think generics are preferential.

                  1. 8

                    I don’t think this fits the “blub” model. People who have only used “blub” don’t understand what they are missing. But here we are talking about people who have got experience with generics: the more experience with Go they gain, the more they understand why Go does not have them.

                  2. 2

                    There is the old adage of being unable to please everybody.

                    It’s better to cater to the crowd you have than the whims of random people.

                  3. 13

                    In the most recent Go survey 7% gave “lack of generics” as a response to “what is the biggest challenge you face today?” which is hardly overwhelming (although it’s not a clear “would you prefer to see generics in Go”, so not a complete answer).

                    I think it’s also worth mentioning that “lack of generics” is the third biggest challenge in that survey (after “package management” and “differences from familiar language”).

                    1. 7

                      “I am suggesting that implementation of generics will be easy”

                      Do you have a link to this comment? The way it’s phrased makes me think that it’s a typo and they meant to say “I am not suggesting that implementation of generics will be easy”.

                      1. 8

                        For outrageously inflammatory post titles like this one, I skip straight to the Lobsters top comment. Cunningham’s Law hasn’t failed me yet.

                        1. 5

                          Reminder that Go has generics for a small set of built-in data types, just not user-defined generics. Let’s be explicit: the language already has generic types in its syntax, e.g.:

                          [n]int
                          []int
                          map[string]int
                          

                          It’s not a great stretch from this to something like tree[int]. Given this, the fact that the language designers have put it off for so long, and so much of the community is antagonistic towards it (where does that antagonism come from–where did people pick up on it?)–it’s not a big stretch to infer that they simply don’t want Go to have user-defined generics.

                          1. 4

                            where does that antagonism come from–where did people pick up on it?

                            I picked it up in the C++ community. From build times to breakage to complexity, I have repeatedly implemented external generics (code generation) solutions that were simpler to manage and gave far better results for my projects than using templates.

                            1. 1

                              Those are not really generic types but variable-length types. Not exactly the same.

                              it’s not a big stretch to infer that they simply don’t want Go to have user-defined generics.

                              The catch with your inferration (is that a word? Is now I guess) is that the Go authors have explicitly stated otherwise many times over the years, and have written a number of proposals over the years (the Go 2 Contracts proposal lists them). There have also been a number of posts on the Go issue tracker, Reddit, HN, etc. by Go authors stating “we’re not against generics, we’re just not sure how to add them”.

                              1. 3

                                Those are not really generic types

                                If you take a look at your linked design document, e.g. maps are repeatedly used as generic types in the proposed Go polymorphic programming design.

                                Go authors have explicitly stated otherwise many times over the years, and have written a number of proposals over the years

                                Good point, before the generics design document was published I suppose my inference would be more credible. Now I guess they are serious about generics–which seems unfortunate for the people you mentioned who vehemently hate them :-)

                          1. 6

                            This can be quite useful on GitHub to hide stuff like long log output or a patch (GitHub doesn’t set a max-height/overflow-y: auto on <pre> elements).

                            1. 11

                              The biggest gripe I have with gopher is that it’s all monospaced text. I just don’t find it very readable. It would not be hard to make a graphical client with proportional fonts and have it reasonably work, but it’s not designed for that (and last time I looked, I couldn’t really find an existing client).

                              On a more deeper level, I dislike that Gopher treats documents as “strings of characters”, and nothing more. In many ways this is very much an engineer’s “function over form” approach (“the airflow is actually quite good”), but I think presentation is part of a good reading experience. Presentation can be done poorly, but it can also be done well and be innovative and surprising. I don’t want to lose the great stuff just because there is also bad stuff. Sounds like mediocracy.

                              I’d love to have a “rich Gopher”, with a reasonable (but not excessive) way to style documents, and perhaps even a some amount of scripting capability (not JavaScript). I think this is also something that could appeal to people beyond the tech community.

                              The problem now is that we’re kind of stuck between two extremes. Many people dislike the web, but many people also dislike Gopher (certainly outside the tech community). If you want Gopher to remain this tiny niche then that’s fair enough, but if you’re really serious about taking on web privacy then a more pragmatic and realistic solution than “no JS, CSS, or any feature that could every possibly be used to track anything” is going to be needed (I have some ideas, but I won’t sidetrack this thread with them).

                              1. 6

                                The protocol is dead simple and one could probably write a client in sh if one wanted to. In fact, it was developed at the same time as HTTP, but without knowledge of HTTP, so it’s a parallel evolution, and at one point, more popular than the web (even Time Magazine had a gopher site back in day). It’s a shame that web browsers stopped supporting it though.

                                As for formatting, HTML is still a viable text format, well documented, highly supported, etc. The major complaint of the web in gopherspace is generally the bloat and abuse of Javascript. I’ve also found that most gopher sites (including my own violate RFC-1436 and use UTF-8 instead of ISO-8859-1 so there’s some progress being made.

                                Personally, I think scripting the web was a bad idea but sadly, it was probably inevitable.

                                1. 1

                                  Do you think “scripting the web” is an improvement over web pages + Java applets?

                                  1. 1

                                    Java applets, Javascript, they’re both “scripting the web” both of which were bad ideas.

                                    1. 1

                                      I see them as different. Java applets had much more separation between code and content. Applets always felt to me like something different than the web, even though they were shipped to the user via the web.

                                      Javascript blurs the lines between code and content. I could turn off Java or not install it, but this is much more difficult with Javascript. At least we rid ourselves of server-side imagemaps and CGI forms, but at what cost?

                                2. 6

                                  but I think presentation is part of a good reading experience.

                                  Yes. Take a step back from the technical view and ask what you’re actually trying to achieve as an author of a document on the Internet. You want that people read and understand the document. So the document has to be presented in a way that makes reading and understanding most accessible. Making everything monospace does not help readability at all – in centuries of book print we have agreed on non-monospace fonts for a reason.

                                  I’d love to have a “rich Gopher”, with a reasonable (but not excessive) way to style documents,

                                  Whatever it is called, an alternative web focused on document presentation would be very nice. While I’m a strict opponent of the excessive JavaScript now found everywhere, I don’t see a reason to ban CSS in its entirety. To the contrary, it is the author who knows best what he wants to say in his document, therefore it is required to give him the tools to present it ideally. A uniform design to the liking of the client’s user can actually hinder best presentation of the information contained. If the user prefers black background for instance, any black arrows you used in your wonderful diagrams vanish. Again, take a look at the books you come over. They don’t look all the same. Font, form, layout, etc. are chosen (by a good publisher) in such a way that they support understanding the presentation. This is the form-follows-function approach. Where there is room left after fitting the page to the function, optional styling can be used for visual identity.

                                  That being said, a fallback must be provided. The desire to present the information to the majority of the people in the best way possible can occasionally conflict with the needs of disabled persons that do need an environment tuned to their needs.

                                  Readability is not identical with retro-minimalism.

                                  1. 3

                                    I do actually completely agree with you about book typography. The restrictions I suggest in the article are meant to be thought-provoking, and to specify something that’s too restrictive to be abused, on the principle that if you give them an inch, they’ll take a mile.

                                    1. 1

                                      While I’m a strict opponent of the excessive JavaScript now found everywhere, I don’t see a reason to ban CSS in its entirety.

                                      HTML 3.2 + CSS2 - JavaScript seems pretty close to the goal. We used to have nice sites with just HTML and CSS. Maybe a few other HTML features. I’ll leave it to web developers to figure out which ones are worth the potential costs.

                                      1. 4

                                        It’s the sweet spot if you are a mouse user. Gopher makes a lot more sense in a world without mice and touchscreens (because of the way it displays numbered links compared to lynx or any of the mozilla/firefox addons that I’ve tried). I could navigate through gopherspace on my 1200bps modem at a speed that I can barely match on the modern web.

                                        1. 1

                                          Good point. I used to use keyboard on older browsers but lots of tabbing. Maybe have a command that puts a little number or letter on each actionable item on the page that user can type in? Just kind of highlights them for a keyboard selection.

                                          1.  

                                            Vimperator for Firefox does just that. My only issue with it was adding and removing the keyboard hints on a slow machine (try it on a Raspberry Pi or an old workstation) adds a bit of a delay while the content on page reflows to adjust.

                                            I believe there is an equivalent plugin for Chrome-based browsers as well.

                                            1.  

                                              Outside the styling, that picture is the kind of thing I had in mind. To me, it was kind of like hitting Alt on Windows where I could see something to speed up what I was doing.

                                            2. 2

                                              This is what happens if you use lynx -number_links, but I find it to have a high cognitive load. A new link added since the last time I visited the page can renumber all the remaining links, so I can’t use muscle memory (this can happen with gopher too, but new links are usually added at the end). Links also aren’t in the same place on each page, so I have to scan the whole page to find all my choices, whereas with gopher I only scan down the left column of the screen.

                                              1.  

                                                Yes, that is my biggest complaint with something like Vimperator (or lynx -number_links). ELinks can produce a simple list of all the targets of visible links (elinks -dump) but it’s not integrated with interactive browsing.

                                          2. 2

                                            Yeah, that’s pretty much the sweet spot. But there are a bunch of nice semantic things in HTML5, like main, article, details/summary, and the new input types. Those things are good in the absence of JavaScript, but some of them also help replace it.

                                        2. 3

                                          By having a look at nroff 1 and mandoc 2, I realize that plain text formatting is a thing. It helps a bit.

                                          It is possible to transmit html and javascript over the current gopher, or say, markdown document, and have the client display them.

                                          There is already a HTTP of Markdown movement through plugins 3.

                                          The simple fact of having the text at the middle of the screen rather than displayed at the left edge of the screen helps. Either with a window manager, terminal emulator or a gopher client.

                                          Just like for the web, the clients are defining a sensible set of choices of what to do with the content or the user through plugins (web) / wrappers scripts (xdg-open custom script for gopher? “Plumbing”).

                                          It is all about how things balance themself, and I do not think extension to the Gopher protocol are needed yet.

                                          Probably one concern is related to encryption, but for that, Gopher over Tor is already quite well settled down, and fully compatible with the current protocol (.onion links are self-describing).

                                          1. 3

                                            Gopher is simple enough that the menu and selector presentation is really an implementation concern.

                                            There have been some novel interfaces designed, like GopherVR, where you can fly around the selectors, and while it doesn’t directly address your concern that most Gopher content itself is monospaced text [for easy (and secure) access from within the average Gopher client], Gopher isn’t limited to that, and can serve up arbitrary rich-text and binary document formats.

                                            A thoroughly modern client could implement sandboxed and secure RTF, PDF, HTML, etc. viewers within the client itself, or build on a browser as other projects have in the past, but that doesn’t actually address your concern, which is that of the main “Gopher site” - the menus & selectors themselves.

                                            I’ve come to view the clear and simple Gopher menu structure as a feature. The design is especially useful for those with disabilities, especially those who are motion or vision impaired. Of course, if you have a proposal to improve presentation, while maintaining backward compatability with existing clients and Gopher’s legendary accessibility, I’d encourage you to join the gopher-project mailing list or the freenode #gopherproject IRC channel and present it - while you might get some pushback (or at least be met with initial skepticism), it’s worthwhile to get these ideas out to the community.

                                            It’s my personal opinion, however, that the classic plaintext selectors should stay as-is. The most distinctive Gopher sites are distinctive because of the actual content that they host, rather than the presentation of the menus leading to the content. This allows the content itself to stand on it’s own merit. It’s a Gopher feature that you don’t have to be a designer (or hire one) to produce a quality Gopher hole, and you won’t be written-off or ignored if you lack those skills or don’t want to pay for them.

                                            A big reason a lot of Gopher advocates have turned against the Web is because the ‘rich’ nature of the Web can lead to favoring style over substance.

                                            1. 3

                                              I’ve come to view the clear and simple Gopher menu structure as a feature.

                                              This is exactly right. Some people complain about minecraft because everything is blocky, but it’s the simple nature of the blocks that make it what it is.

                                              A big reason a lot of Gopher advocates have turned against the Web is because the ‘rich’ nature of the Web can lead to favoring style over substance.

                                              Would you really want to live in a world where hamsterdance never happened?

                                              1. 2

                                                I’d like to live in a world where Twitter doesn’t suck the battery life out of my iPad when I visit it (if it doesn’t outright crash because of the megabytes of Javascript shoved down the pipe).

                                                1.  

                                                  Megabytes of JavaScript for a site that is (still essentially) built on the concept of sharing 140-character messages is exactly the sort of thing that makes a person scratch their head. The style to substance ratio is quite low indeed.

                                              2. 1

                                                the mailing list is dead (and they wont approve my account) and that IRC channel, has, lets say less than helpful characters in it. I found mastodon #gopher tag and the tildesverse IRC a much more productive and respectful place to talk about gopher.

                                                1.  

                                                  Sorry I didn’t see you on IRC to say ‘Hello!’ and try to be a more helpful character.

                                                  Also, the gopher-project mailing list is active - I’ve received multiple messages from it today in fact. You could try to send a message to the list owner if all else fails.

                                              3. 1

                                                I agree with these points and I think that support for a (cut down form of) markdown documents in gopher would be a really great solution to them.

                                                A system with scripting could be cool but that would definitely be done as a separate thing to gopher.

                                                1. 3

                                                  a (cut down form of) markdown

                                                  Why cut down? If anything, it should have extra features standard markdown implementation don’t have, but everyone ends up wanting, like tables or footnotes. Having these kinds of things “by convention, by default” would IMO prove to be a good argument.

                                                  1. 2

                                                    How would you handle links inside markdown documents? (given that gopher documents generally have one link == one line of text)

                                                    1. 1

                                                      How would you handle links inside markdown documents? (given that gopher documents generally have one link == one line of text)

                                                      Well markdown wouldn’t be reduced to a gopher map, but it would be a special type of document, a gopher man can link to. I’ve mentioned this here before, but I still think it’s nonsense to use gophermaps as a markup language.

                                                  2. 2

                                                    Markdown feels like a really good fit for gopher.

                                                    (I’m actually partial to creole, but markdown seems to have won the text-based markup war)

                                                    1. 3

                                                      Markdown feels like a really good fit for gopher.

                                                      Markdown is an extremely do-what-I-mean hard-to-parse markup language. That’s the opposite of something like Gophermaps, which can be parsed with an algorithm that would fit on a business card, and which are very hard to type with a normal keyboard.

                                                1. 3

                                                  How come “(benevolent) dictator for life” is OK for pudgy but lovable Western European men, but is not ok for corporate entities from the USA?

                                                  1. 61

                                                    Shall I compare thee to a billion-dollar corporation? Thou art more lovely and more temperate,

                                                    1. 12

                                                      Because ultimately, when the community VERY LOUDLY made it known to Guido that type system theory may be a fascinating pursuit but that radically altering the Python language to sprout that kind of feature isn’t something some people are interested in, he stood aside and allowed the language governance to change to meet the needs of the community.

                                                      What I’m reading from this article (Not a Go fan, no skin in that game. Feels like a time warp back to K&R C circa 1988 to me.) is that there is exactly zero chance of this ever happening with Go.

                                                      1. 5

                                                        when the community VERY LOUDLY made it known to Guido [..], he stood aside and allowed the language governance to change to meet the needs of the community.

                                                        Wait, you tout it as a good thing? Being very loud rarely has anything to do with being right or useful. And making a smart person cave in to harsh pressure is not really an achievement.

                                                        (Mind, I’m not discussing the technical point about types itself.)

                                                        1. 3

                                                          From my perspective, despite the phrasing I chose in my previous comment, this isn’t at all about being loud.

                                                          It’s about defining the technical direction of a piece of technology that is used and relied upon by a vast number of people with very varied use cases.

                                                          Nobody is saying that Guido shouldn’t design type theory oriented extensions to Python, what people are objecting to is radically altering the syntax of the language standard in order to further those goals.

                                                          For many people, what we value about Python is its un-clever, un-cluttered syntax, and for a substantial number of people, the directions Guido wanted to take the language were not conducive to our usage patterns.

                                                          My point here is simply that Guido, as language designer, was mature/enlightened enough to put his ego aside and recognize that the directions he wanted to take things were not what a sizable numerical percentage of the community wanted, and that his energy would be best spent standing aside and letting majority rule. I see this as a very different situation from the one you paint in your comment.

                                                          1. 2

                                                            Now, that is a much better explanation, thank you!

                                                            Despite being a long-time user of Python I was never involved in the design discussion around the language, so I only see what other people translate outside of the inner circle.

                                                        2. 3

                                                          Isn’t that exactly what happened? The community said they needed module support, the go team added module support.

                                                          1. 11

                                                            Again, not an expert - not even a Go fan - but what I’m reading is that the community came up with its own solution and the Go team chose a radically different path.

                                                            So, maybe? I’m not sure. The point I was addressing was the “Go is Google’s, not the community’s”.

                                                            1. 2

                                                              Not in that way, though. There were a few community solutions to packaging over the years when the Go team didn’t want to tackle the problem, leading to one solution (dep) that was basically officially blessed right up until it wasn’t and another path was chosen by the core team. There was poor communication around this and expectations were not well managed. I think the go team truly wants the best solution, but seeing this play out did make some people feel like the author of this post.

                                                              The bigger issue is that the priorities used to design go modules are quite different from what some folks in the community want in a dependency manager (specifically, its use of minimal version solving), which puts you in the position to use the official thing that doesn’t do what you want or try to find a community-backed project that is attempting to work in a familiar way but will surely dry up as folks adopt the official solution.

                                                              FWIW I had a bunch of issues with dep, but I think they were the result of not having a centralized repository for packages like there is for other languages and with not the tool itself. It turns out that it’s hard to build a reliable dependency manager when you need to be able to contact every host who hosts code instead of just one.

                                                          2. 7

                                                            Because modules.

                                                            (Seriously, I read the whole post as a complaint about the modules decision it alludes to, plus the obligatory swipe at the lack of generics.)

                                                            1. 5

                                                              You’re probably correct.

                                                              I, for one, am happy with modules. I never liked dep, and think modules is significantly better both in semantics and implementation. That being said, some of the communication was … unfortunate, although different people seem to have quite different recollections of some events, so who knows 🤷

                                                              I do empathize a lot with the dep team (And Sam in particular) as it always sucks if you spend a lot of time on something, only to not have it used. But sometimes these things are hard to avoid.

                                                              1. 3

                                                                I don’t think I made it clear enough that my entry was an observation, not a complaint; to the extent that it’s a complaint, it’s only a complaint that the Go team is not honest about how things work in Go’s evolution. I personally am happy with the end results of the current Go module design (as a sysadmin, I particularly like the minimum necessary version approach) and the current lack of generics (I would rather have no generics than not-great generics or generics that clash with the rest of the language). There are a number of benefits that come from having a language with a distinct ownership, provided that you have the right owners, and I think that Go does.

                                                                (I’m the author of the linked-to entry.)

                                                              2. 3

                                                                It sounds like the complaint is that Google talks a big game about how open Go’s development is, but at least in the modules case, is happy to completely ignore extensive open coordination on building a module system for Go while silently building its own module system from scratch. I don’t follow Python development that much, but I don’t think they’ve ever done anything like that.

                                                                1. 0

                                                                  It’s really not ok for either, to be frank.

                                                                1. 6

                                                                  So after reading this I’m like … okay? I don’t know what I’m supposed to do with this, there’s no concrete information, no “lessons learned”, or anything else. I learned pretty much nothing from reading it, and it just seems venting about an encounter with a toxic person.

                                                                  I’m sorry that happened to you, and writing down things like that can be good for you, but it doesn’t seem like the sort of thing that can/should be discussed on the internet.

                                                                  1. 18

                                                                    I get you. I have read other articles similar to this one and in many cases I did not learn anything, in others I learnt a lot. I never expected to write something like this. However after all this happened I had to explain to many people, groups what happened. People that I don’t know called me and told me they had similar issues with the security specialist! I was and am tired of explaining everything. In addition to that yesterday I was again trolled by him. I was tired and decided to write something that I can send to somebody that asks me for details. I know will this will be helpful to some people. I am really sorry if I made you waste time. I really tried to add some type of disclaimer so that anybody that is not interested in something like this did not waste time reading it.

                                                                    I also wanted to avoid being dramatic. I am really not trying to get attention with this. This is BAD attention. There are way more important things for anybody that a conference’s problema but I decided that it was the best thing to do based on all the things that are happening.

                                                                    1. 5

                                                                      If only lobsters supported blocklists it would be useful for identifying “reverse racism oh no!” fools as evidenced by the two -10 comments below.

                                                                      1. 20

                                                                        If the community decides it needs block lists, I’ll probably leave. I don’t want to be part of a place with the level of sustained hostility that implies.

                                                                        1. 9

                                                                          It’s not even about hostility necessarily. I just find that certain users consistently post garbage comments. It’d be nice to just not read it at all.

                                                                          1. 5

                                                                            In the case of this article, the downvoting was enough; the garbage comments are at the bottom of the page and hidden until you click the + to show them. But yeah, that isn’t always the case.

                                                                          2. 2

                                                                            I agree. We can all see what this did to Twitter and the development of echo chambers (on both sides of the political spectrum).

                                                                            1. 2

                                                                              I disagree with almost everything you’ve said in reply to this post, but I agree about that. Twitter’s design is worse than Reddit’s, which is a real achievement considering how bad Reddit is for politically charged discussions. It creates echo chambers, where people who slightly deviate from your own opinions become invisible, but it does nothing to stop the real harassment, who can manufacture sockpuppets quite easily (unlike Reddit, there’s no community moderators to hide the harassing content before you see it).

                                                                            2. 2

                                                                              Agreed. I think blocklists are a dangerous and entirely unnecessary tool. If someone is misbehaving and trolling constantly, there are probably common sense rules that can be pointed at (e.g. “no harassing users, no doxxing, no threats, no spam, etc.”), that can be used as justification to block their account (after a warning). Downvotes for everything else. That is enough in virtually all circumstances in the case of online forums. Blocklists, OTOH, I have never seen lead to anything good. They are easily abused, and are practically guaranteed to generate groupthink.

                                                                              1. 2

                                                                                I’m super happy that somebody finally posted a response that more-or-less summarizes my objections, so I didn’t have to write it. :) I was a bit surprised, though I shouldn’t have been, that the first few responses were coming from other angles that I didn’t think got at the fundamental thing.

                                                                          3. 2

                                                                            I think the lesson learned is to understand the risks you may face organizing a conference. A lot of the logistical risks are assumed and documented, but this is a facet of the experience that might catch you by surprise. A part of this gives perspective on an approach to dealing with the scenario.

                                                                            Some of it is venting, sure, but i do think there’s value in hearing these personal stories. Fair enough if it didn’t resonate as anything you needed to know, but it seems clear that it struck a chord with others

                                                                          1. 16

                                                                            “…The idea of strong opinions, loosely held is that you can make bombastic statements, and everyone should implicitly assume that you’ll happily change your mind in a heartbeat if new data suggests you are wrong…”

                                                                            No, it does not. It means that as a professional, you do not associate your passion for a technical topic with your self-worth. It’s okay to feel strongly about something without being a jerk about it. It’s permission to speak honestly and get feedback from others. If you do this, others may very well call you an asshole! They may vote you off the island. So you learn what’s important and what’s not. What’s worth having public passion over and what’s just being a jerk.

                                                                            You should have strong opinions about error handling, or customer service. You should speak up about your opinions so we might learn from you. You might have strong opinions about the pasta down at Luigis, but nobody cares. And we’ll tell you so. The requirement with strong opinions lightly held is that you have to agree to suck it up and do things you might not agree with. You can’t have one without the other.

                                                                            It’s just the opposite of what this author thinks it is. It’s the thing that over time prevents people from being jerks, not encourages them to.

                                                                            ADD: Does our industry have a problem with tech bros and people making bombastic statements? Most definitely. But I don’t think that’s related to SOLH. In fact, for every one of these bozos, I can show you five tech people that should be speaking up and are not. Those are the ones who cause real damage to an organization.

                                                                            1. 21

                                                                              You should have strong opinions about error handling, or customer service. You should speak up about your opinions so we might learn from you.

                                                                              There is a famous Bertrand Russell quote: “The whole problem with the world is that fools and fanatics are always so certain of themselves, and wise people so full of doubts.”

                                                                              It matches my experience exactly. The more I learn about complex topics like error handling or customer service, the more I realize that there is no “One True Way”™, and that it’s actually really complex and a series of trade-offs.

                                                                              Does our industry have a problem with tech bros and people making bombastic statements? Most definitely. But I don’t think that’s related to SOLH. In fact, for every one of these bozos, I can show you five tech people that should be speaking up and are not. Those are the ones who cause real damage to an organization.

                                                                              At least some people are not speaking up out of fear or exasperation by being told that their viewpoints are “absurd” or “not sane”.

                                                                              I just tap out of discussions these days once someone starts acting like that, and I know that in a few instances it has caused real damage to the business. I’m not happy with that, but there is a limit to what I’m able to put up with before it starts affecting my mood to an unreasonable degree.

                                                                              1. 6

                                                                                Strong opinions does not necessarily mean obnoxious or loud. I don’t understand how we got to the point where people think that. I feel strongly about fishing in the rain. Doesn’t mean I ever yell about it. It’s an odd conflation of ideas, as if the demonstration is as important as the strength. I wouldn’t think that would be true at all.

                                                                                We have to self-correct. In order to self-correct, it is necessary to make a case for some path we recommend and then negotiate/argue/arm-wrestle as part of a decision-making process. Passion allows us to make our case. It does not have to involve yelling or being rude. We just have to care, to feel strongly. After all, we’re professionals. Why wouldn’t we feel strongly about various parts of our job? I’d argue we aren’t worth a bucket of warm spit if we don’t. I know I wouldn’t want to work with anybody who had no passion in our work.

                                                                                It’s such a weird confusion of ideas. Feeling strongly about something does not mean acting like a bozo. In fact, that’s pretty much acting childish.

                                                                                Yep, everything is complex and people who oversimplify and are too sure of themselves can be problems. It is also true that given incomplete and sometimes self-contradictory information, we are required to make choices. We should do what we can to make sure these are the best choices possible. Tapping out ain’t cutting it.

                                                                                1. 4

                                                                                  What you’re describing doesn’t sound like a “strong opinion” to me, but rather just “an opinion”.

                                                                                  Perhaps this is just a case of semantics, but the adjective “strong”, to me at least, means either “not likely to be convinced otherwise” or “obnoxious or loud” These are indeed two very different things, but generally neither of them are very constructive, and doesn’t really seem like what you’re describing.

                                                                                  1. 1

                                                                                    I thought the strong was an adjective on your belief in the opinion. As in, you believe with all your heart that a particular option/action/way is the right one.

                                                                                2. 2

                                                                                  I agree. I am not going to have a shouting match with my coworkers. It’s not worth the aggravation.

                                                                                  1. 1

                                                                                    There is a famous Bertrand Russell quote: “The whole problem with the world is that fools and fanatics are always so certain of themselves, and wise people so full of doubts.”

                                                                                    Well, I am personally full of doubts. Still I would give some of this type of decision makers more credit. It is easy to criticize everything since nobody knows anything of relevance with certainty (or you wouldn’t need to argue about it). In a tech context (and many others), it is often more effective to go with one reasonable choice, stick with it and control doubt with overconfidence.

                                                                                    1. 1

                                                                                      I like the quote and agree on the spirit ( https://quoteinvestigator.com/2015/03/04/self-doubt/ ) but you are confusing strong opinions with overconfidence / inflated egos.

                                                                                    2. 2

                                                                                      There’s something valuable about SOLH, so long as the LH part is taken to mean both qualifying statements based on an honest and informed estimate of confidence & actually updating your priors. And, some folks who stand by SOLH (including, presumably, some of its popularizers) take it this way. I’ve seen too many folks who apply it in the way OP describes to believe that it isn’t being used as a justification for ultimately destructive behaviors, though, even if that application is based on a misunderstanding of what the original popularizers intended.

                                                                                      OP’s suggestion of annotating statements with confidence levels (which is popular in the rationalist community for blog posts, & seems to have come from Robert Anton Wilson, who recommended it along with e-prime for avoiding common patterns of miscommunication) is a good one, because it rewards accurate estimates of confidence, providing a road for careful folks to gain social status over pundits & blowhards by raising a useful metric above being loud and contrarian (which, unless it’s paired with careful thought, introspection, and a rigorous and accurate estimate of one’s own confidence levels, usually ends up being equivalent to being annoying and wrong).

                                                                                      Of course, this runs contrary to norms. We live in an environment where qualifiers are called ‘weasel words’ & no matter how much you signal your level of confidence, all those signals will be stripped away as you are judged on your conclusions as though your confidence were 100%. Furthermore, confidence is held in esteem before it can even be proven to be justified, so we cheer on demagoges for being bold as they lead us full speed ahead into obvious traps. In such an environment, people who can get away with avoiding being held to account are incentivized to sound very sure, and everybody else is incentivized to keep their mouths shut.

                                                                                      1. 3

                                                                                        I think all of us are missing the point when it comes to passion, confidence, truth, and so on.

                                                                                        These are language games. Most of what teams do are language games. Put another way, everybody wants to do a “good job”. The rest of what we do is trying to come to common agreement on what the phrase “good job” means.

                                                                                        The certainty number isn’t awful. It just misses the point of what we’re trying to do. As arp242 pointed out, things are complex. What we’re looking for is the simplest question we can agree on that’s important, testable, and that we disagree on the answer. That question might be something like “Switching to SONAR will result in 10% fewer bugs to production” (I can’t give you a good example because it varies widely depending on the circumstances.)

                                                                                        To get to that pivot question, we have to take strong opinions about fuzzy things, then work our way towards being more reasonable about absolute things. This is the job of being a smart person who creates technology. A user comes in and says “I hate this! Make it stop sucking so badly!” and we work towards testable chunks of code.

                                                                                        It’s perfectly fine to respond with “What do you mean this sucks? This is awesome!” This is the beginning of that back-and-forth. Checking out is not an option. You could try to go the percentage route but then you’re not working towards better definitions of terms. Instead taking a strong position and then following it up with something like “Which parts are sucky?” takes the game forward a step.

                                                                                        “I like X!” vs. “I hate X!” are fine places to start. There’s passion there. Now add some technique and flexibility. If everybody is appropriately apathetic, you are in stasis. Not a good place.

                                                                                        1. 3

                                                                                          That makes sense when the origin of the decision-making process is passion, and when nobody comes to the situation with a nuanced understanding. In most professional situations, neither of these are the case: developers are working on things they don’t care about for users who see the application as a necessary evil, and one or two folks in the group have 30 years of professional experience to everybody else’s three months (along with complex nuanced and experience-backed takes that simply can’t be boiled down to a slogan). Three junior devs shouting irrelevant preferences doesn’t help in this situation, and because their nuance-free takes are low-information, they can be repeated over and over (and thus gain control over the thinking of everybody else). The person with the best chance of designing a usable system gets shut out of the discussion, because when takes are optimized for hotness nobody wants to read an essay.

                                                                                          This notional experienced dev has a greater justification for confidence in their general position, but will necessarily express lower confidence in any individual element, because they have experienced instances that provide doubt. Meanwhile, the junior devs will be more confident because they have never been contradicted. This confidence is not representative of justified confidence.

                                                                                    1. 11

                                                                                      I never quite understood the “loosely held” part of this. As in, I genuinely didn’t understand what was intended with it. I never bothered to look it up so I always just abbreviated it to “strong opinions” in my mind.

                                                                                      This:

                                                                                      The idea of strong opinions, loosely held is that you can make bombastic statements, and everyone should implicitly assume that you’ll happily change your mind in a heartbeat if new data suggests you are wrong.

                                                                                      Made me laugh out loud because it’s such a contradiction. What it really means is “I have strong opinions, but also recognize I may not have all the information, so I’m willing to change my opinion”. In essence, it’s just admitting ignorance.

                                                                                      Ignorance is not a bad word; everyone is ignorant of a lot of things; I sure as hell are. But this also means I’m more humble in dishing out my “wisdoms”. I think the habit of stating things such as “I’m 90% sure that …” is a great tricks, and something I’ve been doing a lot in the last few years (although not always equally effectively, but that’s another story).


                                                                                      I find that a lot of the times these kind of discussions are just a failure in understanding viewpoints. Not everyone’s goals are the same, and not all brains work the same either. This is (part of) the reason that some people like Eminem and others like John Coltrane. Even though I personally strongly prefer Trane I don’t think he’s a “better” artist than Eminem, just a very different one, with a very different approach. The interesting part is that they both get the job done: providing a deeply enjoyable musical experience to millions of people.

                                                                                      I’ll be honest, I don’t quite understand Eminem (or hip-hop music in general), just as I don’t quite understand why people are programming things a certain way, But on the other hand, I can’t fail to acknowledge that for the most part it does give results.

                                                                                      1. 2

                                                                                        I love both Coltrane and Hip-Hop, there’s so much to love in Hip-Hop even for jazz fans (matter of fact one of the biggest hip-hop fans I personally know is actually a jazz pianist). I’ll reply in length as soon as I can! cheers.

                                                                                      1. 1

                                                                                        Is there anything particular to Mongo in this situation, or could it have happened to any unsecured DB?

                                                                                        1. 3

                                                                                          IIRC mongo doesn’t have authentication by default, and older versions were exposed to the internet by default.

                                                                                          1. 1

                                                                                            Looks like a normal case of poor choices by someone acting as sysadmin.

                                                                                            1. 3

                                                                                              The phrasing of the article (“important measures which will prevent the attacks are to enable authentication and to not allow the databases to be remotely accessible”) seems to suggest that by default MongoDB instances do not have any authentication and are remotely accessible. I can’t grep it from the docs right now, but this 2016 SO answer verifies.

                                                                                              I just tested it, and it does seem to bind to 127.0.0.1 by default, but perhaps that’s distro-specific or the default changed.

                                                                                              At any rate, not enabling authentication is a poor default. Not everyone running a MongoDB instance is a MongoDB expert and if the entire security of your installation is dependent on not missing a “warning: please enable authentication” in some documentation then you’re just doing it wrong.

                                                                                              People don’t read the docs, or they don’t read the right ones, or they read the right ones, get asked something by a coworker, and continue reading from a different part (skipping the warning), etc. etc.

                                                                                              It doesn’t hurt enabling it by default, and it will prevent a world of hurt for everyone involved. We’ve seen this before time and time again going back to (at least) SMTP servers running as open relays by default.

                                                                                              Replying to your other comment:

                                                                                              Here is the question. How do software people make good defaults when those defaults may make it harder to use and therefore adopt the software?

                                                                                              I don’t think enabling authentication makes software that much harder to use. It’s essentially just one command to change a password. Having your MongoDB installation hijacked also doesn’t make it easier to use ;-)

                                                                                              1. 2

                                                                                                Having your MongoDB installation hijacked also doesn’t make it easier to use ;-)

                                                                                                Arguably it makes it easier to use for everyone. ;)

                                                                                          1. 2

                                                                                            I’ve never understood this – why would I want to configure my editor based on your project? I want my editor to use my config, not yours.

                                                                                            1. 19

                                                                                              I want my editor to fit a project’s style to reduce friction collaborating with upstream / teammates.

                                                                                              1. 6

                                                                                                So I don’t have to tell every new employee/contributor to use the correct line ending for the project, or to add a newline at the end, or to use the correct indentation size. EditorConfig takes care of those kind of common setting that you should really always be using for the project you’re working on.

                                                                                                Some people have proposed to add stuff like spell checking, and those are the kind of personal settings that should not be in EditorConfig (like auto indent, automatically add closing paren, etc.) but I don’t see why there is ever a reason to not use a project’s standard indentation size and such?

                                                                                                1. -1

                                                                                                  Why should I use a project’s indentation in MY EDITOR? That’s absurd. If EditorConfig is for such things, it’s misnamed. It should be named FormatterConfig instead. I edit the code using my config, and format the code using project’s config just before the commit.

                                                                                                  1. 5

                                                                                                    I don’t think this is how most people work, and it’s quite non-trivial to do correct: you can’t just do a search/replace when the indent size and max line length are different. You’ll either need to spend some time re-formatting the code, or your code will look strange.

                                                                                                    If whatever you’re doing works for you: great, keep on doing it. But simply setting the indentation size to the project’s is what works for the vast majority of people, and that is no more or less “absurd” than any other personal preference.

                                                                                                    Besides, you can do whatever you want with an EditorConfig file; you don’t need to do anything with it, or you can just read the file and echo the settings if that’s what you prefer.

                                                                                                    1. -3

                                                                                                      In a sane language, for example Rust, you just type “cargo fmt” before the commit. I spend zero time manually re-formatting the code, and my code looks great.

                                                                                                      1. 8

                                                                                                        How is this even relevant here. I am guessing EditorConfig probably came out before rustfmt itself. For example, I have to use tabs for a project I contribute to and EditorConfig takes care of it and I don’t have remember to switch settings for my editor each time I edit a file in that project alone since I am not using tabs otherwise. I can use clang-format later but EditorConfig is a low hanging fruit.

                                                                                                        1. 1

                                                                                                          Thanks for this comment, I think it summarizes the use case for this tool perfectly.

                                                                                                        2. 5

                                                                                                          Guess I’m not sane then ¯\_(ツ)_/¯

                                                                                                          1. 2

                                                                                                            Is having a cross-platform autoformatter that works well necessary and sufficient for a language to be sane, or merely necessary? Are there any languages which you currently classify as insane which would become sane if only they had a cross-platform autoformatter that works well?

                                                                                                            1. 1

                                                                                                              We even have CI warn if running cargo fmt would change the layout.

                                                                                                              I guess we could use a git hook, but since we are running tests and clippy anyway.

                                                                                                    1. 5

                                                                                                      Seems to be catching on, comparing to the last time it was discussed: http://editorconfig.org/

                                                                                                      There are now 22 editors bundling .editorconfig support, including VisualStudio and Kakoune, as compared to 7 last time around.

                                                                                                        1. 3

                                                                                                          The resistance to have it enabled by default kind-of defeats the point of including it in the standard Vim runtime files, IMHO. Installing a plugin is just as much effort as enabling a default one (one line) and the downside of shipping it by default is that VIm’s development practices are … somewhat annoying.

                                                                                                          I understand some of the objections, but I abandoned the discussion and that issue after someone became far too toxic (I opened that issue). I don’t feel like dealing what that shit.

                                                                                                      1. 36

                                                                                                        Although the title is correct, I don’t think it does any justice to this awesome OpenGL vs Direct3D history lesson.

                                                                                                        1. 3

                                                                                                          It confused the heck out of me since I immediately started readimg the answer after assuming the title was the question. Re-reading question at top, suddenly the post made a lot more sense.

                                                                                                          1. 3

                                                                                                            The submission guidelines say:

                                                                                                            Do not editorialize story titles, but when the original story’s title has no context or is unclear, please change it.

                                                                                                            So I could have added “(OpenGL/Direct3D history/comparison)”. Can’t edit it any more.

                                                                                                            1. 4

                                                                                                              Since you linked to the answer and not the question, I think that you would have had a bit more freedom when it comes to choosing the title.

                                                                                                          1. 1

                                                                                                            I wonder if this will change Linus’s opinion[0] about sticking with SHA1 for git?

                                                                                                            1. https://marc.info/?l=git&m=148787047422954
                                                                                                            1. 13

                                                                                                              That’s not what that email says though:

                                                                                                              Do we want to migrate to another hash? Yes.

                                                                                                              And if you follow the thread a bit further:

                                                                                                              Again, I’m not arguing that people shouldn’t work on extending git to a new (and bigger) hash. I think that’s a no-brainer, and we do want to have a path to eventually move towards SHA3-256 or whatever.

                                                                                                              But I’m very definitely arguing that the current attack doesn’t actually sound like it really even matters, because it should be so easy to mitigate against.

                                                                                                              1. 2

                                                                                                                In addition to @arp242’s comment, it’s worth noting that email is old. Work for moving to a new hash has been underway for some time now – see brian m. carlson’s talk at Git Merge.

                                                                                                              1. 13

                                                                                                                Nice to read some positive stuff about a maligned language.

                                                                                                                1. 2

                                                                                                                  Is Facebook still using its own version of PHP?

                                                                                                                  1. 3

                                                                                                                    Yes, they are still using Hack.

                                                                                                                  2. 1

                                                                                                                    As I understand it, “maligned” is usually intended as “spreading bullshit/FUD” (Merriam-Webster: “spoken about in an injurious way : harshly or unfairly criticized”). Is this what you intended? Or did you merely intend “criticized”?

                                                                                                                    1. 4

                                                                                                                      If there’s one programming language since Basic that’s literally been maligned, it’s PHP. So yes, I meant it in the M-W sense. We see an example of it in this very thread!

                                                                                                                      Edit note that I am not doing the maligning. I’m neutral on PHP

                                                                                                                      1. 9

                                                                                                                        While I’m sure a lot of the criticism pointed towards PHP is indeed unfair, a lot of it is totally valid. PHP has a lot of extremely strange warts that just don’t really make sense. My favourite example is that the ternary operator (i.e. cond ? true_expr : false_expr) associates left to right instead of right to left (see example four https://www.php.net/manual/en/language.operators.comparison.php#language.operators.comparison.ternary).
                                                                                                                        This is purely a mistake in the grammar and has been left in for YEARS due to lots of code already being written and relying on this.

                                                                                                                        This is just one issue out of a whole lot. There are a lot of benefits to using PHP I’m sure, but it wasn’t a masterclass in programming language design by any stretch.

                                                                                                                        1. 3

                                                                                                                          This is purely a mistake in the grammar and has been left in for YEARS due to lots of code already being written and relying on this.

                                                                                                                          Indeed; this has been an explicit design goal of PHP (maintain backwards compatibility, even if it means leaving warts in place). This is part of what has contributed to PHP’s runaway success: you can run PHP4 code on PHP7 with minimal-if-any changes. I know, because I do.

                                                                                                                          Adam Harvey’s talk What PHP learned from Python made this explicit for me, but honestly it makes sense. It turns out most of these warts are minimally invasive; in general I find reliance on operator associativity or priority makes for hard-to-read code anyway. Focus has instead been on making the language fast and powerful, with optional additions to improve large codebases (like types).

                                                                                                                          I may be biased, because the first language I learned was PHP (more or less), but I keep coming back to it fifteen years later. It’s a fast-to-develop, batteries-included, does-what-you want language. It’s very similar to python in many ways.

                                                                                                                          1. 6

                                                                                                                            There is a loooot of programming languages taking back ward compatibility as a must (out of my head java, python 2, python 3, C, C++, javascript). None of them has wart as PHP. PHP was simply not designed at all.

                                                                                                                          2. 3

                                                                                                                            This will actually be addressed in the next versions of PHP: https://wiki.php.net/rfc/ternary_associativity

                                                                                                                            1. 1

                                                                                                                              In 15+ years of php I’ve never nested ternary calls … Thats just ugly :D

                                                                                                                              I do typically use 1 ternary call to return nicely from a function or method …

                                                                                                                              return (count($f)) ? $f : $bar;
                                                                                                                              
                                                                                                                              1. 1

                                                                                                                                In PHP an empty array returns FALSE, so you can shorten that to:

                                                                                                                                return $f ? $f : $bar;
                                                                                                                                

                                                                                                                                Furthermore, that can be shortened to:

                                                                                                                                return $f ?: $bar;
                                                                                                                                
                                                                                                                        2. -1

                                                                                                                          dude, seriously?

                                                                                                                      1. 6

                                                                                                                        This is a misleading headline.

                                                                                                                        From the linked article

                                                                                                                        “If an attacker can control this memory after the free, there is an opportunity to corrupt more data, potentially leading to code execution.”

                                                                                                                        (my emphasis)

                                                                                                                        1. 12

                                                                                                                          This entire write-up is pretty bad. There is little technical information, contains a number of spelling errors, has awkward and confusing grammar.

                                                                                                                          The original announcements it links is better, and also contains a link to actual technical details.

                                                                                                                        1. 14

                                                                                                                          Just some feedback on that README: all those animated GIFs would be a lot easier to read if they were just pain text:

                                                                                                                          $ some_command
                                                                                                                          output
                                                                                                                          
                                                                                                                          $ other_thing
                                                                                                                          more output
                                                                                                                          

                                                                                                                          It’s just really hard to follow with all the animation, and you can’t look at anything for more than what feels like half a second before the text disappears.

                                                                                                                          1. 7

                                                                                                                            I’ll make the change. Thanks for the feedback.

                                                                                                                            1. 5

                                                                                                                              Yes. Animations and videos are never the way to go for answering your audience’s very first question of, “what the heck is this and why should I care?” If your README.me says “play this video to learn about FooBar”, you’ve already lost me as an interested user.

                                                                                                                              1. 2

                                                                                                                                Personally, I agree, but there are people who would rather watch a video.

                                                                                                                                1. 3

                                                                                                                                  I am in the video camp, my compromise in the end was a single gif followed quickly by text, hopefully it keeps everyone happy now.

                                                                                                                              2. 2

                                                                                                                                Not to mention that they’re not accessible to people who use a screenreader.

                                                                                                                                1. 2

                                                                                                                                  That is an excellent point that I had not considered. Hard to get out of your own bubble.

                                                                                                                              1. 5

                                                                                                                                For prior versions of Red Hat Enterprise Linux, and most Linux distributions, users have been locked to the system version of Python unless they got away from the system’s package manager.

                                                                                                                                Eh? All systems I know of allow installing both Python 2 and 3, and have for a very long time. No one is “locked” to anything.

                                                                                                                                I guess this is “new” for RHEL based on “we can now make multiple versions of Python available and easily installable, from the standard repositories, into the standard locations”. I’m pretty sure I’ve installed Python 3 on CentOS machines in the past, though I think that must have been using one of community repos instead of the standard ones.

                                                                                                                                I also find it interesting that the “new” RHEL 8 uses Python 3.6 from 2016, instead of 3.7 from 2018.

                                                                                                                                1. 5

                                                                                                                                  For prior versions of Red Hat Enterprise Linux, and most Linux distributions, users have been locked to the system version of Python unless they got away from the system’s package manager.

                                                                                                                                  Eh? All systems I know of allow installing both Python 2 and 3, and have for a very long time. No one is “locked” to anything.

                                                                                                                                  What they mean by the above is: for the duration of most OSes’ life cycle, /usr/bin/python existed and was version 2.7, or 3.6, etc., and that’s that - you could not change the system’s default Python version.

                                                                                                                                  What RedHat has done isn’t anything new - OpenBSD has been doing exactly that - there is no default /usr/local/bin/python.

                                                                                                                                  1. 4

                                                                                                                                    I also find it interesting that the “new” RHEL 8 uses Python 3.6 from 2016, instead of 3.7 from 2018.

                                                                                                                                    As to that, Python 3.7 has been released on 27th of June 2018, while RHEL 8 is based on Fedora 28, which itself has been released on the 1st of May 2018.

                                                                                                                                1. 29

                                                                                                                                  Alternative perspective: https://www.jwz.org/doc/cadt.html

                                                                                                                                  Not all issues are equal:

                                                                                                                                  1. Support: “how do I use feature X?”
                                                                                                                                  2. Bugs: “it should do X, but it does Y”
                                                                                                                                  3. Feature requests: “it would be nice if it could do X”

                                                                                                                                  It’s not always obvious what an issue is from the outset. Especially between support and bugs there is quite some overlap.

                                                                                                                                  In my experience many issue that are left lingering are unclear, non-issues, confusions, etc.

                                                                                                                                  Here’s what I did at my last job where the support staff had a tendency to just ramble 3 paragraphs of “description” in the issue title (who needs body text right?) often without a clear example of what went wrong. It worked well enough and made everyone happier; me because I didn’t have to decipher vague issues, support staff because they got better answers faster.

                                                                                                                                  I haven’t tried it at an open source project yet, but I expect it will work well there too.

                                                                                                                                  • Try to triage quickly to determine what kind of issue it is.

                                                                                                                                  • No feedback and unclear? Just close after a few days. It can always be reopened later (but say so in a message! Otherwise people might think closing the issue means “go away”).

                                                                                                                                  • Support request without easy answer? Direct to more appropriate channel. But please, don’t do it like the maintainers of a certain project which just closes issues with an abrasive “this is not a support forum”. Use a canned message to tell people why this is not an appropriate place to get help and where they actually can get help.

                                                                                                                                  • Support request with easy answer? Answer concisely, tell people where to get more help if they need it, and close.

                                                                                                                                  • Add a “confirmed” label to confirmed bugs that really are bugs. IMHO those should remain open until it’s actually fixed. If you’ve got a massive backlog of bugs then chances are that something, somewhere, has gone wrong. Consider it similar to the BUGS section in Unix manpages:

                                                                                                                                    Our habit of trying to document bugs and limitations visibly was enormously useful to the system. As we put out each edition, the presence of these sections shamed us into fixing innumerable things rather than exhibiting them in public. I remember clearly adding or editing many of these sections, then saying to myself “I can’t write this,” and fixing the code instead.

                                                                                                                                  • Feature requests: ~10% are either addressing some fundamental shortcoming or well thought out and are useful. The remaining ~90% are trivial and can be closed with “sounds great, I look forward to a PR!” There are always these people with “ideas” but no actual contributions that post these things.

                                                                                                                                  • Issues without the “confirmed” label can be vacuumed (auto closed) after a few weeks. It’s often not a bug, or if it is, it’s not yet clear. If it’s really important the author can reply and it can be re-opened (say so in the vacuum cleaner message).

                                                                                                                                  • Closing issues is never fun; we all want to help people, right? But it’s required and canned messages are great because it saves you the effort and time of explaining why you’re closing an issue.

                                                                                                                                  1. 2

                                                                                                                                    This seems like a sensible approach, if you can spare the time/energy/whatever to do the work. I believe one of the main issues the article is trying to address is when you don’t have the capacity to do project management work, and it’s more of an emergency measure to deal with a lack of project management resources.

                                                                                                                                    I’ve experienced this myself, where even just doing the work to review and merge a well-put-together pull request feels a lot more like “I should get paid for this”-work than doing what I feel like on my own time.

                                                                                                                                    1. 2

                                                                                                                                      I don’t think it’s that much effort. Essentially, my previous post was just a really verbose way of saying “keep confirmed bugs open, (auto)close most other other things”.

                                                                                                                                      This should get rid of the issue tracker noise while preventing the closure of real issues that should be fixed.

                                                                                                                                      1. 1

                                                                                                                                        I mostly agree with your perspective, but bugs come in different shapes and sizes, and treating them equally is rarely possible (mostly due to resource constraints). I think that major bugs should not be auto-closed, but minor bugs are fair game.

                                                                                                                                  1. 4

                                                                                                                                    What makes an integration worth the dev time to add and maintain?

                                                                                                                                    This is a very good question.

                                                                                                                                    Actually there was a long debate on PR adding support for Keybase on Mastodon and one of concerns raised against Keybase integration was the complexity of the protocol and that it’s tied to Keybase only. Twitter is also a for-profit company but the integrationis I guess it’s vastly simpler (I haven’t seen the code on lobsters but did the Twitter integration for other project).

                                                                                                                                    On the other hand people want to connect to their other profiles but lobste.rs doesn’t have link rel=me support too so maybe there is no harm adding Keybase integration now.

                                                                                                                                    (Personally I’m not quite happy with Keybase’s embrace-extend-extinguish strategy w.r.t. OpenPGP, slowly replacing standards with their proprietary crypto schemes (even if they’re based on widely used crypto primitives) but it seems there is no viable, fully open-source alternative to their identity service).

                                                                                                                                    1. 1

                                                                                                                                      lobste.rs doesn’t have link rel=me support

                                                                                                                                      Note: it does now (since yesterday). It’s added on the GitHub, Twitter, and the homepage fields in your profile (the homepage field is new).

                                                                                                                                      CC: @stevelord (since you also mentioned it in your comment)

                                                                                                                                      1. 1

                                                                                                                                        Excellent! Thank you for the update!