1. 21

    While spreading yourself overly thin is definitely a bad idea, this article is basically about the generalist vs specialist debate, and goes all-in on the specialist side.

    While there is value in being very knowledgeable in a certain domain or technology, it also makes you less flexible with regards to possible employers or different projects within a single company. I’ve worked with plenty of developers who refuse to learn a new technology stack, because they think they’ll start as beginners again and it will hamper their career growth (more specifically, they fear that they will not grow their income at the same rate they would if they continued working with the same thing).

    However, the technology landscape changes, perhaps not overnight but definitely over the course of an entire career. Sticking to what you’re experienced at may lead to a dead end some years in the future.

    Additionally, I believe that many of the important skills that make a developer more valuable are not related to using specific technologies or tools, but rather in generic skills that are transferable across languages, tools and frameworks.

    Using and learning new technologies might also prevent you from forming tunnel vision. If all you have is classes and inheritance, everything starts looking like it should be an object, for example.

    You probably shouldn’t use a different language for every project, the same way you shouldn’t use a different Javascript framework for every project just because it’s the hot new thing. But I also think you shouldn’t bet the house on a single language and/or framework just because you consider yourself an expert in that niche.

    1. 9

      While spreading yourself overly thin is definitely a bad idea, this article is basically about the generalist vs specialist debate, and goes all-in on the specialist side.

      I don’t agree. I think the article is trying to signpost a danger for new folks coming to our field - that is the temptation to feel like I MUST LEARN ALL THE THINGS! rather than realizing that there is tremendous depth at play here and that while having a broad skillset is good, you MUST be able to go deep on some small subset of things, whether or not you’re a specialist or a generalist.

      I’d also argue that being a generalist can make it damn hard to stay employed, because the entire recruiting machine wants to plug discrete shapes into discretely shaped holes, and if you don’t fit that model you’re gonna have to work 10 times as hard to make it past said machine rather than working with it.

      That’s my experience, anyway.

      1.  

        Yes, recruiting machines want developers with specific boxes checked on their resume. But I generally find it pretty easy to write a resume for a specific position highlighting the stuff I’ve done they want to hear while only mentioning others in passing.

        There is also a shortage of qualified workers in our field, at least for now, so as soon as you can match a few of the qualities they’re looking for, you can land an interview, and from there it’s easier to convince a hiring manager that you’re a capable worker.

        1.  

          I think it’s possible we’re talking about two different things here.

          Landing a job is one set of skills - thriving in a job is quite another.

          I’m talking about the latter.

          1.  

            I’m replying specifically to your remark about recruitement looking for specific profile features to fill certain positions in your parent comment.

        2.  

          you MUST be able to go deep on some small subset of things, whether or not you’re a specialist or a generalist.

          Where do you find this “MUST”? As far as I can tell, speaking at such a level of generality, the only must is what is needed to do a job, solve a problem, achieve an aim, etc. One needs to be as specialized as the circumstance requires. But I’m struggling to make the leap from that to some categorical imperative of depth, your MUST.

        3.  

          many of the important skills that make a developer more valuable are not related to using specific technologies or tools, but rather in generic skills that are transferable across languages, tools and frameworks.

          This ^.

          Or, as they say, “learn weightier shit”.

        1. 3

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

          1. 63

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

            1. 12

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

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

              1. 5

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

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

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

                1. 3

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

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

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

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

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

                  1. 2

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

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

                2. 3

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

                  1. 11

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

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

                    1. 2

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

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

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

                  2. 7

                    Because modules.

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

                    1. 5

                      You’re probably correct.

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

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

                      1. 3

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

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

                      2. 3

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

                        1. 0

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

                        1. 5

                          I really wish that instead of data classes, which force me to invent types for my data, we’d get a nice built-in syntax for named tuples that wouldn’t require importing a module and repeating the record name twice.

                          1. 3

                            I really wish that instead of data classes, which force me to invent types for my data, we’d get a nice built-in syntax for named tuples that wouldn’t require importing a module and repeating the record name twice.

                            Well, you still have to specify the types of your data and do an import, but there is a nice alternative syntax for named tuples if you want to avoid repeating the record name:

                            class Component(NamedTuple):
                                part_number: int
                                weight: float
                                description: Optional[str] = None
                            
                            1. 1

                              Thanks, I didn’t know about the capitalized NamedTuple.

                            2. 2

                              I agree, the types seem like an unnecessary complication.

                            1. -1

                              Apparently the answer has a lot to do with the fact that .concat creates a new array while .push modifies the first array.

                              Does the fact that this is slow actually merit an article and benchmarks these days? What next, quickselect is 1000x faster than going through the whole list?

                              1. 15

                                Well, every programmer in a high-level PL has to learn where its abstractions leak at some point. Like, “allocations and copies are slow”. And since we keep making new people, articles like these are going to be written again an again. That’s a good thing.

                                1. 2

                                  I’ve programmed in both JavaScript and C++ professionally at different times and I did not know that there was that much overhead associated with the new array creation. It’s a lot more than I would have guessed.

                                  1. 1

                                    You don’t really have to know unless you’re writing code that has to run really fast or very often. I learnt a lot about how expensive allocation is in Ruby by solving some Project Euler problems with it.

                                2. 11

                                  The sheer effort and polish of the post makes it worthwhile. I’ll happily read about something I already know if it’s presented well.

                                1. 2

                                  As a programmer, you spend a lot of time editing and navigating code.

                                  In my experience, not as much as all editor-focused write-ups want you to think. Presumably, you spend much more time thinking what is it that you actually want to do. (Disclosure: my perception is informed by me spending most of the time in Python, as opposed to more text- and repetition-heavy languages like Java.)

                                  1. 1

                                    Is it? I’m trying to find breakdowns of how programmers spend their time and it’s tricky. I’d suspect it would be something like half our technical time is spent debugging.

                                    1. 1

                                      I second this. Also for more verbose languages like Java there are usually very good supporting tools, and You usually don’t use a simple editor, but a semantically aware IDE for the task.

                                      1. 1

                                        Agreed.

                                        I don’t get why people have this need for optimising their text editing so much. They spend so much time trying to learn all these handy keyboard shortcuts and tricks, that the actual time they save when editing text is meaningless.

                                        1. 3

                                          For me it’s absolutely nothing to do with saving time and everything to do with comfort. It didn’t take long to get over the initial hurdle of just running vimtutor and learning the basic keys to move around and edit. From there it was just editing and occasionally thinking ‘I do this [thing] a lot, is there a way to optimise it? Same for my shell setup. It’s not really a deliberate decision to spend ages customising everything, it’s a gradual process that occurs naturally over years out of curiosity, and it pays off.

                                          Edit: the immediate benefit post-vimtutor was being able to keep my hands off the mouse, and that was enough to make it more comfortable than what I had been doing before. I don’t think I would have bothered if it had been that stressful and time consuming just to get started.

                                    1. 2

                                      My former employer AlphaSights does use Kotlin for writing http services. I’d say it’s a no-brainer to use anywhere instead of Java these days. There’s just no downsides. (Well, except that you may find other JVM languages that you’ll like even more.)

                                      1. 30

                                        I object to the historical tag. I use IRC on a daily basis. (In fact, it’s how I keep in touch with most of my social circle)

                                        I do think that the most important thing IRC could do is implement server side history, which solves the main issue: catching up on history after joining a channel or going offline.

                                        Everything else feels like fluff.

                                        1. 22

                                          On the other hand, I consider lack of history a feature, a highly desirable feature.

                                          I don’t need to be notified of everything that happens, I don’t need to know all of the history.

                                          IRC is like walking into a bar. If there’s an interesting conversation, you jump in. And when you’re away, if something important happened, someone else will fill you in. Otherwise, it wasn’t important.

                                          Just miss out without fear. It’s okay. Do other things.

                                          If you need persistent and slow communication, use a different protocol, but leave chat protocols as ephemeral and forgettable.

                                          1. 5

                                            This is not usually how IRC is used in practise. In practise people use bouncers or “irssi in screen forever” to get the history client side. Better to let the protocol solve the problem most people seem to want, and if you don’t want history configure your client not to fetch or show it.

                                            1. 6

                                              I don’t know how usual this is. Lots of people don’t use bouncers. Some use bouncers. The way we use #octave in Freenode is memoryless; #emacs in Freenode has a no public-logging policy (just a politeness convention) and #mercurial in Freenode also has people coming and going all the time. If something happened and people are talking about it, I ask in #mercurial and people will give me the context. Nobody has ever said to me, “get a bouncer, ya n00b!”

                                              I don’t know if most people want persistent history but I certainly don’t.

                                              1. 3

                                                Sure it is. Source: JordiGH and I hang out in several of the same bars^Wchannels. (Sup.)

                                                I currently use “weechat in tmux forever” (formerly “ERC in screen forever”). However, I never actually bother to scroll back except to search for my own name to see if anybody was looking for me.

                                                Once in the past decade, I reviewed my entire buffer for a specific channel because there was “drama” going on when I got back and I wanted to know what happened. The privilege to do so is what the chanops and opers there grant me when they allow my client to idle.

                                                Honestly, after you join a few big channels and a lot of small ones, “keeping up” is neither possible nor worth it. Do you “keep up” with newly uploaded youtube videos? :)

                                                1. 5

                                                  I do irssi in screen forever (call me old-fashioned ¯\_(ツ)_/¯), and that’s not really my experience. I don’t ‘keep up’, but – well, there are a couple of things. #1 is that when I join I’d like to have some context for what’s going on, and drama that causes me to want to scroll up quite a bit happens a lot more often than once in 10 years. Another thing is that sometimes, when it’s been a quiet day, I’ll go on and see that it’s not more than a screenful of text since last time I joined, which provides a nice sense of continuity. Additionally, just being already connected makes for a generally nicer experience. It makes communication asynchronous because there’s not an expectation that if you’re connected, you’re available; so, you can ignore people (or, to put it more generously, wait till later to talk to them). If you join a channel and immediately ask for help with something, it seems a lot stickier and you’re a lot less likely to get a response, than if you’ve been there for a while.

                                                  1. 1

                                                    Ah, yes. I agree with your description; I have experienced those things you describe. Which makes me wonder, why did I describe my experience differently?

                                                    I think I figured it out… Social channels are different than technical channels. I do in fact review the full buffer of technical channels (if they are low-volume enough). I just hadn’t thought about it when posting my previous comment! Thanks.

                                                    1. 2

                                                      Huh. Generally I don’t look at what happened in technical channels. Generally I come, ask/answer a question, but when I’m not there, I’m not there. Only exception is when there’s some bickering in the c channel (it happens a lot), I read backscroll so I can get an informed opinion and join in. Social channels, I know the people there so I care about what they said while I wasn’t there.

                                              2. 1

                                                What do you do to chat with friends? Coordinating an event over email with 7-8 people is painful.

                                                1. 5

                                                  I coordinate an event over email with 7-8 people; I don’t know, it works for me. I just did that last week.

                                                  1. 1

                                                    Hm, to each their own I guess. For us, someone will usually just ask who’s free tonight and whose house is free, where we’re eating etc etc and within a few hours we’ve sorted it out and whoever comes comes.

                                                    1. 1

                                                      Yep, email works great for that.

                                              3. 7

                                                I’ve always been saying that if you want a paper trail, you want email. There’s nothing wrong with it, it works. Chats are for real-time conversations, and those don’t mix well with having a paper trail. Whenever I’m forced to use Slack in companies where it’s the main way of communication, it’s obvious how inconvenient it is to hold a conversation over a few days (or time zones) buried in a constant stream of messages not separated into topics.

                                                1. 4

                                                  Wow - your post made me remember something I haven’t ‘felt’ about the web since back when Facebook’s instant messages feature was separate from it’s ‘mail’ feature, probably 2008. I remember reading that they planned on combining the two. At the time, I thought “How can they possibly do that? My IMs and my Mails are completely different ways to communicate, because one is real-time and the other asynchronous.

                                                  Facebook and Slack messaging work the same now. Real-time, with the paper trail. Both real-time and asynchronous. Stopped starting at your phone or your desktop client? Too bad, you’re now behind.

                                                  I miss being able to differentiate between a message I was expected to read instantly vs a message I could read on my own time.

                                                2. 3

                                                  That’s certainly one of the biggest drivers that’s forced my scrum team to transition to AWS Chime.

                                                  Being able to have persistent messages regardless of client connection state is an absolute deal breaker for us. Coordination becomes much MUCH more difficult otherwise. We used to use IRC, and it got to the point where I was the only one with ZNC working in the whole team :\

                                                  1. 2

                                                    I’m always a bit surprised by the staying power of IRC. This kind of feature is the reason I have always used XMPP for my chatrooms.

                                                    1. 4

                                                      XMPP is an awesome protocol IMO, the issue is that there does not seem to be any decent clients.

                                                      1. 1

                                                        What platform and style are you looking for? I’m partial to irssi-xmpp myself – and Conversations is king on Android. There are hundreds of clients of every kind, so hard to list at once until I know what you’re after :)

                                                      2. 2

                                                        Pardon my ignorance, I’ve used Jabber a bit way back in its infancy so I can’t recall - does XMPP inherently record server side traffic like that?

                                                        1. 1

                                                          The ability for a multi user chat to play back recent history when you join has been part of the protocol basically as long as the ability to have chatrooms at all. How much history is configured by room admin (usually).

                                                          More recently there are extensions to make this even better, but in practise that original feature covers everything I’ve wanted.

                                                        2. 2

                                                          Matrix seems to have figured out how to bridge different networks well. Does XMPP have similar success in that area, and if not, do you have any theories why? Is it a technical thing or just a matter of not enough critical mass?

                                                          1. 1

                                                            Yes, XMPP has always had bridges (we usually say “gateways” or “transports”) to different protocols. When I first started using XMPP most of my contacts were on MSN Messenger, and I talked to them seamlessly.

                                                            These days, there’s Spectrum as a gateway to everything in libpurple, transwhat to WhatsApp, biboumi to IRC, cheogram.com to SMS, even a few to Matrix :)

                                                            1. 1

                                                              So you guess it was mostly poor salesmanship kinda problem that not many people use those?

                                                        3. 2

                                                          Everyone I know who cares about persistent messages on IRC runs an IRC bouncer (e.g. ZNC). It’s pretty easy to set up..

                                                          1. 2

                                                            You’re assuming several things:

                                                            1. Bedrock infrastructure to run znc on. Not at all easy or guaranteed in the enterprise.
                                                            2. Enterprise IRC has the same lax auth strategy that Freenode or other ‘open’ IRC servers do.
                                                            3. That younger people give enough of a shit to go through this admittedly minimal effort when they can just use SlickCord or whatever and not think about it.
                                                            1. 2

                                                              Eh, I was just pointing out that there are options besides “completely change the IRC server”, that users can do to use IRC with persistent messaging.

                                                            2. 2

                                                              You still have to pay for, secure, and patch a server though. Unless you run ZNC at home, in which case you’d probably want to isolate that machine from your LAN.

                                                        1. 19

                                                          I may sound like a broken record, but, again, Linux graphical shells have been just fine (give or take) for decades, and it simply doesn’t deserve all the fixation on them that they get. It’s the apps (or absence thereof) that usually suck!

                                                          Although I have to admit that with the advent of Electron at least they now suck on other OSes in the same way :-) Which is they don’t adhere to any platform UI rules. Like, right now Enpass is the only app on my desktop that doesn’t close its window by Alt+F4. In fact, it goes to great lengths to achieve that: you can literally see how it immediately reopens a momentarily closed window.

                                                          1. 4

                                                            Although I have to admit that with the advent of Electron at least they now suck on other OSes in the same way :-)

                                                            I didn’t think about it that way. Maybe we should encourage it for Windows developers while encouraging lean, native stuff for Linux. Perceptions might shift a bit over time. ;)

                                                            1. 3

                                                              I’ve found both Windows and OS X’s shells to be nearly unusable since shortly after switching to KDE in early 2008, and the usability gap only widened away from the commercial shells’ favor when I switched to a tiling window manager a year or so later. There are massive bucketloads of inconsistencies within Windows and Mac OS, and they’re missing tons of quality-of-life features that most X11 desktops have offered forever (workspaces, convenient keyboard shortcuts for window manager actions, nearly all customization options, among others).

                                                              So—yeah, I don’t get it. I never have. The reason we haven’t had “the year of the Linux desktop” (which, again, for me, was over a decade ago) has nothing to do with the quality or polish of that desktop, and everything to do with inertia, network effects and marketing. Maybe GNOME, which I have no recent experience with, is just that bad…? But personally, I doubt it.

                                                              1. 11

                                                                Some things I wanted to mention, based on my (largely positive) experience with Ada:

                                                                Object-oriented programming (OOP) is a large and ill-defined concept in programming languages and one that tends to encompass many different meanings […]

                                                                This is something Ada gets very, very right, in my opinion. In many languages, OOP is a kitchen sink idea where you take it all or you’ll have none of it. Ada successfully manages to separate out the various components of OOP (encapsulation, polymorphism, information hiding, etc.) Into different language features, meaning both that you can pick and choose – and that you get more insight into what OOP really is.

                                                                Ada exceptions are not types, but instead objects, which may be peculiar to you if you’re used to the way Java or Python support exceptions.

                                                                Sounds nonsensical, but if you read it extremely carefully, it makes more sense. In Python, different exceptions are different classes, and different instances of the same exception class count as “the same exception” .

                                                                In Ada, there is only one exception “class”. Different exceptions are instead different instances of the same type – but there is only ever one instance of each exception “type”.

                                                                1. 3

                                                                  (encapsulation, polymorphism, information hiding, etc.)

                                                                  I just wanted to shout out to a fellow engineer who doesn’t confuse encapsulation and data hiding into one thing :-)

                                                                  1. 3

                                                                    Could you expand on that?

                                                                      1. 3

                                                                        That’s pretty much exactly what I’d answer, thanks!

                                                                1. 8

                                                                  On gradual refactoring:

                                                                  Gradual refactoring of a codebase, where each individual step is trivial but there’s just so many of them—and this is why big-bang rewrites often happen, because that’s just less terrible than trying to mop up a floor with a muddy mop.

                                                                  I wonder how many people are like me, but I adore slow gradual refactorings consisting of trivial steps that together form a completely unpredictable emergent results which make the code look completely different and from-another-universe better!

                                                                  Unfortunately this sort of work stops being useful pretty soon. Right after code turns from ugly to palatable, nobody wants to pay for it to become really good.

                                                                  1. 3

                                                                    I do this too. For every 2 PR’s related to an issue, I end up with another small refactor (1-10 lines) that I noticed along the way. It’s great because PR’s that small are often pretty trivial to write and test. It feels a bit like tidying up.

                                                                    1. 3

                                                                      Completely agreed. It’s the only way to actually keep tech debt at a minimum, without waiting for a “good time” to clean everything up.

                                                                  1. 1

                                                                    dont say “gems” - thats just confusing.

                                                                    1. 9

                                                                      Thanks for pointing it out. I thought it was a pretty common idiom, like in “hidden gems”.

                                                                      1. 5

                                                                        It’s okay, you can use it because Ruby is mostly dying off.

                                                                        Just don’t call them eggs!

                                                                        1. 3

                                                                          Eggs?? That’s so last century! You probably meant wheels :-)

                                                                          1. 1

                                                                            Yeah but:

                                                                            • hidden gem -> gem
                                                                            • easter egg -> egg
                                                                            • [what goes here?] -> wheels

                                                                            I’m wracking my brain for how you’d get wheels reasonably in the title!

                                                                            1. 2

                                                                              fortune wheel..

                                                                      2. 8

                                                                        Can you please tell us for how long you were confused? your comment comes across quite rude and nonconstructive (to me personally).

                                                                      1. 39

                                                                        I’m really burning out on “simplicity” posts. I get it, simplicity is good. But that doesn’t actually inform me as a developer. Why do things become complex? What kinds of simplicity are there? How do we detect simplicity? How do we know when we shouldn’t simplify? None of these posts ever answer that.

                                                                        It’s like if I stood on stage and said “Be good! Don’t be evil! Being evil is bad!” Sure, everybody agrees with that, but does it actually help people make moral choices?

                                                                        (Also the analogy is dumb. Yes, we should totally base our engineering practice on a movie! A movie where the engineers are wrong because of magic.)

                                                                        1. 11

                                                                          Why do things become complex? What kinds of simplicity are there? How do we detect simplicity? How do we know when we shouldn’t simplify? None of these posts ever answer that.

                                                                          Because your questions are difficult and answers are dependent on a lot of factors.

                                                                          I’ll tell you what I do to detect simplicity, maybe you’ll find it useful. Let’s start with a real-life example.

                                                                          I needed tokens for authorization, I reviewed existing formats, JWTs look conservative and Macaroons look powerful.

                                                                          What do I do? I dissect the formats. For JWTs I read the RFCs and implemented software to create them and verify them (each in 2 languages) for various options (key algorithms).

                                                                          For Macaroons I read the whitepaper, then implemented verifier based on the whitepaper, reviewed existing implementations, found out differences between the whitepaper and de-facto code with explanations. While comparing my implementation I found out some security issues with existing code. Additionally I implemented the rest of the stack (de/serialization, UI for manipulation of Macaroons). After two months I knew precisely where does complexity lie in Macaroons and of course there are the only spots all blogposts don’t mention (spoilers: cycles in third party caveats, no standards for encoded caveats…)!

                                                                          Then I looked at my JWT proof-of-concept code - it uses base64(url) and JSON, primitives that basically all programming environments have built-in. After limiting the algorithms used the entire verifier takes just a couple of lines of code! It’s vastly simpler than the Macaroon one.

                                                                          What’s the moral here? That you need a lot of time to see for yourself what is simple and what is complex. Now every time I see a post recommending Macaroons I can already see the author didn’t use them in practice (compare that with the Tess Rinearson post linked at the end of that article).

                                                                          That’s only the example, I routinely implement various protocols and re-implement software (ActivityPub, Mailing Lists, roughtime client) and each time I discover what’s simple or what’s complex in each one of them.

                                                                          (By the way your book is excellent!)

                                                                          1. 9

                                                                            I get it, simplicity is good.

                                                                            Alas, not everybody gets it. The best that these kinds of exhortations can do (all that they aim to do, as far as I can tell) is to persuade people to modify their own set of values. This doesn’t immediately result in better code… but I think it’s a necessary precondition. The only developers who will even ask the good questions you suggest (let alone look for good answers) are the developers who hold simplicity as a value.

                                                                            (The analogy is pretty dumb though, and not especially motivating.)

                                                                            1. 10

                                                                              I’ve never met a developer who does not claim to hold simplicity as a value. But as a concept it is so subjective that this is meaningless. It’s extremely common for two developers arguing for opposing approaches each to claim that their approach is the simpler one.

                                                                              1. 7

                                                                                I get the value of exhortations. I think more examples would be better. Pairs of solutions where the simple one meets requirements with a number of better attributes. Developers often prefer to see the difference and benefits instead of being told.

                                                                              2. 6

                                                                                Exactly. This is one of those things you can’t explain in a book. When to compose, when to decompose. When to extract methods, when to inline methods. When to add a layer of abstraction, when to remove one. When is it too flexible, when is it too simplistic?

                                                                                No amount of rules of thumb is going to answer those question. I only know of one way to learn it: practice. Which takes effort and most importantly, time. Rendering this kind of posts mostly useless.

                                                                                1. 3

                                                                                  P.S. They do feel good to write though, so people will keep writing them, and there’s nothing wrong with it either.

                                                                                2. 5

                                                                                  I agree that anecdotes like this can get old, but I’ve been meaning to actually write a similar post to this… on something I’ve been calling the “too many buttons” syndrome. This issue pops up a ton in large pieces of software (Though I’m specifically thinking of projects like JRA and Confluence) where there’s an option for everything.

                                                                                  Not everyone gets that simplicity is good because it can be harder to sell. “If a user wants it, we should do it” is something I’ve heard just a few too many times without bothering to look at the use case or if it could be done better. Sometimes it’s worth stepping back and looking at the complexity something will add to the project (in both code and testing… especially when it comes to options and how they interact with each other) rather than just adding all the little features.

                                                                                  1. 5

                                                                                    In my experience a lot of commercial companies that develop under tight deadlines produce a lot of suboptimal and dreadful code. Often it takes more time, to produce less code simply because the more time you spend on a difficult problem, the better you understand it. I think the reason that most a lot of software is bloated and complex is because it’s “good enough” which is optimal from an economic point of view.

                                                                                    The other day there was a discussion here on Lobsters about all the required pieces needed to run a Mastodon instance and the popular solution of abstracting all that away in a Docker container. There are alternative implementations that depend on a smaller number of components alleviating the need for dumping everything in a container (of course the question is, do these alternatives offer the same functionality).

                                                                                    How do we detect simplicity?

                                                                                    For me personally simplicity has to do with readability, maintainability and elegance of code or infrastructure. If someones solution involves three steps, and someone else can do it in two steps (with comparable cognitive load per step), I would say it’s more simple.

                                                                                    How do we know when we shouldn’t simplify?

                                                                                    If that would cut some features you cannot miss.

                                                                                    1. 5

                                                                                      You are so right. After years of experience, I only start to clarify my idea of “simplicity”. There are different kind of simplicity most of them are not totally compatible. And in my opinion some need to be preferred to other, but there is no clear rule. To make a choice between different complexity I still use a lot of intuition and I debate a lot, and I am still unsure my choice are the best.

                                                                                      • only using basic feature of a language (do not use advanced programming language feature) is certainly the most important aspect in simplicity. It will make your code easy to read by more people.
                                                                                      • don’t use too much intermediate functions, and if possible don’t disperse those function in many different files before really feel you are copy/pasting too much. My rule of thumb is, 2 or 3 times duplications is totally fine and superior to centralisation of code. It start to be really clear that code factorisation is good when you start repeating yourself more than 6 to 10 times
                                                                                      • only really use advanced feature of the language after having tried not to use it for some time and really lack the ability of that advanced feature. Some examples of what I call advanced feature of a language are; class heritage, protocols in Clojure, writing your own typeclasses in Haskell, meta programming (macros in LISP), etc…
                                                                                      • prefer stateless functions to objects/service with internal states
                                                                                      • prefer pure functions (side effect free) other procedures (functions with side effects)
                                                                                      • give a lot of preference to composable solutions ; composable in the algebraic meaning. For example, I do my best not to use LISP macros, because most of the time macros break composability. The same could be said when you start to deal with type-level programming in Haskell, or when you are doing meta-programming in ruby/python.

                                                                                      For now, all those rules are still quite artisanal. I don’t have any really hard metrics or strong rules. Everything I just said is “preferable” but I’m pretty sure we can find exception to most of those rules.

                                                                                      1. 5

                                                                                        Amen, +1, etc. “Simplicity” often just means that a concept fits cleanly in the maker’s head at a particular point in time. How many times have I returned to a project I thought was simple only to find I had burdened it with spooky magic because I didn’t benefit from critical distance at the time? When was the last time I deemed another person’s work “too complex” because I couldn’t understand it in one sitting and wasn’t aware of the constraints they were operating under? Answers: too often and too recently.

                                                                                        1. 3

                                                                                          What kinds of simplicity are there?

                                                                                          This is a good question (as are the others). Borrowing from Holmes, I’d say there’s a continuum from naive simplicity, to complexity, to simplicity on the other side of complexity (which is what is truly interesting)

                                                                                          For example, “naively simple” code would only cover a small subset (say, the happy path) of a business problem. Complex code would handle all, or most, of the business complexity but in a messy, complicated way. “Other side” simplicity refines that complex code into something that can handle the business complexity without itself becoming overly complicated.

                                                                                          1. 2

                                                                                            What happens to simplicity? We trade it for a other things of course. For example, you can have simple regular expressions, but most people prefer less simple and more powerful implementation like Perls.

                                                                                            Simplicity is often a tradeoff versus easyness, performance, flexibility, reusability, useability, etc. So simplicity is good, but those other things are also good.

                                                                                            1. 1

                                                                                              Most people seem to agree that simplicity is best. However, when it comes down to simplicity for the user versus the developer, I have seen disagreement. Each trade off is going to be situation and implementation dependent, but at my job I’ve been pushing for a simpler developer environment.

                                                                                              In my office, there is a tendency to create exceptions to rules because it makes things simpler for the user. Since the environment has more exceptional circumstances, it tends to have more errors when people forget the undocumented exception case. In my opinion, this causes an uneven experience for the user despite being “simpler.”

                                                                                              My experience is coming from a medium sized, non-tech company. I work in the IT department so we are a cost center. There is an emphasis on white glove treatment of the revenue producing portions of the company. YMMV

                                                                                            1. 3

                                                                                              I’m not sure it’s inventing anything that doesn’t exist, or even new:

                                                                                              👤 => 人
                                                                                              📕 => 书
                                                                                              🏠 => 家

                                                                                              1. 1

                                                                                                Chinese characters are basically old emoji. I use them as such in texts and it’s always great. (Still learning Chinese though, so sometimes I’m off…)

                                                                                                Added benefit: you can write any word as a combination of “emoji”. Example: In Japanese, an emoji (絵文字) is a “picture writing letter” if you look at each individual kanji.

                                                                                              1. 3

                                                                                                I wish every new language web site, instead of having a “hello world” example would state something like: “It’s like but with and without ”.

                                                                                                1. 3

                                                                                                  They have a “detailed comparison”

                                                                                                  Why create V when there are already so many languages? Why not use Go, Rust, C++, Python etc?

                                                                                                  Detailed comparison of V and other languages.

                                                                                                  Clicking it though gives you “coming in March”

                                                                                                  1. 2

                                                                                                    I’ll post it today. In about 30 minutes.

                                                                                                    1. 4

                                                                                                      Did you ever post that detailed article about the C++ to V translator? If it handles legacy code, that could be your biggest achievement given how slow to compile and hard to analyze C++ is.

                                                                                                      1. 3

                                                                                                        In about 2 weeks. Not sure about all legacy. Boost for example was terrible, I gave up almost immediately for now. That’s why I’m working on Doom 3 right now, it’s written using much simpler C++.

                                                                                                        1. 3

                                                                                                          I’d be happiest to see the sqlite to v translation.

                                                                                                          Sqlite is probably one of the most used code bases on the planet.

                                                                                                          1. 2

                                                                                                            Yes, C is easy compared to C++. You’ll see it in 2 weeks.

                                                                                                      2. 2

                                                                                                        But it’s not March! :)

                                                                                                    2. 2

                                                                                                      What information do you think is missing from the landing page? I’ll add it.

                                                                                                      Right now I have 8 main features there, small FAQ, software built in V, and a link to the documentation that covers pretty much the entire language.

                                                                                                      1. 5

                                                                                                        Shapr said:

                                                                                                        “er, not available yet?

                                                                                                        I’d be more interested if I could read the source.”

                                                                                                        doug-moen said:

                                                                                                        “No GC, “safe”, and “fearless concurrency” (a feature of Rust) is a bold claim. How can this be done without the complexity of the Rust type system and borrow checker?”

                                                                                                        Descriptions on how the safety system works… esp combo of no GC, safe, and ultra-fast… along with the source to prove the description is true. Especially in a form with independent replication of claims being possible. You’re making some big claims that create excitement and skepticism. So, you should expect these reactions at a minimum. Ideally, many folks would love to test it out. If your description is true, it can already do amazing things worth an alpha release that warns of breaking changes maybe happening.

                                                                                                        1. 2

                                                                                                          It says right in the very middle of the page that it will be open sourced this summer. It’s absolutely not ready for a release right now.

                                                                                                          Fearless concurrency is achieved by making sure all variables used in different threads are locked. That’s not hard to implement.

                                                                                                          Implementing easier Rust-like memory management is very hard. Right now it’s very basic, and I manage lots of memory manually when developing Volt. I still need to figure out lots of things, but I’m 100% confident I can do this.

                                                                                                          1. 7

                                                                                                            Fearless concurrency is achieved by making sure all variables used in different threads are locked. That’s not hard to implement.

                                                                                                            Correctness in concurrency is not about locking single variables, but maintaining invariants between variables.

                                                                                                            ie. If there exists a relationship between a and b that must always hold for correct execution eg. f( a, b) must always be true, then the accesses to a and b must be locked both by the reader and mutator.

                                                                                                            Of course, as soon as you do this… you now open yourself up to deadlocks and priority inversions unless you’re careful….

                                                                                                            Of course, you can just Stop The World…. in which case you no longer have concurrency…

                                                                                                            1. 3

                                                                                                              Interesting.

                                                                                                              Could you please post a small example of this in Rust or any language you prefer?

                                                                                                              Thanks!

                                                                                                              1. 2

                                                                                                                The thing to understand about schedulers is “unlock” whether it’s a mutex or whatever, means to the scheduler “reschedule now”. It may decide it doesn’t need to switch threads, but it will make the choice at that point.

                                                                                                                Consider the classic bank account, the variable balance holds how much you have, and you’re not allowed to withdraw more than you have.

                                                                                                                SImple.

                                                                                                                if( balance >= withDrawalAmount) balance = balance - withDrawalAmount;

                                                                                                                If you lock on each variable access it doesnt help you.

                                                                                                                If you have two threads a race like this can still occur… Thread 1 Does if( balance >= withDrawalAmount) and then reschedules to Thread 2 which does if( balance >= withDrawalAmount)

                                                                                                                The check succeeds for both Threads… Thread 2 continues and does… balance = balance - withDrawalAmount; ..taking all the money out of the account and reschedules back to thread 1 which does balance = balance - withDrawalAmount; rendering the account negative.

                                                                                                                But every single variable access was locked!

                                                                                                                You need to identify and lock across the whole transaction, not access to variables.

                                                                                                                1. 1

                                                                                                                  OK I see, thanks.

                                                                                                                  In V you’d have to wrap the entire statement into lock{}:

                                                                                                                  lock { if balance >= withDrawalAmount { balance = balance - withDrawalAmount } }

                                                                                                                  But I understand your point. I don’t think Rust prevents you from making this locking error. It forces you to use locking, but you can still use it incorrectly like you described, right?

                                                                                                                  1. 2

                                                                                                                    Most “fearless concurrency” languages achieve this (more or less) by immutability.

                                                                                                                    The core problem in this example is we’re reading AND writing to balance from more than one thread.

                                                                                                                    If balance was immutable… no problem.

                                                                                                                    If balance was only accessible (for read and/or write) from one thread, also no problem.

                                                                                                                    Rust’s approach is basically that, the borrow checker forces only one thing to be holding at a time…. Which solves this simple class of race… but I bet a bad programmer could still do stupid in Rust by passing balance back and forth between threads with an exchange between the check and the update.

                                                                                                                    ie. Good language design can save you from simple threading issues. Nothing can save you when your code is insanely complexity and you have stupid humans writing it.

                                                                                                                    1. 2

                                                                                                                      Your V example has a gotcha…. what is it locking? ie. It will locking out all threads doing a lock even if they are not touching balance or withdrawal. ie. You won’t achieve good performance on highly parallelized tasks.

                                                                                                                      This is why things like pthreads have mutex’s that are associated with a particular resource.

                                                                                                        2. 1

                                                                                                          I wish it had both. I like examples.

                                                                                                          1. 2

                                                                                                            Hi,

                                                                                                            Developer here. There’s a large “Examples” link in the main menu :)

                                                                                                            1. 2

                                                                                                              The “hello world” ones in particular are by definition so simplistic that they hardly tell you anything about a language. A general shape of the syntax perhaps?

                                                                                                              1. 4

                                                                                                                They give a brief overview of the language and they provide something small enough that you can type it in and get results to confirm your toolchain is properly installed.

                                                                                                                Plus, and most importantly, tradition. :)

                                                                                                                1. 2

                                                                                                                  Yes, I can buy the tradition argument for sure :-)

                                                                                                                2. 1

                                                                                                                  Yes, I like it for the syntax. I think the syntax is very relevant, especially if your language doesn’t differ a lot from other languages in other ways.

                                                                                                            1. 8

                                                                                                              Half of me agrees, the other half disagrees. The half of me that disagrees thinks that I want everyone, including businesses, to use my work. That does mean I need to be open to providing at least some level of support. At the very least, I ought to communicate my schedules/plans so that “share holders” can confide in my work.

                                                                                                              But, this isn’t true for all projects I work on. I’m not going to provide the same level of support for libhijack as I will for HardenedBSD. So, the half of me that disagrees also recognizes the need for flexibility and appropriate “risk management.” After all, the amount of support a given project receives could be considered “risk.”

                                                                                                              1. 19

                                                                                                                The difference here is between a project and a product. A project that is interested to be seen as a product should be making explicit steps for that: have a web site oriented to customers, exposed business contacts, appropriate wording in the documentation, etc. My gripe is about businesses treating all projects as products by feault.

                                                                                                                After effecting a cultural shift about a decade ago that made businesses view OSS code seriously, we need to effect another one, by making everyone understand that dependability doesn’t come for free.

                                                                                                                1. 1

                                                                                                                  Wholly agreed with you there. Great discussion. :)

                                                                                                                2. 3

                                                                                                                  “The half of me that disagrees thinks that I want everyone, including businesses, to use my work. “

                                                                                                                  You’re not really disagreeing. Widespread adoption along with whatever that entails is part of your goals for HardenedBSD. Whereas, the author’s goals were different. Either way, other people freeloading off the work shouldn’t expect you to do anything past what your stated goals and preferences are. Even still, they shouldn’t expect it or criticize you much since it was purely a volunteer effort. If it matters, they can contribute something as well.

                                                                                                                  I just don’t think you’re really saying something different if we’re looking at making sure what maintainer wants and others’ needs align. You’re actively aligning the two to some degree with HardenedBSD. You’re also letting people know with your words, foundation, and so on. Others care less about adoption or putting work in. Won’t align with them. Changes how they should or might react.

                                                                                                                  1. 3

                                                                                                                    You’re not really disagreeing. Widespread adoption along with whatever that entails is part of your goals for HardenedBSD. Whereas, the author’s goals were different. Either way, other people freeloading off the work shouldn’t expect you to do anything past what your stated goals and preferences are. Even still, they shouldn’t expect it or criticize you much since it was purely a volunteer effort. If it matters, they can contribute something as well.

                                                                                                                    Fully agreed. I guess “disagree” wasn’t the right word to describe my thoughts. Sometimes I suck at choosing the right wording.

                                                                                                                1. 18

                                                                                                                  A DSL is better than the alternative. Terribly shitty HIDDEN DSL’s embedded in yaml files … cough kubernetes cough.

                                                                                                                  1. 4

                                                                                                                    My biggest gripe as a programmer of the past ~2 years is pointing out exactly this to ops people and having been met with a blank stare not even understanding what the problem is. I guess there’s a sort of a watershed between people who sees configs as an asset vs. a liability.

                                                                                                                    1. 6

                                                                                                                      As a programmer turned ops person. This is also my biggest grip. YAML is awful as a language, it’s pretty lovely as a data format (easy to read, easy to format), but using it like Ansible or K8S does is just asking for trouble.

                                                                                                                      1. 3

                                                                                                                        Most ops people are convinced Turing completeness is evil but they have no problem putting loops in templetized YAML files.

                                                                                                                        I think it started with tools like puppet and ansible and their marketing. They needed to sell “not programming” as a hireable skill so they did. Now we’re stuck with weird DSLs that configure and manage enterprise software systems with no reasonable path out of the mess.

                                                                                                                        1. 3

                                                                                                                          I have been using https://github.com/dhall-lang/dhall-lang for configuration and like it. It has some programming capabilities, but is not turing complete. Though I think the same problem can happen of forcing a tool to do too much.

                                                                                                                          1. 1

                                                                                                                            Terminating and statically typed programmability seems like a valid tradeoff for a configuration language.

                                                                                                                    1. 2

                                                                                                                      https://highlightjs.org/ is pretty “spartan” with ~20 lines of JS and handwritten CSS, just look into view-source:. Of course, a big caveat is that it’s the site about a JavaScript library, so it won’t be as pretty with it disabled. But it works!

                                                                                                                      1. 1

                                                                                                                        syntax higlighting in javascript is one of those things that says “wtf” to me at all though, with rare exceptions. But it is static content, why not just render the semantic tags on the server - once - and have a stylesheet define the client look?

                                                                                                                        1. 1

                                                                                                                          I’m showcasing the library this way: the site is using it as it is intended to be used by others. If I were using node.js on the server, I’d probably do it there.

                                                                                                                      1. 2

                                                                                                                        I hope all of this gets fixed when the Microsoft facelift is out.

                                                                                                                        1. 2

                                                                                                                          Either you use the word “fixed” with a fair share of sarcasm, or… “you must be new here” :-)

                                                                                                                          1. 1

                                                                                                                            it was sarcasm :-)

                                                                                                                            1. 1

                                                                                                                              you got me then :-)

                                                                                                                        1. 10

                                                                                                                          I dunno. This looks like feature creep.

                                                                                                                          Want to start a conversation but no code has been written: Open an issue. You’re PR is going to fix a bug or add a feature. This starts as a issue that is discussed, voted upon and milestoned

                                                                                                                          Your PR is not ready for merging yet: Keep it in your branch/fork and keep working on it. It’s not ready for a PR. Have questions, ask it on the issue. Want a code review, request one on the issue. Or do a regular PR and request comments, because you can keep adding commits to the PR.

                                                                                                                          1. 10

                                                                                                                            Keep it in your branch/fork and keep working on it.

                                                                                                                            I suspect this doesn’t work for most people because you can’t (easily) see and comment on a diff between your branch and the base one without opening a PR. Which is exactly what they should have done instead of creating another redundant first-class entity in the already over-complicated UI.

                                                                                                                            1. 6

                                                                                                                              t’s not ready for a PR. Have questions, ask it on the issue. Want a code review, request one on the issue.

                                                                                                                              Send the patch to a mailing list and discuss it there inline within the comfort of your favorite mail client of choice.

                                                                                                                              1. 3

                                                                                                                                Hard to deny that these days most people find a Web UI more comfortable than any of the (stagnating) mail clients. Minus the hassle of subscribing to a mailing list.

                                                                                                                                I mean, I’m totally with you that all of that is just as easy, but most people seem to have a different perception.

                                                                                                                                1. 4

                                                                                                                                  Minus the hassle of subscribing to a mailing list.

                                                                                                                                  This is a common misconception; there is no need to subscribe to the mailing list if it’s set up correctly. If you send your patch there, people will include you in the reply list regardless.

                                                                                                                                  I agree it’s distressing how much GMail’s near-monopoly has hurt the ecosystem and caused people to forget that better clients exist.

                                                                                                                                  1. 1

                                                                                                                                    In some cases, like work, you’re forced into GMail to avoid someone exfiltrating your IMAP synced mailbox via malware. So…

                                                                                                                                    1. 2

                                                                                                                                      Yeesh; hopefully work policies don’t prevent you from making OSS contributions with your personal mail account tho.

                                                                                                                                      1. 2

                                                                                                                                        In some cases, yes. For the types of stuff I’d do in my spare time, most likely not.

                                                                                                                                        But my guess is that this restrictive email thing will become more popular, not less, meaning that important projects, like those you get paid to work on during work hours, won’t be able to successfully support contributions that way.

                                                                                                                                        I dunno though. I could certainly be completely offbase here and we will see a resurgence of plain text email, and a new generation of mail tools. Fastmail is betting on JMAP, which uses JSON, so the barrier to entry might get much much lower in years to come…

                                                                                                                                2. 1

                                                                                                                                  A mailing list you say? So I have to fight through all the spam, and everything else that comes with it? Should I set up a list for every single repo? Should I write my own automation for code review and assignment?

                                                                                                                                  I mean, on GitHub, I can clearly see who I requested code review from (and whether they reviewed it, and what their review is), who’s assigned to the PR/issue, what milestone it belongs to and so on. Can I do that with a mailing list? Yes, I could search, use labels, bookmarks, whathaveyou in my client of choice, but there’s no built-in thing that provides me with this information. One can build it on top of mailing lists, but then I’d use the API of that, and the mailing list would be reduced to transport only.

                                                                                                                                  As it happens, I can reply to GitHub notifications by email, from the comfort of my favourite mail client. And I get to enjoy the benefits of the API too. So no, a mailing list is not a substitute. For tiny things, or if you’ve established an email-based workflow already, it can work. For a lot of projects, it doesn’t.

                                                                                                                                  1. 2

                                                                                                                                    So I have to fight through all the spam, and everything else that comes with it?

                                                                                                                                    The last time spam got thru on any of my mailing lists was over a decade ago. (Basically never happened since I moved off Google.)

                                                                                                                                    Should I set up a list for every single repo?

                                                                                                                                    Another advantage of this setup is that you aren’t locked in to a 1:1 mapping between issue tracking and repos. You can easily set up a single mailing list to discuss patches for a group of related repositories under a single project, or a separate mailing list for a subset of development on a single large repository.

                                                                                                                                    1. 4

                                                                                                                                      The last time spam got thru on any of my mailing lists was over a decade ago. (Basically never happened since I moved off Google.)

                                                                                                                                      Lucky you. Plenty of my non-google addresses get quite a bit of spam, can’t imagine it being any different for mailing lists. The single list I run gets plenty of spam. Most are caught, but only because I spend non-negligible time making sure they are. I’d happily let go of this task.

                                                                                                                                      Another advantage of this setup is that you aren’t locked in to a 1:1 mapping between issue tracking and repos. You can easily set up a single mailing list to discuss patches for a group of related repositories under a single project, or a separate mailing list for a subset of development on a single large repository.

                                                                                                                                      I can do the same on GitHub with GitHub projects. I get e-mail notification, I can reply via e-mail, but I also have an API to access all of that information - and more - whenever I want, from wherever I may be, without having to carry my email archive around, or host my email on a server I can access on the go. I can also selectively subscribe to issues (via the API, so I don’t ever need to fire up a web browser), and get e-mail notifications. The API lets me query on labels, milestones, etc. Doing the same on a mailing list is very far from being trivial, or convenient, especially when I want to search backwards to times I weren’t subscribed yet.

                                                                                                                                      If you don’t need the labels, don’t use milestones and various other features GitHub provides, a mailing list might be a suitable alternative, and a convenient workflow. The moment you start to use these, a mailing list will stop being adequate. No, Subject: [project:subsystem bug#N]: blah is not a solution, and doesn’t work. Client-side labeling/filtering doesn’t either, because the point of labels & milestones is that they’re centralised. N+1 mailing lists for subsystems is a pain to maintain, and even bigger a pain to work with (been there, tried it, no thanks).

                                                                                                                                      In my experience, working with Magit & Forge is much more convenient than mailing patches and whatnot around.

                                                                                                                                3. 5

                                                                                                                                  You say feature creep, I say the end of a long period of feature stagnation.

                                                                                                                                  Enough companies use Github as part of their development infrastructure – not just process – that it makes sense to have a programmatic way of flagging a PR as “not ready yet”. The rest of us will just type “[WIP]” less often. Is it that bothersome?

                                                                                                                                  1. 4

                                                                                                                                    Do you all not use a WIP label?

                                                                                                                                    1. 6

                                                                                                                                      I do, and include that same title. No one looks at labels, even if they are blinking and bright red.

                                                                                                                                      1. 2

                                                                                                                                        Reminds me of how many PRs we’ve merged that have a “Do Not Merge” label on them.

                                                                                                                                        1. 1

                                                                                                                                          We have a policy of only allowing PRs to be merged by a reviewer, never by the assignee. You may self assign as a reviewer but normally a PR will be created by one person and merged by another. If nobody has been assigned it sits until someone is.

                                                                                                                                    2. 2

                                                                                                                                      I’d prefer to open a PR to start a discussion, but I’ve worked with people who prefer to see PRs as ‘ready to go’ and get shirty when you open a PR that’s not merge-ready.

                                                                                                                                      Making it explicit is handy for dealing with people who aren’t interested in learning how to use patches-by-mail but you want a place to discuss work in progress.

                                                                                                                                    1. 3

                                                                                                                                      Missing Rust in the ML family?