1. 3

    This is an old brain-dump, but I’m posting it in response to https://lobste.rs/s/mxcmxg/abstraction_is_okay_magic_is_not. I should definitely update this, and add whatever magic is. I don’t think “magic” is precisely the same as either of my three categories.

    1. 1

      It’s a good brain-dump, and I agree with it. I will note that my post (I wrote the ‘Abstraction is Okay’ article) was not exactly aimed at defining what abstraction is. Instead it’s just a musing on a pattern I’ve experienced as a consumer many times and how I consciously avoid producing it myself.

      I have concrete examples of “magic,” but I’d rather not share them because they’d tend to be very recognizable to the people who wrote them. Here’s an anonymized example I debated including in the post:

      @Wire(WidgetModel)
      @NormalPaths(exclude = AsyncPaths)
      @VarySerializer(determinant = ClientAuthentication)
      class WidgetService extends BasicModelService {
          // No code necessary!
      }
      

      What does this do? What does it accept? How do you modify it? It’s the kind of thing that someone presents and says proudly: “Look at how easy it is to implement a service!” but its name quickly becomes a portent of dread the minute they move on to another project or another job.

      “Hey, Beth, I was wondering how this thing in MagicalWeb works…”

      “Oh, man. Don’t worry about that crap, that’s Chuck’s stuff. He’s been gone for ages, and we’re trying to kill it. Add your path to the if statement in SkipThatCrap.java.”

    1. 2

      I haven’t read it yet, but the author of An Elegant Puzzle also has a new book called Staff Engineer: Leadership Beyond the Management Track. Unfortunately, it’s self published, so it’s probably wise to wait for reviews.

      1. 4

        Until there are Linux equivalents, not just “clones,” of the Adobe toolchain in Linux, this is to be expected. You can hire professional designers and let them use the tools they need, or you can say “GIMP and Scribus only!” and turn out terrible looking publications because most designers won’t work with those tools.

        Alternately, they could use LaTeX or troff and produce the sorts of documents that those tools are great at producing.

        1. 7

          There are people who produce excellent quality output using those tools, like David Revoy. At least some of those people are even available for hire.

          1. 1

            You can hire professional designers and let them use the tools they need…

            Never met these professional designers you talk of. Far more often it’s just status signalling jerks who use the most expensive hardware and software because they do the “social media magic” or “glossy brochure secret sauce” everyone is so crazy about lately.

            I’ve met several video specialists who did not understand their formats nor did have any meaningful video editing skills.

            I’ve met UI designers who were unable to explain white space rules for an UI kit they “designed”.

            I’ve met PR staff who did not even know how they’ve licensed the illustrations for a book they’ve published only to find they were - of course - not compliant.

            I’d take someone who can use Scribus and GIMP and Inkscape over anyone who “needs” Adobe products, because the later only guarantees high costs. Not better results.

            Also, the brochure could’ve been set as effectively in LibreOffice on Linux. There is nothing special in it.

            1. 3

              Never met these professional designers you talk of. Far more often it’s just status signalling jerks who use the most expensive hardware and software because they do the “social media magic” or “glossy brochure secret sauce” everyone is so crazy about lately.

              You need to expand your social circle. I e-know plenty of people who work in graphic design who are both professional and passionate about their work.

              1. 1

                Yeah, might be a central Europe thing, because that’s what sits on the other side of the table when we open a public tender or try hiring.

                And don’t get me started on their salesmen…

          1. 1

            Overall, I think this event is the worst I’ve experienced with Amazon. It took twenty-two hours for full recovery of some systems, and the analysis here indicates that this was at least partially because of some really poor architectural choices, like using a thread per server in the farm on every server in the farm and running so many critical subsystems on the same substrate with no damage control measures.

            1. 8

              This is a good talk, and I think it’s a positive that we’re getting more features in terminals. Far from being bloat, I find that better font handling helps me avoid eye strain; viewing non-ASCII text is actually possible (although sometimes still ugly); and I can eliminate tmux/screen, which I have always found annoying to configure and never perfectly ergonomic. Even frivolous-seeming features like ligatures can help make symbol-heavy languages like Rust more readable.

              1. 2

                This is honestly fantastic. (sin(t/i)+tan(i/t))/(x*y)

                1. 4

                  Unfortunately, this doesn’t seem to conform to any previously-defined standards (JMESPath, JSONiq, XPath) or existing tools (jq, json-query, etc.), so this will go on the pile of Yet Another Data Querying Syntax.

                  1. 11

                    I always felt like SPAs were created to make data on pages load faster, while simplifying for mobile web, but they ended up making development more complicated, introduced a bunch of bloated frameworks, required tooling to trim the bloat, and ultimately tried to unnecessarily rewrite HTTP.

                    1. 13

                      Yeah, we started with “no need to load data for the header twice” and ended up with bloated multi-megabyte javascript blobs with loading times in tens of seconds. :(

                      1. 6

                        I think the focus shifted more from “need to load data faster” to “need to be able to properly architecture out frontend systems”.

                        Even though I still “just use jQuery like it’s 2010”, I can’t deny there aren’t problems with the ad-hoc DOM manipulation approach. One way to see this is that the DOM is this big global state thing that various functions are mutating, which can lead to problems if you’re not careful.

                        So some better architecture in front of that doesn’t strike me as a bad thing as such, and sacrificing some load speed for that is probably acceptable too.

                        That being said, “4.09 MB / 1.04 MB transferred” for the nytimes.com homepage (and that’s the minified version!) is of course fairly excessive and somewhat ridiculous. I’ve always wondered what’s in all of that 🤔

                        1. 5

                          “need to be able to properly architecture out frontend systems”

                          An absolute shitload of websites are built with React that could be built entirely with server rendered HTML, page navigations, and 100 lines of vanilla JS per page. Not everything is Google Docs.

                          Recent example: I recently was apartment hunting. All the different communities had SPAs to navigate the floor plans, availability, and application process. Fancy pop up windows when you click a floor plan, loading available apartments only when clicking on “Check Availability” and so on.

                          But why? The pop up windows just made it incredibly obnoxious to compare floor plans. They were buggy on mobile. The entire list of available units for an apartment building could have been a few kilobytes of server rendered HTML or embedded JSON.

                          Every single one of those websites would have been better using static layouts, page navigations, and regular HTML forms.

                          1. 5

                            One reason for a lot of that is that people want to build everything against an API so they can re-use it for the web frontend, Android app, iOS app, and perhaps something else. I wrote a comment about this before which I can’t find right now: but a large reason for all of this SPA stuff is because of mobile.

                            Other than that, yeah, I feel most websites would be better with just server-side rendering of HTML with some JS sprinkled on top. But often it’s not just about the website.

                            1. 6

                              I don’t think an API and server-side rendering have to be incompatible, you could just do internal calls to the API to get the data to render server-side.

                              1. 5

                                That’s what we’re doing. We even make a call to API without HTTP and JSON serialization, but it’s still a call to an API which will be used by mobile app.

                                1. 1

                                  Having done this, I feel this is the way to go for most apps. Even if the backend doesn’t end up calling a web API, just importing a library or however you want to interface is fine too, if not preferable. I’m a big fan of 1 implementation, multiple interface formats.

                              2. 1

                                I’ve worked in that industry. A large portion of it is based on the need to sell the sites. Property management companies are pretty bad at anything “technical,” and they will always choose something flashy over functional. A lot of the data is already exposed via APIs and file shipment, too, so AJAX-based data loading with a JavaScript front end comes “naturally.”

                          2. 3

                            I agree. So, to answer the titular question, I would answer: websites and native applications.

                            Developing “stuff” that feels like a website fitting the HTTP paradigm is mostly straightforward, pleasant, inexpensive, and comparatively unprofitable.

                            Developing “stuff” that feels like an application fitting the native OS paradigm is relatively straightforward, occasionally pleasant, often expensive, and comparatively unprofitable.

                            If we’re limiting our scope to a technical discussion, it seems straightforward to answer the question. Of course, for better or worse, we don’t live in a world where tech stack decisions are based on those technical discussions alone; the “comparatively unprofitable” attribute eclipses the other considerations.

                            1. 1

                              That’s how I remember it. I also remember building SPAs multiple years before React was announced, although back then I don’t recall using the term SPA to describe what they were.

                            1. 1

                              Whenever I encounter a post about addresses, I like to introduce people to the wonders of Hickory, North Carolina, whose baffling streets are an artifact of a benighted attempt to “systematize” addresses within the city; Tokyo, which has many unnamed streets and uses neighborhoods and blocks as its addressing basis; and Ho Chi Minh City, which does what it feels like (e.g. “3-02 14/A Hẻm 46/2,” or a building with an address that doesn’t actually front the road in the address? entirely possible!).

                              1. 4
                                1. Does the Internet ever like multiparadigm languages? I’m trying to think of one that it does. Even with something like OCaml, everyone quickly says, “and don’t use the OO part!”

                                2. Does the Internet ever look back fondly on older, dominant languages? There’s a narrative that the older languages must be defective because we’ve all moved on; this is a necessary belief for the orthodoxy of progress to be held.

                                These are meta questions that don’t apply to C++ as much as languages themselves.

                                1. 3

                                  I will freely admit that I prefer opinionated languages over anything goes languages. Multiparadigm languages I think fall in the anything goes category. I find that the more paradigms I need to hold in my head the more likely I’m going to be frustrated when I’m debugging an issue in production concerning 5 year old code. I think this is because:

                                  • My actual on the job greenfield development experience is close to nil.
                                  • I spend 80% of my on the job time reading and detangling old code.

                                  As a result the less cognitive overhead a language forces onto me the better I like it. It’s the same reason why I prefer explicit to implicit code.

                                  1. 4

                                    I think the core issue is that multiparadigm languages are rarely orthogonal – instead of merging functionality from different paradigms (where it makes sense) they just have them living alongside each other.

                                    That’s why I believe that there is nothing inherently “larger” or “anything goes” about multiparadigm languages, it’s just many of the existing examples did a poor job.

                                    One trivial example is if-then-else statements, ternary expressions and pattern matching – there is no reason why a language needs to have all three! Just merge them until you have “one way of doing things”.

                                  2. 3

                                    Does the Internet ever look back fondly on older, dominant languages?

                                    I see love for plain C.

                                    I don’t think you can write off C++ hate as hipsterism.

                                    1. 2

                                      I don’t know who counts as “the Internet,” but it’s definitely possible to appreciate older languages that are well-designed. For example, Ada is intriguing (I think it’s even had a tiny renaissance as people are revisiting) and, of course, Lisp lives on. Even languages like Fortran are, if not loved, then at least respected. C also isn’t hated, although experience has shown us that it has flaws (memory safety, undefined behavior, and so on.)

                                      As for the first question, it depends on what you mean by “multiparadigm.” Python is certainly a hybrid language. You could argue that a language like Rust is a multiparadigm language with procedural and functional aspects. In fact, you can use structs in Rust and Go in a way that approximates the hybrid approaches of Python.

                                      The issue with C++ (and some other multiparadigm languages) is that it feels like the implications of the combinations of features aren’t thought through (or, in some cases, even thought of).

                                    1. 6

                                      My wife and I started studying Mandarin together using a “gamified” app, Super Chinese. It’s a fun little break at the end of the day as we compete to get higher scores on pronunciation and tests. 很有趣!

                                      1. 2

                                        The problem I always had with Haskell (for context, I have spent a significant amount of time with Haskell and compiling Haskell) was that the proponents would aggressively push performance, and laziness as a path to performance, at the same time, but any time anyone was doing actual performance sensitive stuff they would switch more or immediately to strict evaluation.

                                        to my mind this hurt Haskell in that it meant non-haskell programmers were being told lazy evaluation made everything better, but were subsequently told to rework everything to remove the laziness whenever there was the smallest perf problem. It turns it from a standard “how do I get the best perf out of this language?” problem, and into an “I have been mislead” problem. That hurts the reputation of the language.

                                        Now personally, my problems with Haskell have always been that it mandates functional programming in the strict sense. That means that something that would be trivial in imperative languages - adding basic logging, etc - suddenly requires substantial changes everywhere that has explicit types. While explicit types are theoretically not necessary (beyond higher minded types), a lot of standard practice Haskell has explicit types specified, and that is an instant compilation failure.

                                        For impure functional languages, and for more or less all imperative languages there is no need to consider the behavior of inner functions in your external API, but the purity needs of Haskell require it. My personal feeling is that this is not a good design feature, even if logically it is a “sensible” language feature, and I’m not sure if it would be as much of a problem if I had been raised in a world of pure languages, so I can see valid arguments on each side here.

                                        The other problem I’ve encountered is the emphasis on line or character count of solutions to fairly specific problems. A lot of the reduced character/line count comes as a byproduct of a substantial standard library (though honestly more languages should just have this), and the gratuitous use of new operators. People complain bitterly about the overloading of operators in c++, but a lot of brevity in Haskell is a byproduct of just that, and a lot of the remainder is a byproduct of allowing a dev to define arbitrary infix operators.

                                        1. 1

                                          It feels like the “impurities” that are required in Haskell need to be divided somehow into “incoming” and “outgoing” effects… so, for example, logging and metrics shouldn’t really be reflected in producers’ types, or should be captured at a second level of types, whereas consuming external values obviously has more important implications. That would go a long way toward simplifying the ergonomics of pure languages, in my opinion, and still allow the elimination of many sources of non-determinism. Of course, one of Rust’s strengths (to me) is how it encourages a sort of purity by making you think about where values are produced and consumed more carefully.

                                          1. 1

                                            sorry, I missed this - in the Haskell type system it is never sound to put a function with side effects in a context that does not force you to pass state through it (there’s a literal internal type in GHC called RealWorld, and instance of which is passed into main). The reason you can’t do that is that if a function has no side effects (e.g. doesn’t produce a value the feeds forward) then you can execute that function multiple times with the same arguments (screwing up logging), you can coalesce multiple calls with the same argument (if nothing else that could mean hoisting out of a loop), and of course if the function doesn’t indicate that it changes some state (by returning a new state), then you don’t need to call the logging function at all.

                                            All of these conspire to break “side-effect free” logging.

                                            1. 1

                                              Yeah, I understand. I was thinking more about “some future type system.” Something with a concept of “sink effects” versus “source effects.”

                                        1. 2

                                          I use org-mode, or simple markdown files for short and self-contained notes. However, if I have a large project that spans a long time (language learning, history notes, etc.) I actually use a local instance of gitit. It’s nice to have a dedicated interface with search and so on, and you can edit pages in your text editor of choice as well.

                                          1. 1

                                            I’ve read so many k8s articles in the past years that I feel like I almost have intimate knowledge of this piece of software, even though I have not used it productively before. It’s obviously pretty strong at allowing applications to scale up whenever in high demand.

                                            Kubernetes will automatically manage your resources for you. If configured correctly, it can survive even if a “node”, or a server in the cluster, becomes unaccessible, with no input required from the user. Kubernetes through some service providers can scale up workloads to massive amounts temporarily, which can be incredibly useful if your service becomes very popular and you suddenly gain a lot of traffic. Running a Kubernetes system means you can reduce your downtime to an insanely small level, and increase your computational capacity to an insanely large level. While this may not seem useful up front, you may consider it essential down the line.

                                            Are there persons here who have designed and deployed applications on k8s for non-enterprise use, and have actually gotten to make use of the most important features of k8s: prevented downtime and scaling up (due to high increases in traffic/capacity)? I’m talking here about blogs, web services, apps, mobile apps, mostly deployed and maintained by a single developer.

                                            1. 4

                                              I have been working on Kubernetes for my company for about two years. It’s had a lot of benefits for our use cases, but I would never use it for a one-developer project. It’s simply not worth it – the things it solves for you aren’t going to be problems you have. I’d even say things like downtime and scaling up aren’t as big a deal at that level of functionality; I’d think that it’s often better for a blog to fall over than to scale at the level that some of the apps I work on scale, simply due to cost. (Are you okay with paying $900 for one day’s traffic spike?) Some of the things that it does don’t even make sense if you’re not working in a particular type of environment.

                                              1. 3

                                                As a sole developer, you have near-zero communications overhead; you can just remember / write down the state of play, and everyone who has to maintain it will automatically know. You never (eg) accidentally try to run two deploys at the same time, even if you don’t implement a mutex around your deploy process. Implementing k8s can consume all of your team-of-ones output for weeks.

                                                Adding kubernetes (or similar kinds of complex system) can be fantastic for big teams. Having a single source of truth RE the status of the app is a tremendous advantage. It only takes a small fraction of the teams output to implement. The cost/benefit is totally different.

                                              1. 64

                                                This is one of those things where I simply don’t understand why people insist that empirical science gives a definitive answer, or why people even care what the science says. I switch freely between light and dark schemes, and I do so based on the evidence of… my eyes. If it’s bright in my office I find dark screens harder and more tiring to read. If it’s dark, I find light screens harder to read. I prefer dark, overall, so I keep my office as dark as possible, usually.

                                                The question of which is “proven” to be superior, in lab conditions not using my eyes, is irrelevant. Having statistics doesn’t make it true.

                                                1. 12

                                                  To some, science is religion, so invoking capital-S science justifies their subjective opinions, as if that’s what it’s for. To the rest of us, it looks quite silly and we can see right through it.

                                                  I blame Solarized for even putting forth the notion that color schemes are anything other than preference.

                                                  1. 10

                                                    It seems like most people need permission from science to have any beliefs at all these days. I think articles like this shake people out of it a bit, but people carry that need with them to everything that’s not obviously subjective.

                                                    I don’t think there’s anything wrong with bringing science into colorschemes or anything, I think most people should try doing a bit more of it because I think programming experience and aesthetic pleasure, while connected, aren’t the same thing. Try using acme colors or otherwise minimal, or turn highlighting off entirely every once in a while. Maybe try rainbowy semantic highlighting if you’re a minimalist already.

                                                    1. 2

                                                      It seems like most people need permission from science to have any beliefs at all these days.

                                                      I think it’s the opposite, no? Many people hold beliefs despite the science, heck, some chunk of them believe that if something rhymes it has to be true.

                                                      The article is trying to answer what is better for some narrow definition of better, that matches author’s beliefs. If it were written in e-simple, it would have had a different message. But, as you and many say, color schemes are highly subjective areas — better is what we claim is better.

                                                      1. 1

                                                        some chunk of them believe that if something rhymes it has to be true.

                                                        Maybe we’re getting off-topic here, but I’ve never known anyone like that. Even the most religious people I know of would warn you that the devil has catchy songs, maybe even more catchy songs than God does.

                                                        1. 1

                                                          I don’t know anyone who claims it at the face value, but there are always subtle psychological effects: https://apoorvupreti.com/if-it-rhymes-it-must-be-true/

                                                  2. 12

                                                    …or why people even care what the science says.

                                                    Exactly, especially when it is debatable whether the science is even answering the question we find interesting.

                                                    1. 1

                                                      This is something I’ve been wondering about, because I’m one of these people who feels the urge to tell others about how light themes are actually better than they think. What’s the impulse?

                                                      I think it comes down to culture. Dark editor themes seem to be the norm nowadays, and using a light theme actually draws attention. New colleagues will often make surprised comments when they see my editor—in the same way they’d comment about someone not being able to touch type. They don’t outwardly criticize, but it’s transparent it’s not something they expect from an experienced developer.

                                                      So, as a result, it gets me thinking a lot about why I’m using a light theme despite it being a bit looked down upon. It’s very possible this is a common motivation for speaking out about the light/dark science!

                                                    1. 3

                                                      One more argument to move to miniflux.

                                                      1. 1

                                                        Paid hosting sign ups are closed there. Which is too bad, I don’t really want to self host this since it only works with postgres, and I have no other reason to setup/run/maintain postgres.

                                                        1. 2

                                                          That does tend to be annoying, but my experience with maintaining postgres for my email setup so far has been to 1) set it up, 2) configure backups &c and 3) forget about it. So if you’re willing to put in the up-front work it’s probably pretty painless.

                                                          1. 1

                                                            Postgres has a pretty easy-to-use docker container, which would probably be adequate for this use.

                                                            1. 2

                                                              Except when trying to migrate to another major postgres release, which isn’t all that easy with those containers.

                                                              1. 1

                                                                In that case and for this use I’d probably just do a dump and restore. There’s no downtime limitation, so that seems like it should be adequate.

                                                          2. 1

                                                            I’d never heard of this but just installed it, it’s cool. Light in resources, Debian package repo, clear installation instructions and it feels faster than ttrss. I’ve been using and advocating ttrss for years, but this might be my switch moment. The content parsing is better and it does not require an app on mobile. With ttrss I cannot subscribe to a feed in the ios app…

                                                            Thank you!

                                                            1. 1

                                                              The only thing that keeps me from ditching ttrss is that miniflux seems to have no ability to adjust the sorting. I prefer to have the newest articles on top on the first page.

                                                              1. 2

                                                                Under Settings there seems to be a sort option. I also want newest on top: https://i.postimg.cc/bN85Jvwn/Selectie-0988.png

                                                                1. 1

                                                                  Nice thanks!

                                                          1. 11

                                                            Do you know either language?

                                                            Use the one that you know.

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

                                                            1. 5

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

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

                                                              1. 18

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

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

                                                                1. 4

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

                                                                  1. 6

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

                                                                2. 5

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

                                                              1. 7

                                                                I have written a few microservices in both Go and Rust (including translating some from Go to Rust). There are benefits, particularly over Python (my previous go-to language), but you must recognize that you’re trading a decent amount of maturity for a number of rough edges. In the cases where I am using Rust, that’s fine – but I am also consciously using it for small, self-contained components until the web and database stories “firm up” some. If you’re curious, the frameworks I use are tokio and warp. warp is a higher-level abstraction on top of hyper. For database work I have had some success with sqlx.

                                                                1. 4

                                                                  I think this is bad because the Clojure code is unreadable. If you use HOFs in restrained, sensible ways, with effective naming conventions, they can be just as clear as everything else:

                                                                  # Python
                                                                  filter(Lease.expiring, leases)
                                                                  
                                                                  # Ruby
                                                                  bills.filter(&:paid?)
                                                                  
                                                                  # Haskell
                                                                  filter (\v -> fuelLevel v > threshold) vehiclesOnLot
                                                                  

                                                                  It all just boils down to careful, reasonable naming.

                                                                  Of course, fold is a little less familiar, so those tend to look “weirder” overall than filter, and unfold is almost always a poor choice just because of its unfamiliarity.

                                                                  1. 2

                                                                    This is funny, because beginning of the post argues that using HOFs in filter is actually okay!

                                                                    1. 1

                                                                      The example you give of bad HOFs is also an application of filter, though.

                                                                  1. 22

                                                                    When I saw the text “At the beginning of 2030”, I thought this essay was going to use the narrative conceit of claiming to be a historical retrospective on the present day, published in the future. But the essay doesn’t do anything with that premise, so now I suspect it’s just a typo for 2020. I see that at the end it claims to be an existing talk about Smalltalk with Haskell and Rust substituted in appropriately. I’m not familiar with that original Smalltalk talk though.

                                                                    In any case, I don’t think the object-level point this essay is making holds. In general, I’m skeptical of arguments saying that “such and such language community is arrogant, therefore Y”. It’s easy for an essay-writer or internet commenter to remember a small number of particular interactions with a particular group of people who happened to be advocating for the merits of some programming language over another, and incorrectly attribute this to a property of that programming language. Note the argument in the comments about whether it’s actually Go users who are prototypical examples of arrogance. I don’t generally expect to agree with programming language essayists over whether some example of discourse actually constitutes arrogance - it’s a common trait for people who are arrogant themselves, to accuse others of being arrogant.

                                                                    Haskell also has some important differences from Rust in design and and purpose, that do a lot to explain why Rust is more popular among industry developers than Haskell is. Haskell is fundamentally a research project in lazy functional programming design, whereas Rust is fundamentally a project to make well-established ideas from programming language research readily available to industry programmers, particularly ideas for statically-checking memory safety (which isn’t a research concern of Haskell’s). Rust notably borrowed some ideas from Haskell, such as traits (Haskell typeclasses), and I don’t think anyone working on Haskell would consider it a failure of theirs that an industry-focused language that borrowed ideas from their work happens to be more widely used in industry.

                                                                    Still, I don’t think it’s accurate to say that Haskell is “killed” (certainly it’s a lot easier to get a job in 2020 writing Haskell than writing Smalltalk!). It’s not among the most popular programming languages, but software-writing organizations do in fact use it. The language is being actively developed, (better) tooling around the language is being actively developed. People who care about functional programming reference it quite a bit, even if it’s in the context of applying Haskell ideas to non-Haskell programming languages.

                                                                    1. 7

                                                                      In general, I’m skeptical of arguments saying that “such and such language community is arrogant, therefore Y”. It’s easy for an essay-writer or internet commenter to remember a small number of particular interactions with a particular group of people who happened to be advocating for the merits of some programming language over another, and incorrectly attribute this to a property of that programming language.

                                                                      Plus, of course, the trolls: There’s plenty of people on Reddit, for example, who are “advocating for Rust” in a way that makes Rust advocates seem unhinged, which is the point. Maybe some of them hate the language, but most of them are downvote trolls (“Look at me! Downvote me! LOOK! AT! ME!”) riding a fad.

                                                                      1. 13

                                                                        I’m not so blind as to confuse the arrogance of Rust users with a flaw in the language itself, but I have noticed a fair amount of arrogance from the Rust community. This isn’t just “a few bad experiences in a sea of good ones”: every time I’ve interacted with the Rust community, I’ve had at least one or two responses that would be considered unwelcoming and arrogant. It’s not just trolling, I don’t think.

                                                                        I’ve had this happen on Twitter, here on lobste.rs, Stack Overflow, and various other places.

                                                                        (I avoid Reddit for the most part; if I wanted to know that COVID-19 was a hoax designed to destroy Trump or find out that same-sex marriage is Satanism, I’d just talk to my mother’s side of the family.)

                                                                        I think the perceived arrogance of the Rust community has some basis in reality, and I also think that it comes from Rust being a relatively new community, a relatively small community, a relatively technically-superior community, and a relatively unsupported community.

                                                                        Rust is technically superior compared to many other languages. Rust is the new kid on the systems-programming block. Rust has a relatively small community. Rust is not supported by Google or Oracle or Microsoft or Apple (yeah, Mozilla, but Mozilla is peanuts compared to those guys). All of this adds up to a “siege” mentality. The Amiga community was and is like that, and for often very similar reasons. I think a lot of the Rust community’s arrogance is perhaps a degenerate case of Amiga Persecution Complex.

                                                                        That being said, while I like Rust and I’m learning it and I plan to make it my next big language for major projects…the community needs to get better. I think that will happen with time, as it grows and the ratio of True Believers to Just Want To Get Work Done people shifts.

                                                                        1. 7

                                                                          I think the perceived arrogance of the Rust community has some basis in reality, and I also think that it comes from Rust being a relatively new community, a relatively small community, a relatively technically-superior community, and a relatively unsupported community.

                                                                          I agree with all of this, but I think there’s another thing at play: Rust is a technically different community in a way that matters. It isn’t GC’d, it’s ownership-managed, and that isn’t unimpeachable yet. If Rust fails, ownership-management fails, too, at least in terms of mainstream adoption, so your intellectual investment in that paradigm begins to look like getting taken for a ride by a silver-tongued scammer. OTOH, if Go fails, nobody’s going to Seriously Reevaluate the value of GC’d programming languages.

                                                                          1. 5

                                                                            Don’t worry, linear types failed many times before they had their first glimpse of mainstream success in Rust. ;)

                                                                            And so did GC, it failed even more times before it finally succeeded.

                                                                            1. 2

                                                                              I’m not waiting another 10-20 years.

                                                                          2. 4

                                                                            It’s interesting that you say this, as I’ve actually found the community very approachable. Almost every major project has a Discord (pour one out for IRC…) and I’ve yet to have a really negative experience in one of them. I contrast this with older communities like the extremely toxic C and Linux IRC channels, where it was more of a surprise not to have a bad experience (at least as a beginner). General discussion forums vary, of course, particularly on sites like Reddit, but I’ve also never seen anything in Rust to rival the little nucleus of horrible people who floated around the Haskell and Scala communities for a long time. Even on Github issues, I’ve had pretty good reception and discussion, whereas in more mainstream communities like Python or Javascript I’ve seen (or been on the receiving end of) very negative behavior.

                                                                            The only really bad community behavior I’ve seen was surrounding actix, where I actually think the community was too nice. The maintainer’s behavior was extremely abrasive and negative, but people in the community acted like the reactions to this toxicity were themselves problematic. It reminded me of someone getting suspended from school for punching their bully.

                                                                            1. 5

                                                                              Rust is very interesting in that it is a language in which – in terms of community – there is a massive delta between those who use it and those who are hobbiests and even more strangely, non-user evalgenlists.

                                                                              Those I have spoken to / worked with who either touch Rust core or ship real-world code have been extremely kind, aware of language pros and cons and more than willing to discuss both.

                                                                              But, as you go outside of the that group you reach a group of people who are – borderline non-users. These people have never shipped Rust code anywhere, open-source or elsewhere. Yet they will promote it as being world-saving or viciously attack those who dare slander it.

                                                                              What makes me suspect Rust will overcome is that delta, as the community of active users grows, hopefully, the voices of those who are more on the fringes will be less noticeable, or in the best case, they will start to emulate those they respect in the community.

                                                                              1. 1

                                                                                That’s interesting, and would explain my experience. I very rarely interact with “fringe” communities, instead primarily interfacing with the community as a question of practice while writing code (e.g. if I find a bug or non-obvious behavior in a library, I go and ask about it). In your assessment I would therefore be interacting only with the “core” of the community, and avoiding the “fringe.” Hopefully this core – which, again, I’ve had nothing but positive experiences with – can overcome whatever horribleness newcomers are encountering at the edges.

                                                                                1. 1

                                                                                  Well – the risks are two-fold. The first is the “fringe” in this case might well be the majority (in raw numbers). The second is the “fringe” is often the first point of contact someone has with the community as they explore the idea of using Rust. Unfortunately, many people first explore a language, not via important projects, but via subreddits and various medium articles about the language.

                                                                                  1. 1

                                                                                    This honestly makes me think that we (e.g. people actually using Rust for things) need to write more articles focused on presenting Rust in a friendly/conceptual way besides just the usual beginner texts. It’s hard, though, because I think there’s a kind of analogue of the “explaining monads” problem: Rust changes the way you think about programming somewhat, but there isn’t a real language of practice around it yet. Developing those metaphors will be a challenge.

                                                                                    1. 2

                                                                                      I think you nailed it. The practice of being a Rust developer is still rather new. Additionally, Rust due to its differences with other languages makes it hard to tell someone just to “dive in and get involved” with a project they like. It can feel absolutely intractable at first. That is a benefit that Go tends to have – you find an interesting project, jumping in is easy and the distance from completely lost to enlightened tends to be a fairly straight line.

                                                                            2. 2

                                                                              I’m not so blind as to confuse the arrogance of Rust users with a flaw in the language itself

                                                                              that’s kinda like a foundational line of thinking in media studies in general; the notion that the specific affordances of a medium affect the users of that medium, and that the affordances of the medium are expressed through the content made in that medium. Hence the saying “the medium is the message”. McLuhan takes it pretty far (much farther and more literally than I would be thrilled to support), but the idea that a specific medium (a programming language, in this case) has a character and has its own message is … a widely studied concept worthy of consideration, and shouldn’t be disposed of so casually. For programming languages, the question then becomes: what is the language’s character and what is expressed by the language itself?

                                                                              1. 1

                                                                                This line of thinking permeates HCI, even back when it was just “human factors” research. But the oldest and perhaps deepest form I know is the venerable and well-worn Sapir-Worf hypothesis. It’s a difficult subject to study rigorously. Experiments are almost impossible to conduct, factors hard to control for… but there is nonetheless a rich body of perhaps-not-entirely-useless scholarship.

                                                                                One need not be a scholar to observe that language and culture are everywhere intertwined. Although the diversity of “natural” human languages has suffered an epoch of mass extinction, we computer people are living in a tiny but ongoing explosion of artificial (and thus perhaps even more human) linguistic diversity, and inevitably dragging in all our predilections for cliques and status games, to enact amidst all the mathematical and mechanical concerns. Perhaps someday there will be a true sociolinguistics of programming languages. As it stands now, we barely have even scraps of historical consciousness… like this joking-not-joking article.

                                                                            3. 6

                                                                              There’s plenty of people … who are “advocating for Rust” in a way that makes Rust advocates seem unhinged

                                                                              that’s increasingly my experience of lobste.rs

                                                                            4. 2

                                                                              In any case, I don’t think the object-level point this essay is making holds. In general, I’m skeptical of arguments saying that “such and such language community is arrogant, therefore Y”.

                                                                              I think the original talk was using the demise of Ruby as a pretense to talk about professionalism in programming rather than earnestly attempting to analyze the demise of a language. Professionalism - Martin’s version of it - is something that he likes to pontificate about.