1. 10

    I have found meaning by:

    1. Letting go of thinking that I, at 34, will do something that will meaningfully change the world. I am too late in my life to realistically expect me to have one of those Big Ideas, and I came too late to the party of realizing I found meaning in making the planet better (I am really ambivalent about humanity, whereas when I grew up I felt like technology would improve everything for everyone, which is not a belief I hold anymore). I think you and I have had very similar feelings, I felt very much like the world wasn’t benefitting from what I did, so why bother?
    2. Assuming I won’t have that impact I think I should make, my best bet is to act as an enabler for someone who can. So I work on foundational products like cloud systems, backend APIs, that sort of thing. The cheaper and more accessible foundational systems get, the more likely I can enable someone that will do something amazing. That way I don’t have to buy into the vision of a consumer product in order to get meaning. Consumer products come and go and very few are ever going to make the world a better place (maybe the last one was Facebook or even as far back as Google Maps). Two years ago I took a position to try and optimize for the day-to-day (working on smaller systems after burning out on a big one) that caused the enabling dimension to suffer, and I lost my sense of purpose and meaning. That has affected my excitement about my work much more negatively than the issues of what I left.

    I think of projects like Mozilla, cloud, even something like Tensorflow or Kubenetes, as being these kind of enablers.

    Sure, the most meaningful thing in my life is my family. The most meaningful things in your life are almost certainly going to be outside of work. I’m trying to do more meaningful things like Hour of Code and encourage girls and minorities into STEM (again following the enabling track). But it is important, I think, to find some sort of thing you can extract from the day-to-day as worth it to you, otherwise you’re just going to stop getting out of bed.

    1. 3

      I think when I posed the question, your second bullet point is what I secretly wanted to hear the most.

      1. 3

        Last night, I saw that @cflewis and @freddyb as two sides of same coin in terms of doing meaningful work in IT. One is making sure it’s easy to create things that benefit humanity using technology. One is making sure it’s easy to consume them. In each case, you want what you make to be designed for high uptake for one. Usability, marketing/branding, and cost trumps internal tech on either of these almost every time. Then, if dollars and/or code contributions are rolling in, you can use your influence to make sure whatever it is goes in public-benefiting rather than predatory directions.

        Firefox is actually a good example where they make money off ad-driven search but let you do private search easily. Always having an affordable, private version of anything ad driven is another example. On organizational side, you might charter or contract in basic protections/benefits for everyone from employees to users. On the technology stack, you might build on better foundations to shift more money or effort into quality tech that deserves it. Quick example from my field would be things like routers most half-ass with shoddy tech instead using OpenBSD, secure admin interface, and automatic updates. On web side, it might be those using tech like Erlang to be efficient and highly-reliable with big, success stories getting more people investing in its tooling.

        There’s a lot of possibilities that involve doing something that people want to use or buy that’s just more effective and/or less evil than the norm. Sadly, the norm has so much of those two that there’s plenty of ways to differentiate on those. The relief being that there’s plenty of ways to differentiate on those. :)

    1. 25

      I used to do the things listed in this article, but very recently I’ve changed my mind.

      The answer to reviewing code you don’t understand is you say “I don’t understand this” and you send it back until the author makes you understand in the code.

      I’ve experienced too much pain from essentially rubber-stamping with a “I don’t understand this. I guess you know what you’re doing.” And then again. And again. And then I have to go and maintain that code and, guess what, I don’t understand it. I can’t fix it. I either have to have the original author help me, or I have to throw it out. This is not how a software engineering team can work in the long-term.

      More succinctly: any software engineering team is upper-bound architecturally by the single strongest team member (you only need one person to get the design right) and upper-bound code-wise by the single weakest/least experience team member. If you can’t understand the code now, you can bet dollars to donuts that any new team member or new hire isn’t going to either (the whole team must be able to read the code because you don’t know what the team churn is going to be). And that’s poison to your development velocity. The big mistake people make in code review is to think the team is bound by the strongest team member code-wise too and defer to their experience, rather than digging in their heels and say “I don’t understand this.”

      The solution to “I don’t understand this” is plain old code health. More functions with better names. More tests. Smaller diffs to review. Comments about the edge cases and gotchas that are being worked around but you wouldn’t know about. Not thinking that the code review is the place to convince the reviewer to accept the commit because no-one will ever go back to the review if they don’t understand the code as an artifact that stands by itself. If you don’t understand it as a reviewer in less than 5 minutes, you punt it back and say “You gotta do this better.” And that’s hard. It’s a hard thing to say. I’m beginning to come into conflict about it with other team members who are used to getting their ungrokkable code rubber stamped.

      But code that isn’t understandable is a failure of the author, not the reviewer.

      1. 7

        More succinctly: any software engineering team is upper-bound architecturally by the single strongest team member (you only need one person to get the design right) and upper-bound code-wise by the single weakest/least experience team member.

        Well put – hearing you type that out loud makes it incredibly apparent.

        Anywhoo, I think your conclusion isn’t unreasonable (sometimes you gotta be the jerk) but the real problem is upstream. It’s a huge waste when bad code makes it all the way to review and then and then needs to be written again; much better would be to head it off at the pass. Pairing up the weaker / more junior software engineers with the more experienced works well, but is easier said than done.

        1. 4

          hmm, you make a good point and I don’t disagree. Do you think the mandate on the author to write understandable code becomes weaker when the confusing part is the domain, and not the code itself? (Although I do acknowledge that expressive, well-structured and well-commented code should strive to bring complicated aspects of the problem domain into the picture, and not leave it up to assumed understanding.)

          1. 3

            I think your point is very much applicable. Sometimes it takes a very long time to fully understand the domain, and until you do, the code will suffer. But you have competing interests. For example, at some point, you need to ship something.

            1. 2

              Do you think the mandate on the author to write understandable code becomes weaker when the confusing part is the domain, and not the code itself?

              That’s a good question.

              In the very day-to-day, I don’t personally find that code reviews have a problem from the domain level. Usually I would expect/hope that there’s a design doc, or package doc, or something, that explains things. I don’t think we should expect software engineers to know how a carburetor works in order to create models for a car company, the onus is on the car company to provide the means to find out how the carburetor works.

              I think it gets much tricker when the domain is actually computer science based, as we kind of just all resolved that there are people that know how networks work and they write networking code, and there’s people who know how kernels work and they write kernel code etc etc. We don’t take the time to do the training and assume if someone wants to know about it, they’ll learn themselves. But in that instance, I would hope the reviewer is also a domain expert, but on small teams that probably isn’t viable.

              And like @burntsushi said, you gotta ship sometimes and trust people. But I think the pressure eases as the company grows.

              1. 1

                That makes sense. I think you’ve surfaced an assumption baked into the article which I wasn’t aware of, having only worked at small companies with lots of surface area. But I see how it comes across as particularly troublesome advice outside of that context

            2. 4

              I’m beginning to come into conflict about it with other team members

              How do you resolve those conflicts? In my experience, everyone who opens a PR review finds their code to be obvious and self-documenting. It’s not uncommon to meet developers lacking the self-awareness required to improve their code along the lines of your objections. For those developers, I usually focus on quantifiable metrics like “it doesn’t break anything”, “it’s performant”, and “it does what it’s meant to do”. Submitting feedback about code quality often seems to regress to a debate over first principles. The result is that you burn social capital with the entire team, especially when working on teams without a junior-senior hierarchy, where no one is a clear authority.

              1. 2

                Not well. I don’t have a good answer for you. If someone knows, tell me how. If I knew how to simply resolve the conflicts I would. My hope is that after a while the entire team begins to internalize writing for the lowest common denominator, and it just happens and/or the team backs up the reviewer when there is further conflict.

                But that’s a hope.

                1. 2

                  t’s not uncommon to meet developers lacking the self-awareness required to improve their code along the lines of your objections. For those developers, I usually focus on quantifiable metrics like “it doesn’t break anything”, “it’s performant”, and “it does what it’s meant to do”. Submitting feedback about code quality often seems to regress to a debate over first principles.

                  Require sign-off from at least one other developer before they can merge, and don’t budge on it – readability and understandability are the most important issues. In 5 years people will give precisely no shits that it ran fast 5 years ago, and 100% care that the code can be read and modified by usually completely different authors to meet changing business needs. It requires a culture shift. You may well need to remove intransigent developers to establish a healthier culture.

                  The result is that you burn social capital with the entire team, especially when working on teams without a junior-senior hierarchy, where no one is a clear authority.

                  This is a bit beyond the topic at hand, but I’ve never had a good experience in that kind of environment. If the buck doesn’t stop somewhere, you end up burning a lot of time arguing and the end result is often very muddled code. Even if it’s completely arbitrary, for a given project somebody should have a final say.

                  1. 1

                    The result is that you burn social capital with the entire team, especially when working on teams without a junior-senior hierarchy, where no one is a clear authority.

                    This is a bit beyond the topic at hand, but I’ve never had a good experience in that kind of environment. If the buck doesn’t stop somewhere, you end up burning a lot of time arguing and the end result is often very muddled code. Even if it’s completely arbitrary, for a given project somebody should have a final say.

                    I’m not sure.

                    At very least, when no agreement is found, the authorities should document very carefully and clearly why they did take a certain decision. When this happens everything goes smooth.

                    In a few cases, I saw a really seasoned authority to change his mind while writing down this kind of document, and finally to choose the most junior dev proposal. And I’ve also seen a younger authority faking a LARGE project just because he took any objection as a personal attack. When the doom came (with literally hundreds of thousands euros wasted) he kindly left the company.

                    Also I’ve seen a team of 5 people working very well for a few years together despite daily debates. All the debates were respectful and technically rooted. I was junior back then, but my opinions were treated on pars with more senior colleagues. And we were always looking for syntheses, not compromises.

                2. 2

                  I agree with the sentiment to an extent, but there’s something to be said for learning a language or domain’s idioms, and honestly some things just aren’t obvious at first sight.

                  There’s “ungrokkable” code as you put it (god knows i’ve written my share of that) but there’s also code you don’t understand because you have had less exposure to certain idioms, so at first glance it is ungrokkable, until it no longer is.

                  If the reviewer doesn’t know how to map over an array, no amount of them telling me they doesn’t understand will make me push to a new array inside a for-loop. I would rather spend the time sitting down with people and trying to level everyone up.

                  To give a concrete personal example, there are still plenty of usages of spreading and de-structuring in JavaScript that trip me up when i read them quickly. But i’ll build up a tolerance to it, and soon they won’t.

                1. 12

                  It is very, very unlikely that he was rejected purely for a binary tree search issue. He says in the OP he had 7 interviews. When a hiring committee looks at the data from 7 interviews, a single bad interview isn’t enough to torpedo a whole application. Sometimes an interviewer and and interviewee just don’t jive. It might have been that he was just middling in the interviews, and middling is great for most companies.

                  From all I’ve ever read on this topic, it seems to me that Howell thinks his previous record should have counted in the process, and that’s a legitimate feeling, but that’s not the way Google interviews. A good record gets you through the door, but once you’re in the interview room, interviewers barely look at the resume past some warmup questions or a “Hey cool, you did Homebrew? That’s wild! I use that all the time!” and then move on to the questions they are used to asking and calibrating their recommendations for. Personally, I am pretty glad that external record isn’t counted, I like that a fresh university graduate or someone who has been stuck working in a secret at a company that doesn’t produce exciting software has the same starting potential as Howell. But I get how that can burn.

                  1. 3

                    We find experience can actually work against candidates; if the interviewer reads too deeply into a resume and well known projects on it they can set unrealistically high expectations on how they’ll do in the interview.

                    Starting from a more or less blank slate is really the only fair way to do interviews in volume with lots of different interviewers.

                  1. 23

                    As a programmer, I read this and think, yes, that’s an unsurpassable moat. How will Apple–much less OpenStreetMaps–ever catch up?

                    As someone who worked with Sanborn fire insurance maps in a previous career, I’m not so sure. Sanborn maps had even more detail than today’s Google Maps–they showed not only building footprints but building function, number of floors, construction materials, and other features of interest to fire insurers (sometimes interior structural walls were indicated). They existed for big cities but also for places like Circle City, Alaska and Adrian, Michigan. I have a hard time imagining the level of effort that went into creating and maintaining these maps (they were literally updated by mailing out sheets with bits of paper you would cut out and paste over your existing map, usually at the level of individual buildings). But people managed to do it without aerial or satellite imagery, or ML image recognition, or any of the other tools available to us today. It’s hard to imagine that Apple couldn’t–if it wanted to–replicate something a much smaller company (the Sanborn Map Company employed 700 people at its peak) was doing a hundred years ago.

                    1. 10

                      The Sanborn example is a really good one. As a fire insurance company, they invested in good maps because they were potentially liable for a lot of unexpected costs from inaccurately-estimated risks. The maps were literally Sanborn’s business. Apple sells phones and computers so they just need a good-enough map to keep people from jumping ship to Android or allowing GMaps an enclave in iOS territory. What does Google need this level of detail for? Ultimately they sell ads, and they’ve been very creative in figuring out ways to expand the potential surface area for ad sales and improve consumer data flowing back to them.

                      1. 3

                        I agree with you, it’s all about who the detail is for. It’s not unsurpassable. It really depends what you’re trying to do.

                        Mapping is one of the most subjective pieces of data you can offer: a map’s value is only what the reader gets from it. That’s why we have so many… hiking maps, road maps, the fire maps you point out. Is the information that the article notes others don’t have really that valuable? Not to me. I’m sure it’s valuable to some. I’ve tried Apple Maps again because it worked nicely with the iPhone X out the box (note to app developers: you don’t get second chances, you gotta be there at the beginning) and it seems fine for road maps, which is what I need it for. I also like the Yelp reviews that are embedded. I remain skeptical about the traffic information, though.

                        Waze is a really good example of a map that’s hyperfocused on a single use case: driving. You got roads. You got traffic. You got where you can get a donut. You don’t need to know the shape of a building.

                        I guess I just don’t find the idea of moats all that compelling. I think we’ve seen time and again in tech and elsewhere that when people see a moat, what you usually have is a very broad offering which leaves opportunities for very focused offerings to do better (even Google was this at the beginning, Yahoo had all the content out the wazoo, and everyone thought you couldn’t compete with that, and Larry and Sergey just built a very good search engine that rocked the one Yahoo had).

                      2. 3

                        I sat next to a Apple maps engineer on a flight recently. Was told it’s a 1500 person org. Kind of shocked me.

                        1. 1

                          Most of those people are acquiring and processing data, similar to other mapping orgs.

                      1. 2

                        Test doubles for services is a real problem. I am glad this exists.

                        That said: Conflating together mocks, fakes and stubs does not convey the authority necessary to show that you can help developers work better. It conveys that you don’t really know what you are doing. The blog post mentions fakes, which isn’t what this service offers. The docs themselves indicate to me that what are really being offered are stubs.

                        I would be really worried about investing time in this service when its not clear what I am being offered, and its not clear that the developers really understand what they are offering me either.

                        For background, this is a good rundown between fakes, mocks and stubs: https://stackoverflow.com/questions/346372/whats-the-difference-between-faking-mocking-and-stubbing

                        EDIT: Also, $50 a month for such a service sounds pretty high. I’m not usually one for “but I can spin up my own [x] on [y]” as it usually comes with the caveat of “but I didn’t do any of the number crunching about how to maintain this”, but you could build something pretty quickly to deploy on Heroku or App Engine and get the same result.

                        1. 5

                          Hi! Blog post author here. I appreciate the feedback that conflating mocks/fakes/stubs might make it less clear to some potential users what exactly the service is offering. Overall, I am less interested in using precisely Martin Fowler’s definitions of these overloaded terms than conveying in practical terms to the target audience what the service does, but I may revisit the language. The service presently offers “mock servers”, not “fakes”.

                          EDIT: the accepted answer for your linked stackoverflow post says “in fact, it doesn’t really matter what you call it” ;)

                        1. 2

                          For those looking for a TL;DR, my watch of the first 10 minutes is that Troy is showing that Face ID has UX problems in many situations he finds himself in, such as wearing sunglasses outdoors. Imma take a stab at guessing he makes the case that people might turn it off because of this, which is bad security too.

                          I have bad, but forgivable, usabilyt issues too, like wanting to read my phone when I have my CPAP machine on, or if part of my head is hidden by a pillow and I’m lying down.

                          I don’t understand why Apple doesn’t allow FaceID to train multiple faces, so you could train it with your sunglasses or with your pillow or whatever. Maybe it’s a processing limitation that it takes too much time to run through the options? I’d be happy if the fallback to PIN was quicker or otherwise accessible from the get go too.

                          1. 2

                            Your speech isn’t banned, it’s just impeded past reasonable bounds. You’re free to set up your own ISP and deliver your web sites on it, but you’re not going to. It’s like newspapers’ Letters to the Editor. “You didn’t print my letter! You are preventing my speech!” “Well, a) we don’t care, and b) you can just setup your own newspaper and print what you want.” You could go out and buy a printing press and make a zine and distribute it as far as you can, but you probably won’t.

                            I get the spirit of what the author is saying, but I don’t think it’s going to fly unless you believe internet access is a utility, rather than a medium. I think the majority of the public do see it as a utility, and being told how you should use your electricity is something we wouldn’t tolerate. But I think Pai and his cronies have convinced the old men on the Hill – that don’t care because they have their interns print out all their email anyway – that it’s a medium, and just like cable can choose channels, ISPs can choose web sites.

                            1. 5

                              You’re free to set up your own ISP and deliver your web sites on it, but you’re not going to

                              This just isn’t true.

                            1. 4

                              Any guesses as to how this could happen?

                              There must be some timing involved because of how you need to press the button quickly, but I am struggling to think of why you would put any timing code in there at all apart from exponential backoff, which would result in things slowing down, not passing.

                              Maybe some wacky timing attack protection that bugged out?

                              1. 2

                                my experimenting didn’t reveal any timing element; it worked consistently for me without any kind of trickery.

                                1. 1

                                  Yeah, I’ve been puzzling over this. I simply do not understand how this happens. Assuming it’s not an intentional backdoor left by a departing employee (which I doubt), it has to be related to something in Directory Services? I am really at a loss.

                                1. 2

                                  Money quote:

                                  And, yes, I know the game tracks works by tracking your location. I’m all right with that. As I repeatedly say, Internet privacy is all about trade-offs.

                                  1. 5

                                    How are other kernels managed?

                                    Doesn’t never “breaking compatibility” result in accumulating “technical debt”?

                                    What would it take for user space stuff to adapt to changes in a kernel’s API?

                                    1. 9

                                      Other OS’s have ABI versioning and the userspace matches that.

                                      1. 9

                                        FreeBSD is allowed to break ABI in a new major release. Compatibility layers are provided for old binaries (down to 4.x!) and they work… when reasonable — right now in -CURRENT every <=11.x binary that touches stat and dirent is kinda screwed thanks to 64-bit inodes.

                                        OpenBSD, IIRC, doesn’t have any compatibility layers or even minor releases. New release — new ABI, recompile your crap.

                                        1. 2

                                          That’s sad. I really like the backwards compatibility that FreeBSD and NetBSD provide.

                                          1. 7

                                            What is sad about getting a new set of binaries every 6 months?

                                            1. 6

                                              Christos (from NetBSD) was really into binary compatibility (among other things) and he used Franz Lisp compiled for NetBSD 0.9 in 1994 (http://www.aiai.ed.ac.uk/~jeff/franz-for-386.html) to test NetBSD’s binary compatibility over the years. Last time I saw him reporting success was around NetBSD 4.0. If he continued this work, Franz Lisp is likely still running, unchanged, 20 years later.

                                              I think that’s something to be proud of.

                                              1. 4

                                                Having to manually adjust hard-coded information about syscalls in languages like Go every 6 months or risk your programs failing at run-time

                                                1. 3

                                                  syscalls will usually be given at least 2 releases cycles (12 months) to phase out.

                                                  But such problems do happen sometimes, indeed. However, if there’s a process in place to deal with such changes on a regular basis, they can be dealt with more easily than if they only happen once in a decade, making everyone forget how to best transition to a new ABI.

                                          2. 8

                                            On Darwin (macOS/iOS/…), the syscall boundary isn’t considered ABI. Rather there’s a libsystem_kernel.dylib that provides the userspace system call stubs and the functions exported there define the ABI. This allows lockstep kernel/user changes and userspace can use symbol versioning or other tricks to keep old software working.

                                            1. 3

                                              Windows does this too, though it’s just one of the numerous schemes (of varying insanity) to avoid breaking userland.

                                            2. 5

                                              I don’t know about kernels, but

                                              Doesn’t never “breaking compatibility” result in accumulating “technical debt”?
                                              

                                              isn’t true in a wider scope, you can just mark a method as deprecated and add a new method instead that does what you want. Then there’s some deprecation policy that’ll let you remove the old code eventually. You have to tolerate the debt for the period of the policy.

                                              I think we as developers really hate that once we create an API we’re locked into it. It really annoys us, but when you write an API, you’ve made a contract and you’ve got to deal.

                                              This is why I avoid working on APIs ;)

                                              1. 7

                                                Or you can add longer and longer calls to sleep() below the deprecation message: https://twitter.com/johnregehr/status/920691341738123264

                                              2. 4

                                                Doesn’t never “breaking compatibility” result in accumulating “technical debt”?

                                                Yes, it does. There are numerous system calls (i.e. mmap2 or statx) which should be used instead of older system calls but remain “optional.” It’s not as much of a problem as one might think, however. A lot of new functionality is instead implemented as a file (although /proc is fairly crufty itself) or as an ioctl.

                                              1. 57

                                                Yeah, “moderating” with a don't make "hate posts" isn’t gonna cut it. There was glossed over reason for not liking electron followed by good discussion pointing to the actual reasons. This looked a lot more like a “frustrated and with good reason” post to me!

                                                If absolutely nothing else - there needs to be an explanation from @pushcx on what the specifics of hate are!

                                                I sincerely hope that this type of moderation doesn’t become the norm!

                                                1. 16

                                                  It’s really boring whenever an app made with Electron comes up that someone has to bring up that they don’t like Electron. It adds nothing to the conversation. I hope this kind of moderation becomes the norm.

                                                  1. 45

                                                    And I personally find many discussions on this site boring, but I’d hope that my discussion preferences don’t get baked into moderation policy.

                                                    We’ve already got downvotes.

                                                    1. 10

                                                      So… sarcastic remarks are now a no-no?

                                                      I find Electron to be a little too much bloated for my taste. I would not recommend it as a go-to solution for desktop applications, since not everyone really needs bundled web browser and ffmpeg. That out of the way, feel free to talk about it’s advantages.

                                                      Is this really better?

                                                      1. 5

                                                        I assume you mean moderating of the comment.. not the removal of the entire thread.. hopefully you mean that :P.

                                                        1. 6

                                                          Exactly this! Much nicer way to resolve this situation was to say in comments like “Hey, we consider this type of comments harmful because of etc etc etc… but no, they had to remove it. And the comment was not as problematic as they present it here. I don’t want to leave this place after 3 years of reading other people’s (well moderated) opinions. I kinda felt this is going to happen after JCS announced that he’s stepping out.

                                                        2. 0

                                                          Its really boring when a “lightweight” app comes up that has been written in Electron, when it is far from lightweight. It adds nothing to the site. I hope this kind of content doesn’t become the norm.

                                                        3. 5

                                                          Given the effects of rants on conversation (especially rants many of us have read many times), it would be nice to enforce stricter requirements on the writer of the rants to offer “constructive feedback”.

                                                          “I’m really tired of having to install Electron’s 200 megs” yeah we all are… “would be nice to have some shared libs/for people to rely more on OS-specific containers” OK now we have something that adds to the conversation.

                                                          And if we’ve all had this conversation before…. well… we can just not make the post (This one might apply to my own post but I don’t read it that often).

                                                          EDIT: I don’t necessarily think this requires deletion in most cases. Downvotes should work so long as people aren’t rage-upvoting….

                                                        1. 4

                                                          Seems all very fine, but I would caution against GoMock.

                                                          GoMock has been abandoned internally at Google for good reasons. It’s ugly to read, it’s hard to write, and it masks underylying architectural problems. “…refactoring our code to have simple, interface-based components would add too much noise” addresses the architectural thing head on, and I just don’t see a world where having a bunch of GoMock code is better than having some tightly defined and documented interfaces in the system under test instead.

                                                          But I liked everything else :)

                                                          1. 1

                                                            Post author here :) Thank you for your feedback - and I agree with your point about architecture: a good Go design almost always mean that you don’t have to use stuff like GoMock. I know it’s heavy, it’s ugly, and it’s not doing anything special, but, I think, there are certain scenarios where it can have sense to just spawn a compiled mock to speed up the development, without sacrificing too much in terms of design. Sill, from scratch I’d always say: “don’t use GoMock (or similar)” when you can achieve the same result with plain and clear code, but when evaluating the tradeoffs I think it can still be a viable option given certain circumstances.

                                                          1. 16

                                                            tl;dr: the author wants to talk about how good Elixir is, but can’t do it without trampling on other technologies with unfit comparisons.

                                                            1. 7

                                                              Yeah. I mean, OK cool, I have no love for Node either, but I’m also of the opinion that “safe” and “dynamically typed” is an oxymoron, so I guess that would exclude Elixir for me too.

                                                              And isn’t the point of Node not that it’s rad on the backend but that it’s Javascript for those who live in frontend land? Whenever I look at something like gopher.js just so I don’t have to write Javascript, that’s me doing the same thing but the other direction. I can’t cast the first stone here.

                                                              This is a weird post.

                                                              1. 4

                                                                Part of the point of Node is that all the libraries are aware of the cooperative threading model, and the default APIs are non-blocking (with callbacks). Thus you can get the performance advantages of event-based asynchronous I/O without thinking about it too hard. (Which you can then throw away without thinking too hard either, by doing CPU-intensive tasks on your single event loop thread. No free lunch here.)

                                                                1. 2

                                                                  I think his point is pretty sensible - the Erlang/Elixir/BEAM runtime is pretty cool beans, especially compared to NodeJS.

                                                                  If you’ve got other things that we should check out that are cool from statically-typed land, I’m always on the lookout for something new and interesting.

                                                                  1. 3

                                                                    The point is that if you want to show an ecosystem proper, do it on its own right. Elixir is great, BEAM is too, but most of the parts they are good at are shown much better in isolation, without slinging mud at Node.

                                                                    The post is neither fish nor fowl: it’s not a good criticism of Node nor a particularly good endorsement of Elixir, because it is based on the poor criticism of Node.

                                                                    By all means, programming languages must be criticised, but hyperbole rarely is it. Not because it’s out of line, but because it doesn’t stick particularly well. It’s fun to read, but not lasting.

                                                                    1. 1

                                                                      Nah, I would be into it though.

                                                                      I use Go exclusively on the job and I’m happy. I would like a Supervisor model thingy but Go doesn’t really have one (I think I read a post about why it was hard but I forget) and Google does something similar with the entire process instead (Borg will just restart a dead task), so there’s no real push for it to change.

                                                                    2. 1

                                                                      Another point for JavaScript is that it is fast, thanks to JIT. At least, faster than Python.

                                                                      1. 1

                                                                        At least, faster than Python.

                                                                        That’s arguably a tossup.

                                                                        1. 5
                                                                          1. 3

                                                                            Had no idea this site existed and it’s incredible thanks!

                                                                            1. 2

                                                                              It’s a neat site, but sometimes it’s misleading.

                                                                              People have a tendency to submit code using tricks that would normally be avoided or frowned upon. For example, checkout how many of the Haskell samples are using unsafe modules to avoid laziness and immutability.

                                                                              That’s not against the rules, but it’s good to be aware of.

                                                                              1. 1

                                                                                Sure that is true but if you know the languages you can see “is this normal”. For the JS and Python top few examples they seem to be relatively normal.

                                                                            2. 1

                                                                              Shame they don’t show how fast the “bad output” was generated, that would be an interesting benchmark.

                                                                            3. 1

                                                                              Yeah, if you use libuv in Python, you’ll get the same I/O performance as Node, which uses libuv.

                                                                              But the actual CPython interpreter is horribly slow compared to V8’s JIT. PyPy is better than CPython, of course.

                                                                              Also, I’ve tried async Python 3 and it’s honestly somewhat clunky. The awesome thing about ES6 async/await is that it just uses promises, which makes it trivial to integrate with code that doesn’t use async/await syntax.

                                                                        2. 4

                                                                          You read my mind. At the very least don’t hand wave - SHOW ME. Prove your mastery of both technologies by comparing and contrasting the code. if you can’t, you’ve no business writing the article IMO.

                                                                          1. 1

                                                                            I think the main reason is that node.js is just a more highly ‘engageable’ keyword. So if you have a title that says “my opinion about Elixir” there would be many fewer clicks than if you have your title as “NODE.JS IS BAD also elixir”.

                                                                          1. 7

                                                                            What is the actual worst case scenario that could result from this patent clause?

                                                                            1. 14

                                                                              For big companies its:

                                                                              • Facebook violates a patent you hold and you’re like “dude, that’s not OK” and you go to litigation.
                                                                              • Facebook’s patent grant retaliation kicks in. It revokes the grant to everything Facebook gave you under BSD+Patents anywhere in the company.
                                                                              • You are now at risk of having to pull products that are completely unrelated because of the patent infringement.

                                                                              Apache 2’s patent termination is only in regards to entering litigation about that particular piece of software. So if you build three apps using a library, but there’s a patent battle over something in software A, software B and C still have the patent grants.

                                                                            1. 1

                                                                              Is it time to move back to jQuery and Prototype.js? If these mysterious patents are about things like “virtual DOM”, comparing trees of state or something derived from FRP, then using Vue, Preact, Angular 2, Cycle, Riot, Elm, reflex-dom will infinge them too.

                                                                              Then let’s wait 20-30 years until these patents expire and everyone finally can use these nice state-management things.

                                                                              1. [Comment removed by author]

                                                                                1. 1

                                                                                  social contract of open source

                                                                                  This is something new.

                                                                                  1. 5

                                                                                    New? Not really. Debian has a well-stated social contract: https://www.debian.org/social_contract

                                                                                    1. 3

                                                                                      Huh. It’s Debian’s “social contract”. Do you see the difference between somebody publishing “a set of commitments that we agree to abide by” and a non-existing unspecified thing that the poster above requires Facebook to abide by just because they published and maintain some open source code?

                                                                                  2. 1

                                                                                    So, the issue is that they deliberately added this “patent clause” to induce fear to everyone who thinks about suing Facebook? And not that using React is risky?

                                                                                  3. 3

                                                                                    Does Facebook actually have patents covering React? I’ve looked around a few times and have never seen a link to an actual patent covering it. I would assume there’s gobs of prior art for anything going on in there.

                                                                                    1. 5

                                                                                      AFAIK they’ve never stated public which ones, if any.

                                                                                      Submarine patents are a thing, sadly.

                                                                                    2. 2

                                                                                      And yet, there are a number of big companies which undoubtedly have big legal teams, and which seem to be okay with using React somewhere. Just cherry-picking some from the list [0]

                                                                                      Airbnb, American Express, Chrysler, Atlassian, eBay, Expedia, Microsoft, NHL, Netflix, New York Times, Salesforce, Twitter, Visa, Walmart… At least some of these companies must have had their legal teams look at the license and decide it was okay to use to use React. Which makes me wonder if the hysteria (this is a bit of hyperbole, but it does seem to have some people really worked up) is justified.

                                                                                      [0] https://github.com/facebook/react/wiki/sites-using-react

                                                                                      1. 8

                                                                                        You’re assuming they’re using the “off-the-shelf” license. There’s nothing preventing them from negotiating a different license with Facebook. Now, I haven’t seen anything showing that this has happened, but it’s a fairly common practice to have individualized contracts with traditional commercial software, so it wouldn’t shock me.

                                                                                        1. 3

                                                                                          It would surprise me, though - why would Facebook enter into an agreement with these big name companies that altered the React license out of Facebook’s favor? I don’t think all these companies did that (and I didn’t list every large or well-known company that’s on that link, by the way), and unless they’re paying FB to use React I just don’t know why FB legal would bother with all the work. Individual negotations with legal teams at all these big companies to reach a mutually agreeable license, just so a dev team can use React? It seems really unlikely. Just as unlikely as all these companies paying FB to get some kind of commerical license for React - when there is no suggestion that such a thing exists.

                                                                                          1. 2

                                                                                            I assume they are paying. Just because things don’t have a price list or an explicit offer of a commercial license doesn’t mean you can’t get one.

                                                                                            1. 2

                                                                                              Right, I get that. I just don’t think it’s actually happening. Since there’s no evidence either way I guess we won’t be able to figure it out!

                                                                                    1. 4

                                                                                      I really want to move to mail in the terminal, like Mutt. But I can’t do that because my Inbox Zero workflow relies entirely on Google Inbox clustering mail for me, hiding anything that isn’t directly addressed to me until the next day, letting me snooze mail I can’t deal with yet… I wish there was a terminal equivalent! (whereby “wish” means “it would be rad but I don’t have the time to do it so don’t reply telling me to scratch my own itch ;) )

                                                                                      1. 3

                                                                                        Depending on what you’re doing, scratching this itch shouldn’t actually be very hard. I have a very simple mail filter that just kicks anything not addressed to me personally into a folder called Triage that I go through once a day. Doesn’t break things down as far as Inbox, but gets me 99% of the way there. (I’ve also gradually added additional bucketing for travel and whatnot, but that’s been a slow burn.) If you want to use Mutt, something like this remind-based workflow would then cover your snoozing just fine.

                                                                                        It’s completely fine if that’s not enough; Inbox does a lot. But based on the two things you highlighted, you might be surprised how quick it is to get to 90%.

                                                                                        1. 2

                                                                                          You definitely can manage something of the like easily with mblaze. I’m using it for email along with fzf, and it’s been fun so far. I have a few shell scripts to help with redundancy, and that kind of clustering is like two pipes away.

                                                                                        1. 9

                                                                                          I admit to not being a much of an ESR fan, but this actually seems like a fairly reasonable post.

                                                                                          I gave rust a try a while ago (shortly after 1.0 shipped, as I recall), and at the time, I didn’t find it a very pleasant fit for the kinds of things I wanted to do (network services (http, tcp, udp)). Maybe I just didn’t “get it” or “didn’t give it enough time”. Not sure.
                                                                                          I currently use Go (or python for the occasional rest api), and find it “pretty ok”.

                                                                                          Makes me wonder what languages I will be using over the course of the next 5 years though.
                                                                                          Server-side Swift? Will D finally break out? Crystal? Elixir? Nim? Pony? Myrddin?

                                                                                          1. 1

                                                                                            I’m seeing a TON of activity in Elixir. Its Ruby-like syntax and real erlang derived MP model seem like a really solid value prop with a relatively shallow learning curve.

                                                                                            1. 9

                                                                                              The question is what systems programming language will we be using. There’s a ton of comfortable high level languages, but by contrast there are only a handful of systems programming languages. It’s 2017, and I think people are growing tired of buffer overflows, and are super keen to wave manual memory management goodbye. But then GC doesn’t suit systems programming either. This is the “niche” rust is trying to address, but we have yet to see if the learning curve will be its demise.

                                                                                              1. 3

                                                                                                I’m looking forward to a time when the phrase “systems programming” doesn’t implicitly throw out the idea of a garbage collector. I’d personally like it if Go was a little bit more strict about stuff like checking for err, but if someone said “Hey, we’re going to write an operating system top to bottom in Go” I’d be all for it. Whatever inflection point we needed between user expectations and hardware limitations that called for no garbage collection we went past a long time ago.

                                                                                                I could have maybe entertained the idea that my phone would need it, but my phone has such horsepower now that manually managing object lifecycles is a much smaller issue than just straight up business logic bugs.

                                                                                                Maybe the network stack for a real time online video game. But if we’re doing that, we don’t need a brand-new language to do it; safety isn’t the concern there.

                                                                                                1. 2

                                                                                                  Are you sure about that? I don’t doubt what you’re saying, but I’m hearing and seeing an awful lot of movement around go even in contexts that would have been previously considered to be “systems programming”.

                                                                                                  I agree there will always be a niche for non gc languages that need max to the metal performance, but how big that niche is has yet to be determined IMO.

                                                                                                  As to Rust, I think most people agree there’s an enormous amount of untapped potential there. It’s unfortunate that some large company with associated large $$ and man hours doesn’t back the project. I think that would help smooth some of the rough edges and make the adoption experience a bit smoother.

                                                                                                2. 4

                                                                                                  Elixir has a shallow learning curve. OTP (the main benefit of BEAM languages) doesn’t, especially for web developers used to Ruby and Node. It’s not “hard” or impossible, but like Rust, it’s not Python.

                                                                                                  1. 1

                                                                                                    Good point about the OTP aspects.

                                                                                                    I’d be interested to learn what the performance characteristics of non OTP Elixir are versus similar code running in Ruby or Python.

                                                                                                    1. 4

                                                                                                      Anecdotally, I’d say Elixir feels about 2-3x faster than Ruby or Python in the single-threaded case. But just about any Elixir app will use multiple processes (Erlang processes, not OS processes), and at that point the benefits of concurrency quickly leave Ruby and Python in the dust.

                                                                                                      EDIT: A couple of benchmarks say roughly the same thing I do:

                                                                                                      1. 2

                                                                                                        I think raw Elixir is faster, but the problem is that every real world library or use case of Elixir will use OTP in some way or another (at the very least, a GenServer, which is admittedly very easy to learn).

                                                                                                1. 17

                                                                                                  The idea that the go language designers and implementors are nondogmatic is an interesting assertion to make, but it’d be better if there were a citation or an example. Certainly there are, famously, many more counterexamples, so it would be great to understand why the author has this belief. Is it from experience? Or is it from an ardent wish that it be true?

                                                                                                  1. 9

                                                                                                    I am a huge fan of Go, bet businesses on it, have had great successes with it, that said…

                                                                                                    … why the author has this belief. Is it from experience?

                                                                                                    I have no doubt that this is the truth. I believe the core team is very willing to discuss things at length, non-dogmatically with those they consider peers (language designers, researchers). But how they dealt with the community in both tone and substance was another thing all together – they set the dogmatic “no questions” (less charitably, “we are right”) tone absolutely, and the community followed.

                                                                                                    Or is it from an ardent wish that it be true?

                                                                                                    Or I suspect, a hope for the future. Which is fine, if your community has issues, try to change them and the change has to start from people with voices with enough reach, rsc is one of those voices.

                                                                                                    1. 9

                                                                                                      The go team are a bit similar to how openbsd works. If its clear you dont know what you are talking about, you will be redirected to go-nuts.

                                                                                                      Tbh i think they are incredibly patient with lots of bad and unresearched suggestions. Good suggestiona get a great deal of consideration

                                                                                                    2. 6

                                                                                                      rsc is just one of the Go designers/implementers, and is probably somewhat less opinionated than, say, Rob Pike.

                                                                                                      My guess is rsc is reposting this as much as a reminder to himself as to others. Go is probably more famous for what it expressly leaves out than what it leaves in, and so remembering to say why something was left out is pretty hard versus just saying “because that’s not Go.”

                                                                                                      1. [Comment removed by author]

                                                                                                        1. 4

                                                                                                          I was surprised to come here to see a lot of objection to the Lisper’s suggestion that language designers tend to be open to talking about tradeoffs because they had to consider them during the design process. I read the point of the piece as the conclusion, asking the community to be fair and complete in talking about pluses and minuses:

                                                                                                          But we need help from everyone. Remember that none of the decisions in Go are infallible; they’re just our best attempts at the time we made them, not wisdom received on stone tablets. If someone asks why Go does X instead of Y, please try to present the engineering reasons fairly, including for Y, and avoid argument solely by appeal to authority. It’s too easy to fall into the “well that’s just not how it’s done here” trap. And now that I know about and watch for that trap, I see it in nearly every technical community, although some more than others.

                                                                                                        2. 5

                                                                                                          The idea that the go language designers and implementors are nondogmatic is an interesting assertion to make

                                                                                                          I don’t think he’s actually making that assertion - he’s saying that the conversations language designers (of different languages) have amongst each other don’t appeal to dogma. Citations, then, could really only come from specific recorded conversations amongst only language designers.

                                                                                                          There is this slightly disappointing panel with Bjarne Stroustrup, Rob Pike, Niko Matsakis (of Rust), and Andrei Alexandrescu (of C++ and D), whose most dogmatic participant seems (to me) to be Rob Pike, but if you’re hoping for an in-person flame war, it’s not there.

                                                                                                          1. 3

                                                                                                            Replied something like this to dwc, but I’m surprised the focus here ended up on the Lisper saying that language designers are comfortable talking about tradeoffs because they had to wrestle with them while designing.

                                                                                                            Seems like a nice enough anecdote and my reaction wouldn’t be to demand citations proving anyone’s thoughtfulness. But more fundamentally, the story was just a stop on the way to asking users to “[r]emember that none of the decisions in Go are infallible” and “present the engineering reasons fairly.” Hard for me to find that objectionable.