1. 24

    I am confused about why the Rest crowd is all over grpc ant the likes. I thought the reason why Rest became a thing was that they didn’t really thought RPC protocols were appropriate. Then Google decides to release an binary (no less) RPC protocol and all of the sudden, everyone thinks RPC is what everyone should do. SOAP wasn’t even that long ago. It’s still used out there.

    Could it be just cargo cult? I’ve yet to see a deployment where the protocol is the bottleneck.

    1. 14

      I’I imagine that the hypermedia architectural constraints weren’t actually buying them much. For example, not many folks even do things like cacheability well, never mind building generic hypermedia client applications.

      But a lot of the time the bottleneck is usually around delivering new functionality. RPC style interfaces are cheapter to build, as they’re conceptually closer to “just making a function call” (albeit one that can fail half way though), wheras more hypermedia style interfaces requires a bit more planning. Or at least thinking in a way that I’ve not seen often.

      1. 9

        There has never been much, if anything at all, hypermedia specific about HTTP, It’s just a simple text based stateless protocol on top of TCP. At this day an age, that alone buys anyone more than any binary protocol. I cannot reason as to why anyone would want to use a binary protocol over a human readable (and writeable) text one, except for very rare situations of extreme performance or extreme bandwidth optimisations. Which I don’t think are common to encounter even among tech giants.

        Virtually every computing device has a TCP/IP stack these days. $2 microcontrollers have it. Text protocols were a luxury in the days where each kilobyte came with high costs. We are 20-30 years pst that time. Today even in the IoT world HTTP and MQTT are the go to choices for virtually everyone, no one bothers to buy into the hassle of an opaque protocol.

        I agree with you, but I think the herd is taking the wrong direction again. My suspicion is that the whole Rest histeria was a success because of being JSON over HTTP which are great easy to grasp and reliable technologies. Not because of the alleged architectural advantages as you well pointed out.

        SOAP does provide “just making a function call”, I think the reason why it lost to Restful APIs, was because requests were not easy to assemble without resourcing to advanced tooling. And implementations in new programming languages were demanding. I do think gRPC suffers from these problems too. It’s all fun and games while developers are hyped “because google is doing”, once the hype dies out, I’m picturing this old embarrassing beast no one wants to touch, in the lines of GWT, appengine, etc.

        1. 9

          I cannot reason as to why anyone would want to use a binary protocol over a human readable (and writeable) text one, except for very rare situations of extreme performance or extreme bandwidth optimisations.

          Those are not rare situations, believe me. Binary protocols can be much more efficient, in bandwidth and code complexity. In version 2 of the product I work on we switched from a REST-based protocol to a binary one and greatly increased performance.

          As for bandwidth, I still remember a major customer doing their own WireShark analysis of our protocol and asking us to shave off some data from the connection setup phase, because they really, really needed the lowest possible bandwidth.

          1. 2

            hypermedia specific about HTTP

            Sure, but the framing mostly comes from Roy Fielding’s thesis, which compares network architectural styles, and describes one for the web.

            But even then, you have the constraints around uniform access, cacheability and a stateless client, all of which are present in HTTP.

            just a simple text based stateless protocol

            The protocol might have comparatively few elements, but it’s just meant that other folks have had to specify their own semantics on top. For example, header values are (mostly) just byte strings. So for example, in some sense, it’s valid to send Content-Length: 50, 53 in a response to a client. Interpreting that and maintaing synchronisation within the protocol is hardly simple.

            herd is taking the wrong direction again

            I really don’t think that’s a helpful framing. Folks aren’t paid to ship something that’s elegant, they’re paid to ship things that work, so they’ll not want to fuck about too much. And while it might be crude and and inelegant, chunking JSON over HTTP achived precisely that.

            By and large gRPC succeeded because it lets developers ignore a whole swathe of issues around protocol design. And so far, it’s managed to avoid a lot of the ambiguity and interoperability issues that plagued XML based mechanisms.

        2. 13

          Because a lot of what is called REST wends up as something fairly close to an informal RPC over HTTP in JSON, maybe with an ad-hoc URI call scheme, and with these semantics, actual binary rpc is mostly an improvement.

          (Also everyone flocks to go for services and discover that performant JSON is a surprisingly poor fit for that language)

          1. 3

            Cargo Cult/Flavour of the Week/Stockholm Syndrome.

            A good portion of JS-focussed developers seem to act like cats: they’re easily distracted by a new shiny thing. Look at the tooling. Don’t blink, it’ll change before you’ve finished reading about what’s ‘current’. But they also act like lemmings: once the new shiny thing is there, they all want to follow the new shiny thing.

            And then there’s the ‘tech’ worker generic “well if it works for google…” approach that has introduced so many unnecessary bullshit complications into mainstream use, and let slide so many egregious actions by said company. It’s basically Stockholm syndrome. Google’s influence is actively bad for the open web and makes development practices more complicated, but (a lot of) developers lap it up like the aforementioned Lemming Cats chasing a saucer of milk that’s thrown off a cliff.

            1. 2

              Partly for sure. It’s true for everything coming out of Google. Of course this also leads to a large userbase and ecosystem.

              However I personally dislike Rest. I do not think it’s a good interface and prefer functions and actions over (even if sometimes very well) forcing that into modifying a model or resource. But it also really depends on the use case. There certainly is standard CRUD stuff where it’s the perfect design and it’s the most frequent use case!

              However I was really unhappy when SOAP essentially killed RPC style Interfaces because it brought problems that are not inherent in RPC interfaces.

              I really liked JSON RPC as a minimal approach. Sadly this didn’t really pick up (only way later inside Bitcoin, etc.). This lead to lots of ecosystems and designs being built around REST.

              Something that has also been very noticeable with REST being the de-facto standard way of doing APIs is that oftentimes it’s not really followed. Many, I would say most REST-APIs do have very RPC-style parts. There’s also a lot of mixing up HTTP+JSON with REST and RPC with protobufs (or at least some binary format). Sometimes those “mixed” pattern HTTP-Interfaces also have very good reasons to be like they are. Sometimes “late” feature additions simply don’t fit in the well-designed REST-API and one would have to break a lot of rules anyways, leading to the questions of whether the last bits that would be worth preserving for their cost. But that’s a very specific situation, that typically would only arise years into the project, often triggered by the business side of things.

              I was happy about gRPC because it made people give it another shot. At the same time I am pretty unhappy about it being unusable for applications where web interfaces need to interact. Yes, there is “gateways” and “proxies” and while probably well designed in one way or another they come at a huge price essentially turning them into a big hack, which is also a reason why there’s so many grpc-alikes now. None as far as I know has a big ecosystem. Maybe thrift. And there’s many approaches not mentioned in the article, like webrpc.

              Anyways, while I don’t think RPC (and certainly gRPC) is the answer to everything I also don’t think restful services are, nor graphql.

              I really would have liked to see what json-rpc would have turned to if it got more traction, because I can imagine it during for many applications that now use REST. But this is more a curiosity on an alternative reality.

              So I think like all Google Project (Go, Tensorflow, Kubernetes, early Angular, Flutter, …) there is a huge cargo cult mentality around gRPC. I do however think that there’s quite a lot of people that would have loved to do it themselves, if that could guarantee that it would not be a single person or company using it.

              I also think the cargo cult is partly the reason for contenders not picking up. In cases where I use RPC over REST I certainly default to gRPC simply because there’s an ecosystem. I think a competitor would have a chance though if it would manage a way simpler implementation which most do.

              1. 1

                I can’t agree more with that comment! I think the RPC approach is fine most of the time. Unfortunately, SOAP, gRPC and GraphQL are too complex. I’d really like to see something like JSON-RPC, with a schema to define schemas (like the Protobuf or GraphQL IDL), used in more places.

                1. 2

                  Working in a place that uses gRPC quite heavily, the primary advantage of passing protobufs instead of just json is that you can encode type information in the request/response. Granted you’re working with an extremely limited type system derived from golang’s also extremely limited type system, but it’s WONDERFUL to be able to express to your callers that such-and-such field is a User comprised of a string, a uint32, and so forth rather than having to write application code to validate every field in every endpoint. I would never trade that in for regular JSON again.

                  1. 1

                    Strong typing is definitely nice, but I don’t see how that’s unique to gRPC. Swagger/OpenAPI, JSON Schema, and so forth can express “this field is a User with a string and a uint32” kinds of structures in regular JSON documents, and can drive validators to enforce those rules.

            1. 3

              The only time you need to consider a client-server setup is:

              Where you have multiple physical machines accessing the same database server over a network. In this setup you have a shared database between multiple clients.

              So…. an enormous percentage of mature production applications?

              1. 8

                Which is a tiny percentage of all database deployments.

              1. 1

                Great. To get something similar (manually grokking a ginormous json blob) I was using irb, this is awesome. Thanks!

                1. 9

                  Having volunteer moderated elsewhere in the past I can say it is truly thankless work. Be kind to your mods, their best case scenario is “nobody knows they exist” and more commonly various different people are mad at them for irreconcilable reasons.

                  I have no idea if he’s interested but I’d nominate @calpaterson as he’s one of the few folks I know personally who post here, and he’s principled enough to do it properly.

                  1. 8

                    All but one of these function to make reviews stricter - ie: reject more stuff - but none of them really are ways to make reviews more effective. Effective does not always mean “stricter”.

                    My personal experience is that there is a strong bias among programmers to feeling good that they rejected stuff and “were a tough reviewer!” and never considering the false positive side of that where you end up asking people to make a bunch of time-consuming changes based on perceived strictness but which are not really worthwhile. Talking about preventing “sub-optimally factored code” sounds like micromanagement at the review stage and does start to ring alarm bells for me!

                    This one in particular really rubs me the wrong way:

                    To review a change, it is important to agree on the problem to solve. Ask the author to supply a problem statement if it is not presented in the change. Only once you understand the problem statement you can evaluate the quality of a solution. The solution could be over- or under-engineered, implemented in the wrong place, or you could even disagree with the problem statement altogether.

                    If you are ever in the situation where someone has spent time implementing something and their entire approach gets rejected at the final review stage you should absolutely not be patting yourself on the back for that. You need to immediately introspect about why your team process has spent time producing code that was fundamentally wrong from the beginning.

                    1. 6

                      If you are ever in the situation where someone has spent time implementing something and their entire approach gets rejected at the final review stage you should absolutely not be patting yourself on the back for that.

                      I think there’s some nuance here in terms of where the change came from. In open source, it’s fairly common for someone to show up and drop a PR on your project with little or no explanation. That doesn’t make it bad, and it doesn’t make the person who submitted it bad. However, understanding the problem they are trying to solve is still important and may just need to happen in the code review. On the other hand, if we’re talking about a corporate setting, or a PR submitted by a regular contributor to a particular open source project, then it should already have been discussed (and if it wasn’t, there are probably larger communication issues).

                      1. 2

                        From personal experience, I’ve helped someone maintain a friendly fork of an open source project because they wanted a change that I definitely did not want upstream, but which solved a real problem for them (working around a bug in something else that was specific to their deployment). I think ‘this is a great implementation of what it does, but we don’t want it’ is a fine outcome for open source code review.

                      2. 4

                        I’ve definitely met some people who went too far (in my opinion) when it comes to requesting changes in code review. I prefer to conduct code review in person or in a freeform chat, rather than gerrit / PR conversations / etc. because I think there’s a bit of nuance to it. In my opinion things should go something like the following:

                        Major bugs / functional issues: no real question here, send it back to be fixed.

                        Unhandled edge case: fix if possible, but an assert guarding against the unhandled condition, and a TODO comment explaining why you might actually need it at some point, are an acceptable alternative if there’s more important work to be done.

                        Violation of something explicitly set out in the company style guide: fix unless emergency.

                        Refactoring opportunity / optimization opportunity / “I wouldn’t do it that way”: discuss, don’t insist. Sometimes the reviewee will agree that you have the better idea and they’ll go and make the change. Sometimes they’ll prove you wrong because they learned something during implementation that you overlooked from your lofty position. Sometimes they’ll agree that you made a good suggestion, but you’ll agree together that now isn’t the time to squeeze in the change (but the reviewee learned something, and you can come back to it later). And sometimes you’ll just agree to disagree on a matter of style. I think a lot of senior devs push too hard for having things done exactly their way, and end up wasting time and goodwill on things that are ultimately immaterial.

                        1. 3

                          I have almost word-for-word the exact same outlook. One trick I use (which it sounds like you already know) is to just phrase pretty much every piece of feedback as a question rather than a demand. Most people are good-natured and will either make the change you’re implying or will explain why not (often convincingly). One of the very worst things you can do is get up on your high horse about something in the code before hearing about it from the author.

                          1. 1

                            Yeah, I tend towards that as well. I don’t hold fast to it, but I agree. Even in the most straightforward cases, “hey, won’t the code blow up here if this variable is less than zero?” sets a much better tone than “this is broken.” Not to mention, it makes me look better in case I made a mistake and there isn’t actually a bug.

                        2. 3

                          On the contrary, I have a really hard time rejecting stuff. I suspect a lot of people in the industry are probably similar to me (shy, imposter syndrome, etc). I’m sure there are just as many on the other side of the spectrum (socially tone-deaf, cocksure, etc).

                          It has to be pretty “bad” for me to reject it or ask for a large refactoring of their approach, for better or worse. Most of the time, if I don’t see actually errors/bugs with the approach, I try my best not to shit on the whole approach just because it was not the way I like it done.

                          1. 1

                            On the contrary, I have a really hard time rejecting stuff. I suspect a lot of people in the industry are probably similar to me (shy, imposter syndrome, etc).

                            I have reviewed and subject my code from/to hundreds of other developers and what I observed is that you suspicion off. By and large, the majority, think 90%+, get high on power and are eager to reject patches for everything and nothing. White space, bracket style, indentation, style, naming conventions, linting and other secondary details always end up taking up like 75% of the work involved in code reviews. Grand parent is spot on.

                            To make the assertion that everyone is in position to review everyones code is a very silly premise, and can only result into non sense like this. We then get sprinkled with posts like this one on “how to do it right”, as if they have the magical formula and everyone else is doing it wrong.

                            In the occasions I had ownership of the code I end up asking fellow developers to not submit the code to review unless they feel uncertain about it or need additional input for any specific reason.

                            “At least two pairs of eyes”, “a last line of safety before the main trunk” and other silly mantras are non sense to account for lack of competence or code quality. You can throw 20 pairs of eyes at it, if those 20 are bad developers, than it is worst than just one pair of eyes. There is no shortcut to competence.

                            Furthermore, the idea that the whole code can be reviewed bit by bit doesn’t make sense. You can have 20 patches that all look perfectly fine by themselves, but when you put them together are a disaster.

                            An experiment for anyone to try: gather the reject ration of your coworkers and compare with how you would rate them in terms of skill/competence. These are usually inversely proportional.

                            1. 1

                              White space, bracket style, indentation, style, naming conventions, linting and other secondary details always end up taking up like 75% of the work involved in code reviews.

                              Other than naming conventions, humans shouldn’t be wasting their time reviewing any of those things anyway; automated tools should be rejecting those things before a code review request even goes out.

                              On teams I’ve been on where we’ve had automated checks for machine-detectable violations of the project’s style conventions, code reviews have tended to stay much more focused on the stuff that matters.

                          2. 1

                            If you are ever in the situation where someone has spent time implementing something and their entire approach gets rejected at the final review stage you should absolutely not be patting yourself on the back for that. You need to immediately introspect about why your team process has spent time producing code that was fundamentally wrong from the beginning.

                            I’d agree strongly with this. Having implementation approach be part of the PR feedback cycle makes development inordinately time consuming and adversarial; technical approach needs to be either (ideally) ingrained into the day-to-day communication on your team through some mechanism like slack, daily sync meetings, etc. or else formally deliberated on before the time is spent to build a complete solution. It’s better to take the time to have a half an hour meeting than it is letting a two-day change be implemented in an unacceptable fashion.

                            1. 2

                              It’s better to take the time to have a half an hour meeting than it is letting a two-day change be implemented in an unacceptable fashion.

                              Doesn’t that depend on how often the problem happens? It is, I think, not better to have a few dozen half-hour meetings over the course of a year when you would only have prevented one or two rejected PRs. Those meetings don’t come at zero cost to the team.

                              1. 1

                                It does depend on how often the problem happens but I think the probabilities you’re implicitly assuming aren’t quite right (IME, ofc). Disagreements over approach at review stage are quite common if the person was not involved at the design stage, largely people there are just a lot of ways to do something. In the worst cases you will find a senior or lead developer will be too busy to attend design sessions but will sit as gatekeeper on PRs. That tends to lead to lots of rework and a very slow effective pace of improvement.

                                To make it explicit with some numbers: getting a design agreed usually only takes a 10-15 minute discussion between a 2-3 people, one of which can do it and one of which can review. If you skip that it I would say that you have a ~15% chance - and that’s conservative - of drama raised at review stage and rework. Solving for x, if your piece of work takes >5 hours, you should always have the design session. Obviously this is approximate maths, I just hope to give a sense of when the conversation is worthwhile and when it’s not.

                          1. 4

                            Go’s learning curve is amazing. I was writing real, useful code in Go in just a few hours and had successfully written a real, “large” application in a few days. It’s great.

                            It’s a shame that it seems like all the momentum is with Rust now. It almost feels like there’s no point in learning anything other than Rust given the trajectory of things…(I’m sad because I prefer Go to Rust).

                            1. 2

                              What momentum? I must be reading all the wrong sources of things, I don’t see Rust as on an upward trajectory myself (maybe I’m just biased), I don’t even see it on the TIOBE index where Go is at #14. :D

                              1. 2

                                Rust is at 26 right now. It’s jumped into the top 20 within the past year and jumped up and down.

                                The momentum I’m talking about is that Rust has been picked up by Microsoft as an acceptable language, Linus has intimated that he might be willing to allow Rust in the kernel, I’ve seen a lot of “why we switched Product X to Rust”, and so on. Go has been “stable” for over a decade now, so it’s got an enormous head start, but I feel like Rust is going to rapidly outpace it.

                                Again, they’re both fine languages, I just feel like I’m gonna need to learn Rust for the sake of my future career.

                                1. 3

                                  Rust will never have the “market adoption” of Go. Not to say it’s not worth learning! Or that it’s not the right tool for many jobs. It’s a great language.

                              2. 2

                                I think it depends on what you want to write and where you want to write it. A lot of big name companies are doing things in Go these days, it’s hardly fallen out of favor in that sense.

                                1. 2

                                  It’s a mistake to conflate online “buzz” with real momentum. I’d argue that Go has less buzz precisely because it has lots of momentum. Rust doesn’t have much momentum right now, it has acceleration.

                                  1. 1

                                    Rust doesn’t have much momentum right now, it has acceleration.

                                    That’s a really elegant way to put it.

                                    I do feel like every job posting/offer I come across has C/C++/Python/Rust listed, and not Go. I realize that there’s very likely selection bias at play given the kind of jobs I look at.

                                    EDIT: Okay, so yeah, perception vs reality. I went to Stack Overflow and did a job search. 109 for Golang, 18 for Rust (and I’m sure there’s overlap there).

                                  2. 1

                                    Go learning curve is smooth but it feel really like … work even if I only worked with it during a few months two years ago, that was the lasting impression Go made on me. It feel like a tool to get stuff done. The connotation is not negative but I don’t see myself use it for doing fun stuff on the side. Since that time, I want to take the time to learn more Go but for now I am waiting that Go2 drops because my knowledge is dated (never been exposed to go module at that time for example). It feels like a nice tool to have but I will not have fun creating with it.

                                    On the momentum side, Go still have a lot and Rust has gained a fair share of it but it really different field and for different reasons imho and for teams/companies with different needs and approaches. Nothing to be sad about, your hammer don’t have to fit every nail.

                                  1. 11

                                    Do you know either language?

                                    Use the one that you know.

                                    If you love working with Python, then I’d suggest Go. Rust would likely be too much cognitive overhead for little benefit.

                                    1. 5

                                      Interesting. I would have the exact opposite reaction. Go will make you think about raw pointers and that kind of thing, whereas rust you can write at a high-level like Python.

                                      Totally agree use the one you know unless you have a desire to learn a new one.

                                      1. 18

                                        If pointers are too much cognitive load then Rust’s lifetimes and ownership juggling is going to be way worse. I’d say that the comparison is more that Python and Go are not particularly functional languages, while Rust obviously is (and that’s the appeal of it to people who like functional languages).

                                        If Rust is faster for a given use case that’s a more like-for-like basis for comparison, but then you might want to use Fortran to go even faster depending on the use case. ;-)

                                        1. 4

                                          Admittedly I’ve invested time in becoming comfortable with Rust, but I actually concur – after gaining some familiarity, Rust feels much higher level than Go.

                                          1. 6

                                            Rust does can definitely operate at a higher level than Go, but it also has a lot more cognitive overhead.

                                        2. 5

                                          Pointers in Go are pretty trivial to work with, and I say this coming to Go from Ruby. Basically your only concern with points are “they can be nil,” otherwise you barely need to differentiate between pointer and structs if you’re writing idiomatically (that is a gross oversimplification and there are performance implications at times, but it’s extremely unlike C/C++ in this respect).

                                      1. 1

                                        I’d like an operating system I can run on a laptop that I can:

                                        • leave plugged in without the battery swelling
                                        • run google hangouts, zoom, goto meeting, and whatever other video conferencing tools I need for work and family
                                        • run slack
                                        • run 1password (or another non-lastpass password manager)
                                        • use a real package manager on
                                        • program in ruby, go, java, python, c, etc without horrendous amounts of pain

                                        I guess Ubuntu is my best bet? I still have yet to find a single linux-using coworker who can reliably join google hangouts video calls though (and I have no control over what video tool I use for work, but I CAN control my OS)

                                        1. 1

                                          Give Parrot OS a try.

                                          1. 1

                                            I’m guessing macOS is not on the cards?

                                            1. 1

                                              I mean, this is a Macintosh?

                                              1. 2

                                                I’m specifically frustrated with my nearly $3000 2018 macbook pro which has a swollen battery and cannot simultaneously handle a video call, slack and my IDE. I do recognize I’m being grumpy though.

                                                1. 2

                                                  lol fair enough.

                                                  1. 1

                                                    To be fair, that’s probably an issue with the video calling software, Slack, and your IDE. Though IDEs at least have an excuse for eating some resources.

                                                    My tip is to use Slack in a browser tab if you can, though this doesn’t allow you do call through it.

                                              2. 1

                                                I run Fedora on a Thinkpad and carry an iPad for slack and other text/video conferencing tools. Oddly enough, I landed here out of frustration with Apple laptops released since 2016. I’d been happily using Mac laptops since the ’90s, prior to that.

                                                The only place Fedora falls down for me (for the items on your list) is the reliability of conferencing tools. I’d say the ones you list are fine for me about 80% of the time, but soaking up the rest is worth the cost of the low-end iPad I use to do it. Hangouts/Meet, Zoom, Goto Meeting, Teams, etc. all work well there. Plus the camera is better and slack sucks less on iPad than anywhere else I used it. Slack and Discord don’t chew battery there they did on Mac and Linux, either.

                                                My non-lastpass password manager of choice is Bitwarden, fwiw. It did a decent job importing my large, very heavily used, 11-years-old (all my passwords since 2007!) 1password database, but there were quite a few empty entries to clean up after initial import.

                                              1. 7

                                                Having worked on a lot of Rails codebases and teams, big and small, I think this article is pretty spot on. Once your codebase or team is big enough that you find yourself getting surprised by things like

                                                counters = %i(one two three four five)
                                                counters.each do |counter|
                                                  define_method("do_#{counter}_things") do |*args|
                                                    # whatever horrible things happen here
                                                  end
                                                end
                                                

                                                etc… you’ve outgrown rails.

                                                1. 7

                                                  This is my litmus test for “has this person had to maintain code they wrote years ago”.

                                                  I don’t think I’ve yet worked with anyone who can answer yes but also wants me to maintain code that can’t be found via grep.

                                                  1. 3

                                                    What unholy beast is that. I mean. Seriously. Wtf is that?

                                                    1. 4

                                                      It’s gruesome, and I’ve seen a version of it (using define_method in a loop interpolating symbols into strings for completely ungreppable results) in at least 3 different large old codebases, where “large” is “50KLOC+” and “old” is “5+ years production”

                                                      There are a lot of ways to write unmaintainable code in a lot of languages/frameworks, but if I ever were to take a Rails job again, I would specifically ask to grep the codebase for define_method and look for this prior to taking the job. It’s such a smell.

                                                      1. 2

                                                        I don’t understand why it’s so normalized in rails to define methods in the fly. You could do that monstrosity easily in most interpreted languages, but there’s a reason people don’t! On Rails, it’s just normal.

                                                        1. 4

                                                          It’s been a long time since I’ve read the ActiveRecord source so it may no longer be this way, but there was a lot of this style of metaprogramming in the early versions (Rails 1.x and 2.x) of the Rails source, ActiveRecord in particular, and I think it influenced a lot of the early adopters and sort of became idiomatic.

                                                    2. 1

                                                      Who the fuck writes code like this?

                                                      shudders

                                                      1. 1

                                                        The time between “just discovered ruby lets you do that” and “just realized why I shouldn’t” varies from person to person; I’ve seen it last anywhere between a week and a year.

                                                    1. 1

                                                      I don’t understand why you wouldn’t want a timeout for the secondary request… But, naturally, this functionality is not exposed (in the context pkg), and the cancellation aspects are a bit tricky…

                                                      1. 1

                                                        One reason is if you’re delegating asynchronous calls (something with side effects, say a cleanup process) but still want to preserve the original context for observability/tracing purposes.

                                                        1. 1

                                                          SOOOO. I think the thing I missed is that you can still context.WithCancel() on this dummy context. So, nothing should be lost..

                                                      1. 6

                                                        Hey, this is a really interesting problem that i think lots of companies hit without noticing, however i think there are simpler ways of tackling it, i figured i could give a few pointers on how your code might be simpler and smaller.

                                                        Firstly with your DisconnectContext you can eliminate stubbing a lot of your fields by embedding the parent context rather than stubbing them eg:

                                                        type DisconnectContext struct {
                                                            context.Context
                                                        }
                                                        

                                                        then only overriding methods you need to change the behaviour of (https://golangbyexample.com/embedding-interfaces-go/).

                                                        edit: i just deleted some stuff about wrapping in another WithCancel to avoid the DisconnectContext from this comment because i was wrong!

                                                        here’s the example i used to prove myself wrong : https://play.golang.org/p/ynNwc-otFGO

                                                        1. 5

                                                          Thanks! I intentionally didn’t use embedding so that I could explicitly show the delegation of Value to the parent. Otherwise, that would be the only method missing from the impl and might be lost to the reader.

                                                          1. 2

                                                            This is roughly what we do at DO. The main thing is that your DisconnectContext wraps its parent but noops on Done()

                                                          1. 9

                                                            The case against OOP is not that it is impossible to write good OO code, but that OOP encourages people to abuse bad design and bad patterns, which the author seems to concede. The article makes an argument similar to someone who says it’s possible to write eg Ruby without type errors: of course it’s possible, but the language makes it harder than other languages, which is the whole brunt of the criticism.

                                                            1. 9

                                                              That only holds if you’re defining OOP to be something like Java circa 2000.

                                                              If you want to say “Java circa X encourages bad design”, I would concede that (see my other comment in this thread).

                                                              I would not concede “OOP encourages bad design”, because the space is so big and there are simply too many programs under that umbrella.

                                                              You could similarly define FP to be the subset of FP that allocates too much memory, is slow, and hard to modify, but that wouldn’t make much sense either.


                                                              I’ll point back toward the same comment: OOP and FP have largely converged – they are both about being principled about state and I/O, and not littering it all over your code.

                                                              https://lobste.rs/s/lwopua/functional_code_is_honest_code#c_twssec

                                                              “Immutable objects” were a thing 15 years ago and continue to be – and to not acknowledge that is like not acknowledging anything that’s happened in functional programming in 15 years (e.g. think Haskell or OCaml 15 years ago).

                                                              I understand that some people are still working with bad old codebases designed before that period. I think that is just the curse of “being used”, a la Bjarne Stroustrop (there’s 2 kinds of languages: the ones people don’t complain about and the ones people use).

                                                              1. 4

                                                                That only holds if you’re defining OOP to be something like Java circa 2000.

                                                                I think it holds pretty true of Rails in 2020 as well - idiomatic rails is a giant conflation of behavior and state where every model/controller/etc inherits from a framework class.

                                                                1. 2

                                                                  OK I don’t have any experience with Rails, but that doesn’t surprise me too much. I am more of a Python person, and Ruby code definitely seems to lean more on classes/objects, for a better or worse.

                                                                  I like this comment: https://news.ycombinator.com/item?id=24012090

                                                                  If there is anything in CS which should be renamed simply because people have completely incorrect assumptions from the name, it’s OOP. Everyone has someone different they think about it, and almost none of it has anything to do with late-binding, encapsulation, or message passing.

                                                                  Basically I think it is more useful to criticize Java or Rails specifically, rather than OOP, which is a big nebulous concept. (And ironically I don’t even agree that those are the 3 main things about OOP :) )

                                                                  Although Java and Rails may share some problems with regard to maintainability, I also think they have completely distinct problems as well. Putting dynamically typed OO and statically typed OO under the same umbrella and making statements about them does seem like a stretch to me.

                                                                  1. 2

                                                                    Basically I think it is more useful to criticize Java or Rails specifically, rather than OOP, which is a big nebulous concept. (And ironically I don’t even agree that those are the 3 main things about OOP :) )

                                                                    Those things quoted are not the 3 main things about OOP. The main things about OOP are inheritance, polymorphism, encapsulation and abstraction. (https://www.oreilly.com/library/view/vbnet-language-in/0596003080/ch04s02.html) At some point when you start defining OOP as not-these-things you’re just committing a “no true Scotsman” fallacy. And it’s entirely fair to criticize a language based on its dominant idioms and paradigms: writing code based around mutable state and subtype polymorphism isn’t just something you CAN do in Java or Ruby, it’s what you’re largely expected to do. The fact that even these languages have recently provided mechanisms to avoid doing this isn’t a counterargument to “OOP is bad”, it’s evidence that even mainstream OOP languages can’t sustain large professional codebases with the design patterns foisted by the overwhelming tendency of the respective ecosystems.

                                                            1. 3

                                                              My take is that the claimed advantages are not really delivered by OOP. From the website:

                                                              • Encapsulation: Most OOP languages leak trivially avoidable implementation details to the caller (like whether some member is a field or a no-arg method).
                                                              • Inheritance: Usually not that useful.
                                                              • Polymorphism: Parametric polymorphism is often superior to OOP’s subtype polymorphism.

                                                              I don’t have anything against OOP, but it is definitely oversold.

                                                              In the end, just stop making everything mutable, and I can largely live with it.

                                                              1. 0

                                                                In the end, just stop making everything mutable, and I can largely live with it.

                                                                I largely agree with this sentiment, but I feel that since objects are essentially a behavior/mutable state combination, this sentiment is also very anti-OOP.

                                                                1. 4

                                                                  Object-oriented design does not imply mutability, but rather most implementations of OO feature it as the fusion of behavior and mutable state. As you mentioned, this creates the perception that OO must be implemented this way. (In fact, few languages even take mutability seriously enough until very recently!)

                                                                  OTOH, most languages feature immutable String classes in their standard library, and there’s nothing non-OOP-y about them. They’re fundamentally values, and have the semantics of values by being immutable. OOP is not opposed to value semantics. IMO, the sweet spot of OOP is defaulting to values everywhere, with a few islands of mutable state loosely connected together (see Gary Bernhardt’s Boundaries talk for further discussion).

                                                              1. 12

                                                                I don’t generally look at programmers as personally inspirational or “heroes” (not out of cynicism, but mostly just because programming is a career to me and a career is only a part of a meaningful life) but antirez is the first exception I always make. I remember getting started in the field professionally a decade ago working with redis, reading stackoverflow questions, and seeing replies from him to nearly all of them - it still blows my mind how he could be seemingly singlehandedly the author, designer, and community support for such a ubiquitous thing. A prolific coder who genuinely put himself into redis (which has been useful for me my entire career including as recently as this week). Kudos to a job well done!

                                                                1. 1

                                                                  I’m noticing it today for the first time. I’ve made a few (trivial) contributions to the source code before and can say the developer experience is pretty painless if you’ve worked with Rails before, so don’t be afraid to jump in if anyone has bandwidth.

                                                                  1. 3

                                                                    I think it’s either an infrastructure or database issue, not something inherent in the application.

                                                                  1. -1

                                                                    Can anyone recommend some material describing concrete motivations for adding generics to Go? I’m aware of the abstract idea that you need generics in order to build data structures that work with different types, but is there a real-world setting where this is actually better than just copying code and doing s/type1/type2/g? My sense is that projects that use complex data structures almost always customize the data structures in a way that depends on the data type being stored.

                                                                    1. 19

                                                                      I hope it’s not that hard to imagine wanting different data structures than hash maps; maybe your problem fits better into a binary search tree for example.

                                                                      Well, I for one usually don’t feel like implementing my own red-black tree, so I would like to just grab a library. That library will be much nicer to use if I can just make an RBTree<string, MyFoo>. I certainly wouldn’t want to copy/paste an int->string red-black tree into some file(s) and judiciously search/replace until I have a string->MyFoo tree (and then do the same when I need an int->float tree).

                                                                      1. 0

                                                                        That makes sense, but I am still looking for some grounding in actual programming practice. Is there a use of a red-black tree that would not warrant customizing it for the storage type? Or one where it would make sense to add a library dependency rather than copying the RB tree code?

                                                                        1. 8

                                                                          How do you write a library that provides a Red-Black tree that can in principle work with many different client types without generics? This isn’t a rhetorical question, I don’t know Go and I genuinely don’t know how you would implement this kind of library in Go without generics.

                                                                          1. 6

                                                                            Go’s sync.Map (concurrent hashmap) is an actual real world example of this, and it uses interface{}, akin to Java’s Object.

                                                                            1. 25

                                                                              Right, that’s a great example. Because it uses interface{}, it:

                                                                              • Requires all keys and values to be heap allocated, leading to worse performance, worse memory usage, and worse memory fragmentation. Requiring two heap-allocated ints to store one value in an int->int concurrent hash map is unacceptable for many uses.
                                                                              • Is less ergonomic, requiring a cast every time you want to use a value.
                                                                              • Provides no type safety. (I imagine this one will be the least convincing to Go programmers, since Go generally expects the programmer to just not make mistakes)
                                                                              1. 4

                                                                                This brings me back to C++Builder 3 back in the 90s. To use a list, you had to create a class derived from a kind of TItem class to be able to store things. Why anyone would want to go back to that in productive code boggles my mind.

                                                                                1. 1

                                                                                  I’m using a sync.Map (for its concurrency support - I have many goroutines writing map entries, and another goroutine periodically ranging over the entire map to dump it to a json file).

                                                                                  However I know the types I write to the map, I have no need for interface{}.

                                                                                  Am I better off with a real typed map + using sync.RWLock/mutex/etc. directly (in a custom struct)? Performance-wise.

                                                                                  1. 1

                                                                                    I don’t know, you would have to benchmark or measure CPU or memory usage. The sync.Map documentation suggests that using a regular map + mutexes could be better though: https://golang.org/pkg/sync/#Map

                                                                                    The Map type is specialized. Most code should use a plain Go map instead, with separate locking or coordination, for better type safety and to make it easier to maintain other invariants along with the map content.

                                                                                    The Map type is optimized for two common use cases: (1) when the entry for a given key is only ever written once but read many times, as in caches that only grow, or (2) when multiple goroutines read, write, and overwrite entries for disjoint sets of keys. In these two cases, use of a Map may significantly reduce lock contention compared to a Go map paired with a separate Mutex or RWMutex.

                                                                                    If your usage falls outside of the two use cases which sync.Map is optimized for, it would absolutely be worth looking into replacing your sync.Map with a regular map and a mutex.

                                                                                    I suppose it becomes a question of which has the biggest performance penalty for you, heap allocation + indirection with sync.Map or lock contention with regular map + mutex?

                                                                                    (Also, in most cases, this probably doesn’t matter; make sure you’re not spending a long time improving performance in a part of your code which isn’t actually a performance issue :p)

                                                                                    1. 1

                                                                                      Right - the code “just works(TM)” and it takes around 0.5 seconds to render the JSON file every minute (which I track with metrics just to be safe) so it should be fine to keep as is. This is just a for-fun conversation.

                                                                                      or (2) when multiple goroutines read, write, and overwrite entries for disjoint sets of keys. In these two cases, use of a Map may significantly reduce lock contention compared to a Go map paired with a separate Mutex or RWMutex.

                                                                                      I definitely remember reading this sentence and it made me choose sync.Map because it sounds like my usecase. But like you say if I don’t measure it’ll be hard to tell.

                                                                              2. -1

                                                                                I don’t know and I didn’t think you could. I’m asking for an example use of an RB tree where using a library would make sense.

                                                                                1. 6

                                                                                  Here is a popular Go RB tree implementation https://github.com/emirpasic/gods/ that uses Interface{} for the key and value types. Just search github for uses of it… With generics, users of this library would get greater typesafety.

                                                                                  https://github.com/search?q=%22github.com%2Femirpasic%2Fgods%2Ftrees%2Fredblacktree%22&type=Code

                                                                                  1. -2

                                                                                    okay. except i don’t know how to search github for uses of it and your search link brings me to a login page :(

                                                                                    1. 5

                                                                                      To short-circuit this:

                                                                                      At a previous job, I worked on a tool that started various services. The services had different dependencies, each of which needed to be started before the service. We wanted to be able to bring them up with as much parallelism as possible, or have a flag to launch them serially.

                                                                                      A simple approach to doing this correctly is modeling the dependencies as an acyclic graph (if it’s a cyclic graph, you’ve got a problem — you can never bring the services up, because they all depend on each other). To launch them in parallel, launch each one that has its dependencies met. To launch them serially, topologically sort the graph into an array/list/whatever and launch them one by one.

                                                                                      A generic graph implementation would be very useful, as would a topological sort that worked on generic graphs. With Go, you can’t have one that’s type-safe.

                                                                                      Another great use case for graphs: visualizing dependency graphs! You can have an open source graph visualization library, build a graph of whatever it is you’re trying to visualize, and pass it to the library and get a nice visualization of the data.

                                                                                      Graph data structures can be quite useful. Supporting generics makes them type-safe, so you catch errors at compile time instead of runtime. Some other examples of the usefulness of graphs:

                                                                                      • Graphs of friends at a social network (I currently work at one, and we use generic graph data structures all over the place — graphs of people to people, graphs connecting people and photos they’re tagged in, etc)
                                                                                      • Network topology graphs
                                                                                      • Graphs of links between documents

                                                                                      etc.

                                                                                      And it’s not just graphs. How do you write a type-safe function that takes in a list of possibly-null items, and returns a new list with the nulls stripped out? How about a function that takes a map and returns the list of its keys? In Golang, the answer is always copy-paste or give up type safety. In languages with generics, you can trivially write these functions yourself if they’re not in the standard library.

                                                                                      1. 1

                                                                                        thanks, this is a good motivating example.

                                                                                      2. 1

                                                                                        Huh. It had not occurred to me that github search would require a login.

                                                                              3. 11

                                                                                To turn the question around, why would you want to manually copy/paste code all over the place when the compiler can do it for you? And while I personally think “DRY” can be over done, not having the same (or very similar) code copy/pasted all over the place seems like a big practical win.

                                                                                As far as customizing specific data structure and type combinations, most languages with generics have a way to do that, and I’d bet the Go designers thought of it.

                                                                                1. 2

                                                                                  Copy / paste has got it’s own problems, but it lets you avoid a ton of complexity in the toolchain.

                                                                                  Toolchain development is all about tradeoffs. For instance, I use Typescript; the reference implementation is featureful, but slow to boot, so it keeps a background process alive to cache the heavy lifting, which accumulates state and introduces subtle confusions (eg type errors that don’t exist) until it’s restarted.

                                                                                  For some problem spaces, the problems introduced by copy/paste pale in comparison to the problems introduced by slow, stateful compilers.

                                                                                  1. 7

                                                                                    Copy/paste vs generics is unrelated to compiler bugginess.

                                                                                    If you carefully pick TypeScript as the comparison point, you can make the case that a buggy toolchain is bad (not that most users care, they just restart the compile process when it starts to go bad).

                                                                                    But if you were to pick say ReasonML for comparison, you could say that it’s possible to have a solid generics implementation (much less copy-pasting) and a super-fast, accurate compiler.

                                                                                    I.e. you can have both buggy and non-buggy compilers supporting generics. Hence, unrelated.

                                                                                    1. 2

                                                                                      ReasonML is great!

                                                                                      That said, while the relationship is indirect, it’s there. Adding complexity is never free. It didn’t cost ReasonML speed or reliability, but it costs maintainers time and makes every other feature more difficult to add in an orthogonal way.

                                                                                      1. 2

                                                                                        I think these comparisons are a bit unfair: isn’t Typescript self hosted, whereas ReasonML is written in OCaml? It seems like Typescript would have a very hard time competing.

                                                                                        1. 3

                                                                                          Being able to use lots of existing OCaml bits is a huge advantage.

                                                                                          Typescript has been able to compete due to the sheer number of contributors - MS pays quite a large team to work on it (and related stuff like the excellent Language Server Protocol, VScode integration).

                                                                                          However, large teams tend to produce more complex software (IMO due to the added communications overhead - it becomes easier to add a new thing than find out what existing thing solves the same problem).

                                                                                          1. 1

                                                                                            I should clarify my comment was more about comparing performance of the two languages.

                                                                                            OCaml is a well optimized language that targets native machine code so tooling built in OCaml should be more performant than tooling built in Typescript. As a result, it’s hard to compare the complexity of either tool by the performance of the tool. It’s apples and oranges.

                                                                                          2. 2

                                                                                            isn’t Typescript self hosted, whereas ReasonML is written in OCaml? It seems like Typescript would have a very hard time competing.

                                                                                            That’s a strange argument. If it were very hard for them to compete why would they not use OCaml as well, especially since its contemporary alternative, Flow, was written in OCaml too? Or why would they not make TypeScript as good as a language for writing TypeScript in as OCaml is?

                                                                                            1. 1

                                                                                              My comment was more about performance, but it wasn’t very clear. It’s hard for Typescript, which is compiled to Javascript and then interpreted/JITed, to create tooling that’s as fast as a language that builds optimized native code.

                                                                                              Given that Typescript is self hosted it has the advantage that community involvement is more seamless and I don’t want to downplay the power that brings.

                                                                                          3. 2

                                                                                            In the scheme of things, is it more important to have a super-simple compiler codebase, or is it more important to put more power and expressiveness in the hands of users? Note that every mainstream language that started without generics, has now added it.

                                                                                            1. 1

                                                                                              IMO, there’s such a thing as a right time to do it.

                                                                                              In the early years it’s more important to keep the simplicity - there aren’t that many users and you’re still figuring out what you want the language to be (not every feature is compatible with every approach to generics).

                                                                                              Once you’re ready to start generics you need to answer questions like - do you want monomorphisation or lookup tables? Is boxing an acceptable overhead for the improved debugging ergonomics?

                                                                                              1. 1

                                                                                                It seems like Go has been going through exactly the process you’re describing.

                                                                                          4. 0

                                                                                            But compilers that support generics are more likely to be buggy. That’s a relation.

                                                                                            1. 2

                                                                                              Any source for this rather surprising assertion?

                                                                                              1. 0

                                                                                                generics are feature that requires code to implement; code can contain bugs.

                                                                                                1. 1

                                                                                                  But a self-hosting compiler with generics is likely to be less verbose (because generics) than one without, so it should be less buggy.

                                                                                                  1. 1

                                                                                                    i guess you can’t prove it either way but IME the complexity of algorithms is more likely to cause bugs than verbosity.

                                                                                          5. 5

                                                                                            I think Typescript is a straw man. Does this Go implementation of generics slow down the compiler a noticeable amount? There’s nothing inherent to generics that would make compiling them slow.

                                                                                            On the other hand, copy/pasted code is an ever increasing burden on developer and compile time.

                                                                                          6. -2

                                                                                            You are imagining a code base where the same complex data structure is instantiated with two different types. Is that realistic?

                                                                                            1. 6

                                                                                              You are imagining a code base where the same complex data structure is instantiated with two different types. Is that realistic?

                                                                                              Realistic enough that the Linux kernel developers went through the hassle of developing generic associative arrays, circular buffers, and other generic data structures using void*.

                                                                                              And so did Gnome with GLib, which provides generic lists, hash tables, and trees, along with several others structures, also using void*.

                                                                                              And the standard libraries of most modern languages include reusable and generic sequence and associative data types, and some times significantly more than that.

                                                                                              For most data structures, though, focusing on a single code base gives too narrow of a view. Generics allow libraries of data structures to be created, so even though a single code base only use one R* tree (or whatever), that R* tree library can be used as-is by any number of projects.

                                                                                          7. 8

                                                                                            The Abstract and Background sections of the draft design doc touch on the motivations. Additionally, each section describing a dimension of the design usually mentions, at least briefly, the motivation for that feature.

                                                                                            1. 8

                                                                                              Here is an example that I’ve wanted for ever, and can finally do. Higher order combinators that you can leverage first class functions with!

                                                                                              Generic map, in go

                                                                                              1. 1

                                                                                                That’s the type of thing I have seen as a justification, but I don’t get why that’s so important. Can’t you just use a for loop?

                                                                                                1. 22

                                                                                                  “Can’t you just …” goes forever. “Can’t you just write your for loop with labels and jumps in assembly?”^^

                                                                                                  For me, it’s all about abstraction. Having low level combinators, like this, that I can compose to build higher level abstractions in a generic way is wonderful.

                                                                                                  ^^: See also whataboutism.

                                                                                                  1. 3

                                                                                                    I’m not sure that composing from higher level abstractions is always such a good idea. I like both Go (hobby projects) and Rust (work!) but I still fell that most of the time I prefer this level of abstraction:

                                                                                                    type Server struct {
                                                                                                    ...
                                                                                                        Handler Handler // handler to invoke, http.DefaultServeMux if nil
                                                                                                    ...
                                                                                                    }
                                                                                                    type Handler interface {
                                                                                                        ServeHTTP(ResponseWriter, *Request)
                                                                                                    }
                                                                                                    

                                                                                                    from this:

                                                                                                     pub fn serve<S, B>(self, new_service: S) -> Server<I, S, E>
                                                                                                        where
                                                                                                            I: Accept,
                                                                                                            I::Error: Into<Box<dyn StdError + Send + Sync>>,
                                                                                                            I::Conn: AsyncRead + AsyncWrite + Unpin + Send + 'static,
                                                                                                            S: MakeServiceRef<I::Conn, Body, ResBody = B>,
                                                                                                            S::Error: Into<Box<dyn StdError + Send + Sync>>,
                                                                                                            B: HttpBody + 'static,
                                                                                                            B::Error: Into<Box<dyn StdError + Send + Sync>>,
                                                                                                            E: NewSvcExec<I::Conn, S::Future, S::Service, E, NoopWatcher>,
                                                                                                            E: H2Exec<<S::Service as HttpService<Body>>::Future, B>,
                                                                                                        {
                                                                                                        ...
                                                                                                    

                                                                                                    Don’t get me wrong, i like type level guarantees and I can see flexibility here, but in my experience with c++, rust and haskell is that generic programming often ends up complicating things to a degree that I personally don’t like.

                                                                                                    1. 1

                                                                                                      I think this is going to be a balance that the community has to find. I don’t regularly program in rust, but I’d be quite surprised if it wasn’t possible to get something close to the Go http API in it. The example you pasted seems complicated for the sake of being complicated. In theory, the Go community has been drilled into thinking in terms of the littlest abstraction that’ll work, which maybe makes it possible to generally avoid generic APIs that don’t actually need to be?

                                                                                                    2. 3

                                                                                                      “Can’t you just” does not go forever. It is a simpler way to say that the alternative is not significantly harder than what’s proposed. Is there some type of task that would be doable using a generic map but unreasonably hard using for loops?

                                                                                                      I feel like Go was designed from the ground up to be written in an imperative style, and composing first order functions is more of a functional style of coding. If I understand, without generics you would be nesting for loops rather than composing map functions, which is no more difficult to understand or write.

                                                                                                      I don’t follow the connection to whataboutism.

                                                                                                      1. 2

                                                                                                        I think it’s fine for your style of writing code to be to use loops and conditionals instead of map and filter. I think it’s a fine way to code that makes more sense in an imperative language. Straight for loops and while loops with if statements inside them is just better, more easily understandable code in an imperative language, in my opinion, than .map(...).filter(...).map(...) etc.

                                                                                                        1. -1

                                                                                                          Incidentally there is a repo wherein Rob Pike expresses his attitude towards this style of coding:

                                                                                                          https://github.com/robpike/filter/

                                                                                                          I wanted to see how hard it was to implement this sort of thing in Go, with as nice an API as I could manage. It wasn’t hard.

                                                                                                          Having written it a couple of years ago, I haven’t had occasion to use it once. Instead, I just use “for” loops.

                                                                                                          You shouldn’t use it either.

                                                                                                          1. 2

                                                                                                            I mean… that’s like … one man’s opinion… man. See also.

                                                                                                            Generics are going to create a divide in the Go community, and it’s going to be popcorn worthy. There’s no point of adding Generics to the language if this filter thing “shouldn’t be used,” and the community rejects the abstractions that Generics provide.

                                                                                                            This divide is easily already seen in the community as it relates to test helpers. On the one hand, there’s a set of developers that say “stdlib testing is more than enough.” On the other hand, there are people who want the full testing facilities of junit, with matchers, lots of assert style helpers, etc. Who is right? They all are, because those things work for their respective teams and projects.

                                                                                                            This general dogmatic approach to language idioms is why I call it “idiotmatic” Go.

                                                                                                            1. -1

                                                                                                              I suppose if Ken and Rob wanted generics they would’ve put them in the original language, and there wouldn’t be this controversy. Time to go back to learning Erlang which seems old and dusty enough to not have big language changes and drama.

                                                                                                        2. 16

                                                                                                          You can’t pass a for loop to anything, you can only write it where you need it. Sure, toy examples look like toy examples, but the fact remains that Go has first-class functions, which should be a nice thing, but it doesn’t actually have a type system rich enough to express 90% of the things that make first-class functions worth having.

                                                                                                          1. -1

                                                                                                            You can’t pass a for loop to anything, you can only write it where you need it.

                                                                                                            right, so the example code could be done with a for loop no problem. is there a more motivating example?

                                                                                                            it doesn’t actually have a type system rich enough to express 90% of the things that make first-class functions worth having.

                                                                                                            how do you mean?

                                                                                                          2. 3

                                                                                                            Consider composing multiple transformations and filters together. With multiple for loops you have to iterate over the array each time, while by composing maps you only need to iterate once.

                                                                                                            1. 3

                                                                                                              Just compose the operations inside the loop.

                                                                                                              for x in y:
                                                                                                                  ...f(g(x))...
                                                                                                              
                                                                                                              1. 2

                                                                                                                That works in some cases, but it’s pretty easy to find a counter example, too.

                                                                                                        3. 7

                                                                                                          In terms of collections, the truth is most of the time a map/slice is a good option. Here’s my top two favorite use cases for generics in go:

                                                                                                          1. Result<T> and functions that compose over them.
                                                                                                          2. Typesafe versions of sync.Map, sync.Pool, atomic.Value, even a rust like Mutex
                                                                                                          1. 5

                                                                                                            Oh man. I hadn’t even considered a better way to do error handling, eg. a Result type. People are gonna get so mad.

                                                                                                            1. 5

                                                                                                              Generics isn’t enough to do what people want to do with error handling 99.99% of the time, which is to return early. For that, you either need a macro, such as the aborted try proposal, or syntactic sugar for chaining such “functions that compose over them” (like Haskell’s do notation).

                                                                                                              Otherwise you end up with callback hell à la JavaScript, and I think nobody wants that in Go.

                                                                                                              1. 4

                                                                                                                I was more thinking of something where the if err pattern is enforced via the type system. You’re still not getting there 100%, you could get reasonably close, with a generic Result type that panics when the wrong thing is accessed, forcing you to check always or risk a panic.

                                                                                                                r := thing()
                                                                                                                if r.HasError() { handleError(r.Err()) }
                                                                                                                else v := r.Val() { handleSuccess(v) }
                                                                                                                

                                                                                                                And of course it’s easy to question why this is interesting until you do chaining of things, and get a full on, type safe Result monad.

                                                                                                                r := thing().andThen(func(i int) { ... }).andThen(func(i int) { ... })
                                                                                                                if r.IsErr() {
                                                                                                                   handleErrForWholeComputation(r.Err())
                                                                                                                } else {
                                                                                                                   handleSuccessForWholeComputation(r.Val())
                                                                                                                }
                                                                                                                

                                                                                                                The alternative can be seen in things like this where you skirt around the fact that you can’t generically accept a value in one of those called functions. This is also why I said people are going to get so mad. These things are confusing to people who haven’t dealt with them before, and will make Go much more expressive, but less easy to grok without effort.

                                                                                                          2. 5

                                                                                                            but is there a real-world setting where this is actually better than just copying code and doing s/type1/type2/g

                                                                                                            All of them. Copying code manually is one of the worst things you can do in software development. If it weren’t, why even bother writing functions, ever?

                                                                                                            My sense is that projects that use complex data structures almost always customize the data structures in a way that depends on the data type being stored.

                                                                                                            The fact that libraries exist that don’t customise in such a way in languages with generics would disprove that notion.

                                                                                                            1. 6

                                                                                                              one of the worst things you can do in software development

                                                                                                              For me that’s “making things unreadable for whoever comes after you”. And sometimes copying a bit of code is the optimal solution for avoid that.

                                                                                                              1. 0

                                                                                                                but is there a real-world setting where this is actually better than just copying code and doing s/type1/type2/g

                                                                                                                All of them. Copying code manually is one of the worst things you can do in software development. If it weren’t, why even bother writing functions, ever?

                                                                                                                I disagree with your implication that the use of functions means code should never be copied. For example if you want to use strlcpy() in a portable C program, it makes more sense to put a copy in your source tree rather than relying on an external library. An extra dependency would add more headache than just copying the code.

                                                                                                                My sense is that projects that use complex data structures almost always customize the data structures in a way that depends on the data type being stored.

                                                                                                                The fact that libraries exist that don’t customise in such a way in languages with generics would disprove that notion.

                                                                                                                That’s why I said “almost always.” And remember that the existence of a library doesn’t mean it is used with any frequency.

                                                                                                              2. 3

                                                                                                                Suppose you have a structure parametrizable by types T1, T2. You’re writing it in Go, so you assume that it’s ok if T1=string, T2=int. Also, in some of the places, you were using int for purpose unrelated to T2 (ie. if T2=foo, then there are still ints left in the source). Another programmer wants to copy-paste the code and change some types. How does he do it?

                                                                                                                1. 2

                                                                                                                  I think “this would make copy-pasting code harder” is not so compelling an argument. One of the major points of introducing generics is that it would eliminate much of the present need for copy/paste in Go.

                                                                                                                  1. 2

                                                                                                                    Yes it would be harder than a search-and-replace, but that is still abstract and unrelated to any real-world use case.

                                                                                                                    Yes, I’m just counterpointing the parent commenter’s argument. I know the value of generic structures.

                                                                                                                  2. -1

                                                                                                                    Yes it would be harder than a search-and-replace, but that is still abstract and unrelated to any real-world use case.

                                                                                                                1. 22

                                                                                                                  I understand a lot of these articles may be largely backlash against the surge in popularity of dark mode, but I think this misses the point. “Is dark mode such a good idea?” Letting people choose how they visit your website is a good idea. You can’t know how all of your users work, what the light is like in their residence, what their eyes are like, what hours they are on the computer. Give them a choice. I greatly appreciate things like chrome dark reader that let me easily toggle between dark and light modes, and I used to have an emacs configuration to do this with my editor themes. When it’s dark where I am and I’m on the computer, bright screens hurt my eyes. When it’s light out I am and I’m on the computer, dark screens hurt my eyes. I have sensitive eyes and a family history of eye problems. I don’t really care what someone else thinks about the trendiness or aesthetics of my choices, I just want my eyes not to hurt. Please stop opining on the subject and just provide a theme that works for both setups and an easy way to choose.

                                                                                                                  1. 7

                                                                                                                    From OP:

                                                                                                                    I’m sure there are people out there who genuinely need dark mode for a specific health condition. For that reason, there will continue to be a dark mode on this site.

                                                                                                                    1. 3

                                                                                                                      Post author here (thanks to the person who posted this by the way). I end the post by saying that there are likely to be people who require dark mode…or just prefer it. For that reason, my site does support prefers-dark-mode and will adapt if you’re using a dark OS theme.

                                                                                                                    1. 10

                                                                                                                      “But how do you know appeal to authority is bad?” “Because Carl Sagan said so!”

                                                                                                                      1. 7

                                                                                                                        That’s just a quote. She could have left it out and the point would still stand intact.

                                                                                                                        Appeal to authority is flawed because we are talking about engineering. And in that context, appeal to authority is the conceptual opposite of science. As an engineer, you do something because you have technical knowledge and you can predict the results running the numbers using algorithms based on scientific knowledge. This applies to a codebase or a programming stack. If you use it because you have technical motivations to do so, you are aware of the advantages and disadvantages. From the moment you start using this because “Facebook|Google|Netflix|amazon” did it and they must be right”, you are putting the technical aspects of your choices to a secondary plan, and walking right into the pitfalls.

                                                                                                                        1. 4

                                                                                                                          I don’t know if in this case the irony was deliberate, but it reminds me of the beautiful (and quite intended)

                                                                                                                          Isn’t it rather amusing that to this day the most serious philosophers, however strict they may be in questions of certainty, still call on what poets have said in order to lend their ideas force and credibility? And yet it is more dangerous for a truth when a poet agrees than when he contradicts it. For as Homer says: “Many lies tell the poets.”

                                                                                                                        1. 6

                                                                                                                          In the issue comments I found repeatedly a proclamation that „All software is political“.

                                                                                                                          This is generally not true. There might be some „political“ software, but usually software is simply a tool. It is not good or bad* – it can be used for good or bad or neutral purposes, just depending on who and how is using that software.

                                                                                                                          And there is also software or development style that is explicitly apolitical – Sane software manifesto says:

                                                                                                                          In order to contribute, it must not be required: … to sign any political, religious or other proclamation or agree with it.

                                                                                                                          P.S. Yes, free software has some political undertone, or I would rather say ethical, but it is very strictly defined and there are clear boundaries that prevent bending and misusing this term. Free software can be used by anyone for any purpose.

                                                                                                                          *) now I am not talking about code quality, but about the ethical dimension

                                                                                                                          1. 13

                                                                                                                            The inception of the Free Software movement was inherently political, and the recuperation of that movement into a more business-friendly Open Source movement was also political. Licensing software using a FLOSS license is a political act.

                                                                                                                            1. 2

                                                                                                                              Yet the success of the open-source movement in relation to the failure of the free software movement (at least, according to their goals) is almost 100% due to the FSF’s politics. Companies would rather use open-source software rather than free software because there’s less legal bullshit to go through. Additionally, companies have been less inclined to license their own software with the GNU GPL and have chosen alternative licenses that are more permissive and don’t place so much burden on the author to “give credit where credit is due”.

                                                                                                                              I love the FSF, GNU, and the movement it all stands for. But in my opinion, the world has mostly left that concept of “freely available software that you have total control over” behind. Especially in the current “rental” climate where less software is actually owned by a user.

                                                                                                                              1. 5

                                                                                                                                Companies would rather use open-source software rather than free software because there’s less legal bullshit to go through.

                                                                                                                                You use company adoption as the yardstick for success here but I would counter that it is entirely irrelevant to the political goals of Free Software.

                                                                                                                                (P.S. my use of the word recuperation above was deliberate.)

                                                                                                                                1. 3

                                                                                                                                  Open source is hardly a success. It’s companies struggling over control of software for their own interest (that very often is not aligned with the interest of the community) or bright people working for free for companies and be happy about the theft of time and energy. Corporate adoption and investments for control is their own metric of success but arguagly one that reflects the wellbeing of the commons.

                                                                                                                                  1. 4

                                                                                                                                    hardly a success

                                                                                                                                    What? This makes very little sense. Most of the software running the Internet is open source. Throw a dart at the list of top 100 tech companies, they’ve probably open sourced major libraries that have gone on to spawn entire industries.

                                                                                                                                    The Linux kernel, ffs.

                                                                                                                                    I’m confused at your argument. What is it you define as “success?” Adoption? Growth? Longevity? Monetary return?

                                                                                                                                    1. 3

                                                                                                                                      Be useful to people, solve problems in the real world (ideally problems that aren’t created other open source software), make the world a better place.

                                                                                                                                  2. 0

                                                                                                                                    ‘Free’ and ‘open source’ are synonyms. Companies don’t use open source software instead of free software. Using open source software is using free software. Using free software is using open source software.

                                                                                                                                    Copyleft and permissive software licenses are all both free software licenses and open source software licenses.

                                                                                                                                    1. 2

                                                                                                                                      No, they are not synonyms. Free software does no need to be gratis, nor does open source software imply that you have the freedom to change and distribute that software - even in exchange for money - like free software gives you. This distinction has been made clear so many times by now that it is surprising to see the claim that these two are synonyms.

                                                                                                                                      1. 1

                                                                                                                                        No, they are not synonyms. Free software does no need to be gratis

                                                                                                                                        Nor does open source software.

                                                                                                                                        nor does open source software imply that you have the freedom to change and distribute that software

                                                                                                                                        Yes it absolutely does imply that you have the freedom to change and distribute that software. The Open Source Definition requires:

                                                                                                                                        “The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.”

                                                                                                                                        This distinction has been made clear so many times by now that it is surprising to see the claim that these two are synonyms.

                                                                                                                                        It’s been stated over and over again by everyone from the FSF to the Open Source Initiative that, ignoring some very idiosyncratic edge cases, ‘free software license’ and ‘open source software license’ are synonyms. The cases where the FSF approves and the OSI doesn’t or vice versa is generally because one of the them considers it too vague to be a valid license, such as with the Artistic License v1 or some issues with public domain licenses in Europe. Or to put it another way: if you put the FSF people in charge of evaluating licenses under the OSI definition and the OSI people in charge of evaluating licenses are free or not, they’d come to the reverse conclusions. The requirements for something to be a free software license are virtually identical to the requirements for something to be an open source software license.

                                                                                                                                        RMS: The term “open source” software is used by some people to mean more or less the same category as free software. It is not exactly the same class of software: they accept some licences that we consider too restrictive, and there are free software licences they have not accepted. However, the differences in extension of the category are small: nearly all free software is open source, and nearly all open source software is free.

                                                                                                                                        1. 1

                                                                                                                                          “The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.”

                                                                                                                                          If the original licence says the software can not be used for or distributed by individuals and companies who work in a certain industry - defence is an example which has come up several times, police would be another - that software is not free software.

                                                                                                                                          1. 1

                                                                                                                                            Nor would it be open source software.

                                                                                                                                            Have you ever actually read the open source definition?

                                                                                                                                            “The license must not discriminate against any person or group of persons.”

                                                                                                                                            “The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.”

                                                                                                                                            1. 0

                                                                                                                                              OK, if that clause is part of the open source licence (there are many) the distinction gets less clear. This used to be a problem back in the day when ‘open source’ and ‘free software’ started to be recognised as two possibly distinct licence types. It still is for some licences (e.g. [1], “The license above does not apply to and no license is granted for any Military Use of the Licensed Patents.” but they do seem to be getting more rare.)

                                                                                                                                              [1] https://www.cs.ucdavis.edu/~rogaway/ocb/license2.pdf

                                                                                                                                              1. 1

                                                                                                                                                OK, if that clause is part of the open source licence (there are many) the distinction gets less clear.

                                                                                                                                                That clause is a restriction on what constitutes an open source license. It applies to all open source licenses by definition.

                                                                                                                                                1. 2

                                                                                                                                                  Ah, but that is where the shoe wrings. Open source has become a generic term which is applied to any and all software for which the source is not hidden. The OSI has tried - and, as far as I can see, failed - to rein in the term to only encompass those licences which abide to the directions set forth in their licence, other software should be called ‘source-available’ or similar such constructs.

                                                                                                                                                  1. 1

                                                                                                                                                    the shoe wrings

                                                                                                                                                    I love this translation of “där skon klämmer”, but I think a better English is idiom is “there’s the rub”.

                                                                                                                                                    1. 2

                                                                                                                                                      It is actually a translation of “daar knelt de schoen”, an idiom which exists in many Germanic languages (the one cited being Dutch), English being one of them. Proverbs citing shoe-related woes have been used for many centuries, Shakespeare and his contemporaries were rather fond of these expressions which can be found scattered around their proze: I feare me theres s shooe wrings her i’th instep, of my yong [sic] Shooemakers making was a way of referring to a pregnant woman in a play from 1540.

                                                                                                                                                    2. 1

                                                                                                                                                      Open source has a definition and is still being used according to that definition. I have never seen anyone refer to anything that isn’t open source as ‘open source’ without having many comments pointing out the incorrect use of language and then usually an apology.

                                                                                                                                    2. 1

                                                                                                                                      Most developers who write open source (or free, if you will) software either aren’t very familiar with the politics of Free Software, or explicitly reject it. A well-known example of this is Linus Torvaldus, but there are many more.

                                                                                                                                      Many who use the GPL simply want to ensure people contribute code back, nothing more. I think Free Software as a political concept is not particularly common, even among people who contribute to it, and even less common outside of it.

                                                                                                                                      1. 2

                                                                                                                                        Torvalds doesn’t reject Free Software, he rejects the tivoization clause(s) in GPLv3.

                                                                                                                                        1. 2

                                                                                                                                          He’s been pretty critical of the concept of Free Software, and sharply critical of Stallman and the FSF, and not just about the GPL3. He’s often said that he mostly sees open source and the GPL has a simple practical matter (“it just works best, and sending back your patches is just basic fairness”), and has also said that he doesn’t really mind that proprietary software exists (which is quite different than the political position of the FSF).

                                                                                                                                    3. 17

                                                                                                                                      Nothing is apolitical, because nothing can exist outside of the political (social) climate in which it is created or consumed. Calls to keep politics out of X are political, however, because they distill down to a tacit defense and support of the status quo.

                                                                                                                                      1. 9

                                                                                                                                        This argument has no merit, as you could equally apply it to the choice of condiments you put on a hotdog.

                                                                                                                                        1. 5

                                                                                                                                          It’s political in a very narrow scope; the one of producing the software. The reverse conclusion that some seem to make is that it is a justification to throw even more politics into software development. It is used as a strong-arming argument that disrespects the intent of the author.

                                                                                                                                          1. 8

                                                                                                                                            Calls to keep politics out of X are political, however, because they distill down to a tacit defense and support of the status quo.

                                                                                                                                            You have to be trolling. Some people are just sick of everything being a political discussion.

                                                                                                                                            1. 13

                                                                                                                                              I think the counter here would be that, if you are sick of discussing a political issue, it is likely because the issue does not affect you, which is in some cases due to what might be described as social/cultural/whatever privilege: hungry people don’t often become “sick of” talking about food.

                                                                                                                                              I’m a straight white upper class American male and I both empathize somewhat with your sentiment and do often get tired of every discussion becoming political (hence why I read lobste.rs 100x as often as the orange site) but I must concede some validity to the argument that my position in society is what lets these political discussions be just “boring” to me instead of terrifying and immediately relevant.

                                                                                                                                              1. 13

                                                                                                                                                I think the counter here would be that, if you are sick of discussing a political issue, it is likely because the issue does not affect you

                                                                                                                                                And sometimes, you are powerless to affect it.

                                                                                                                                                Racism exists everywhere in the world, but the form it takes in Bulgaria and elsewhere in the world is unlikely to line up with the American discourse. Imagine how you’d feel if people vehemently demanded you pick a side about the Indian citizenship law, and saw your unwillingness to comply as an indirect endorsement of the other side’s position? Because this is what the internet is like for non-Americans, at the moment.

                                                                                                                                                1. 6

                                                                                                                                                  if you are sick of discussing a political issue, it is likely because the issue does not affect you

                                                                                                                                                  Bear in mind that even activists and volunteers need to decompress.

                                                                                                                                                  One can’t be 24/7 involved in the same thing or you will burn out. Not every conversation can be about the same topic, over and over again.

                                                                                                                                              2. 3

                                                                                                                                                Nothing is apolitical

                                                                                                                                                It’s not true. The action itself can be apolitical at the same time when analyzing the results of the same action can be political. If I stare at a tree because I find it relaxing, it’s not political. But the realization that I’m at the park staring at the tree instead of vandalizing public monuments in a name of some idea, can be political.

                                                                                                                                                It’s similar to mathematics. If I eat an apple because I’m hungry, the action itself is not mathematical. But the number of apples in the area I live in will decrease by 1, so it will be a mathematical result only if you use mathematical reasoning when interpreting the situation.

                                                                                                                                                1. 3

                                                                                                                                                  Maybe this would help you understand:

                                                                                                                                                  … People are different and have various opinions on various topics. But the pure free software ideas are a common interest which leads people from different groups and with different backgrounds to cooperation and shows them the way how to talk each other and eventually build a friendly and respectful community. It is much better than if people from different groups stay in their own bunkers and just bark at each other.

                                                                                                                                                  Future of the Free Software Foundation

                                                                                                                                                  1. 2

                                                                                                                                                    If you want to make something political you can, not matter what it is. Eating a peanut butter sandwich can be political. Washing your hair can be political. Walking to your work can be political. Washing your hands can be political.

                                                                                                                                                    That does not mean these things are political, only that you choose to make them political. This is a personal choice which does not need to - and often does not - transfer to others who get to make their own choices about what they consider to be political and what not.

                                                                                                                                                    That last statement is political, it is the freedom of thought and expression which is one of the pillars most of our societies are built on. Think well before you demolish this pillar, it was built for a good reason.

                                                                                                                                                    1. 0

                                                                                                                                                      Let’s suppose, for the sake of argument, someone came into your supermarket and demanded you change the labels on the white pepper and black pepper (to, say, retted and unretted pepper, or pepperseed spice and peppercorn spice, or any other term that didn’t mention colours) because the words ‘white’ and ‘black’ are racist and political.

                                                                                                                                                      You respond ‘no that’s ridiculous, there’s nothing political about white and black pepper’. They respond ‘everything is political’.

                                                                                                                                                      Ponder that.

                                                                                                                                                      1. 4

                                                                                                                                                        You think you’re making a point, but you’re not.

                                                                                                                                                        1. 3

                                                                                                                                                          Well, for example, electron recently changed whitelist/blacklist to allowlist/blocklist, and Chromium did the same some time ago.

                                                                                                                                                          1. 5

                                                                                                                                                            A blacklist is literally a list of bad things, which are clearly bad because they have the ‘black’ quality.

                                                                                                                                                            Black pepper is a tasty spice.

                                                                                                                                                            1. 1

                                                                                                                                                              A blacklist is a list of bad things which are bad because the colour black is associated with negativity in our culture, while white is associated with good. That has nothing to do with skin colour. It’s honestly pretty cringe to try to force an association between the word ‘black’ and black people everywhere the word exists. ‘Blacklist’ has nothing to do with black people and black pepper has nothing to do with black people. Black MTG cards have nothing to do with black people. Whitelist has nothing to do with white people, white pepper has nothing to do with white people, white MTG cards have nothing to do with white people.

                                                                                                                                                              1. 1

                                                                                                                                                                white pepper has nothing to do with white people

                                                                                                                                                                No shit.

                                                                                                                                                                It’s honestly pretty cringe to try to force an association between the word ‘black’ and black people everywhere the word exists.

                                                                                                                                                                Sure.

                                                                                                                                                                ’Blacklist’ has nothing to do with black people

                                                                                                                                                                Nothing wrong with disagreeing with the majority of linguists if you’ve got an informed opinion.

                                                                                                                                                                Perhaps demonstrating some familiarity with the relevant literature (or maybe even linked a source for this unfounded claim) would help people be a little more charitable in their reading of your ideas.

                                                                                                                                                                1. 2

                                                                                                                                                                  Nothing wrong with disagreeing with the majority of linguists if you’ve got an informed opinion.

                                                                                                                                                                  It’s been used in the English language for hundreds of years (as far back as the mid 1600s, if I remember correctly), rarely, though its first popular use was in the 20th century in reference to blacklists of union members. It’s a blacklist in the sense that the list itself is black. A blacklist was originally two words (as with many compound words) and its first usages are in a more poetic sense: a ‘black list’ where ‘black’ is used poetically to mean dark or evil. ‘His black list’ i.e. ‘his evil list’. It is not a list of ‘blacks’, never has been. Its use far predates modern American conceptions of race.

                                                                                                                                                                  Now you might respond by saying that using a term that has its popular origins in the suppression of unionism to be ‘problematic’, but etymology is not the same as meaning. Words do not mean precisely what they were coined to mean, and it would be absurd to expect everyone to inspect the etymology of every word they speak to make sure it isn’t associated too closely with whatever topic has fallen under the gaze of the keyboard warriors on Twitter and is now considered ‘problematic’. There are probably heaps and heaps of completely normal terms people use all over the place that have their origin in something that, under close inspect without the proper context, might seem ‘problematic’.

                                                                                                                                                                  Should one not use the word bugger? Or hysterical? Are no can do and long time, no see racist? What about uppity or hooligan? Grandfather clause? Call a spade a spade? What about gypsy or Eskimo or American Indian where despite the popular view among white Americans that they’re racist or outdated terms, they’re actually preferred by many of the people they’re meant to describe over Romani (lots of whom aren’t Romani at all) or Inuit or native American?

                                                                                                                                                                  Maybe instead of being offended on behalf of others, you just leave it to them to raise issues if they are actually offended? Getting offended by the origins of terms that have been free of offensive connotation for decades or centuries because a couple of keyboard warriors on Twitter decided that the best way to solve an issue like systemically racist police violence in the USA is to police what variables people use on GitHub…

                                                                                                                                                                  Perhaps demonstrating some familiarity with the relevant literature (or maybe even linked a source for this unfounded claim) would help people be a little more charitable in their reading of your ideas.

                                                                                                                                                                  If you’re going to make such a significant claim you should back it up with sources from the relevant literature. Language is not problematic-by-default. The onus is on you to prove that the term was coined in reference to race if you wish to claim that it is “problematic”. I’m not telling people what to do or calling anyone racist. I’m not making any extraordinary claims. I don’t see why any burden of proof falls on me.

                                                                                                                                                                  1. 3

                                                                                                                                                                    its first popular use was in the 20th century in reference to blacklists of union members

                                                                                                                                                                    Says who? (The wikipedia page for an active political controversy is not a source).

                                                                                                                                                                    Maybe instead of being offended on behalf of others, you just leave it to them to raise issues if they are actually offended?

                                                                                                                                                                    Firstly, I’m not offended by it; secondly, what idea would you have whether it was on someone elses behalf or my own if I were.

                                                                                                                                                                    I’m offended by longwinded, unsourced, nonsensical arguments on an otherwise-good-SNR technical forum.

                                                                                                                                                                    I don’t see why any burden of proof falls on me.

                                                                                                                                                                    You’ve asserted, without evidence, that ‘Blacklist’ has nothing to do with black people, which is sort-of the crux of the discussion. Not only are you raising flat assertions without a source, you’ve the gall to demand anyone who points out this is low-effort do the legwork for you. Generating bullshit is much easier than refuting it, and all that.

                                                                                                                                                                    EDIT: Oh. It’s you, but you’ve changed your username again. I’ll update my killfile, as usual.

                                                                                                                                                                    For anyone else as uninterested as I am in this inanity, a handy ublock rule is:

                                                                                                                                                                    lobste.rs##:xpath(//div[contains(concat(' ', normalize-space(@class), ' '), ' comment ')][.//a[contains(@href,'/u/mrr')]])

                                                                                                                                                                    1. 2

                                                                                                                                                                      You are a nasty piece of work.

                                                                                                                                                              2. 1

                                                                                                                                                                Nonsense. Bookkeepers and accountants rejoice when the numbers are ‘in the black’ but shudder to see them go red. Here, black is good, red is bad. Is this a different black from the one used in the blacklist?

                                                                                                                                                            2. 3

                                                                                                                                                              He is making a point though, even if you choose not to see it. You might not agree with it but that does not imply the point doesn’t exist. In other words, a single person or a group does not get to be the purveyor of truth in an open society which allows freedom of thought and freedom of expression.

                                                                                                                                                          2. -2

                                                                                                                                                            Excellent. Now these monsters who support the status quo have no place to hide.

                                                                                                                                                        1. 9

                                                                                                                                                          I can and will retrain my hand placement habits. After all, this touchbar-keyboard-trackpad combo is forcing many people to learn to place their hands in unnatural positions to accommodate these poorly designed peripherals.

                                                                                                                                                          It is amazing to me what people put up with to use these devices. I generally find the issue with accidentally touching the trackpad so severe that I only use laptops with trackpoint and the first thing I do on my device is to disable the trackpad completely.

                                                                                                                                                          1. 15

                                                                                                                                                            Part of why I ended up becoming a programmer is frustration with a touchpad. It led me to keyboard-only UIs, which lead me to Arch/XMonad, which led me to Haskell, which confused me but led me to Python, which… <10 years later> I have a career as a software engineer :)

                                                                                                                                                            1. 2

                                                                                                                                                              Part of why I got into programming more passionately was excitement when the apple trackpad came out ten years ago. It led me to think about possibilities beyond keyboard-centric UIs. It led me to make zany things. While I’ve never succeeded professionally as a full-blown software engineer it made me appreciate how hard developing great experiences for humans are.

                                                                                                                                                            2. 5

                                                                                                                                                              At work, we actually had to modify a piece of software to deliberately ignore most of the input from recent mac touchpads. The application is multi-touch capable, which on some of the hardware it runs on is really useful. However, on mac, the combination of the oversized touchpad and the fact that it doesn’t map to the screen (it’s mapped to a smaller area which follows the cursor around, so nobody really knows what they’re touching) meant that macbook users were constantly touching things with their tentacles which they didn’t mean to touch.

                                                                                                                                                              1. 1

                                                                                                                                                                macbook users were constantly touching things with their tentacles which they didn’t mean to touch.

                                                                                                                                                                So, uh, what exactly do you do for work?

                                                                                                                                                              2. 1

                                                                                                                                                                Honestly, I liked trackpoints for several years, but after getting a Thinkpad with both trackpoint and trackpad, I have firmly settled on preferring trackpads for this reason: I can accurately point at things faster than with the trackpoint. I do use the trackpoint on rare occasion, but only when I need fine control with something, like moving in a very small screen area, or scrolling only a tiny bit.

                                                                                                                                                                I acknowledge that many other people around the Internet have a problem with accidental palm touches, but, for some reason, that’s never been a problem for me. Then again, I haven’t used Windows in the last several years (only Linux and OSX), so maybe that’s the reason?

                                                                                                                                                                1. 2

                                                                                                                                                                  The Thinkpad has those two big buttons at the top of the trackpad. They require force, so you won’t accidentally press them, and they’re placed about where my thumb wants to rest when I use the keyboard.