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

                              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. 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. 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

                                              …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. 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. 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

                                                    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!

                                                    2. 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.

                                                      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.

                                                                        1. 11

                                                                          I can’t reconcile “embedded” with “immutable”. Whatever your definition of “embedded” is, storage space is limited. (Yes, current phones and tablets come with a lot of storage, but users always fill it up with photos or gigantic games.) If your database grows constantly, then it’s only a matter of time before it exhausts free storage. Then what? Your actually-embedded box crashes and can’t be fixed without a factory reset. Or your mobile app frustrates users, who either spam your support channel with complaints that it’s using too much space, or simply delete the app.

                                                                          I’m also feeling cranky because when people bring up client-side databases they never mention Couchbase Lite (of which I’m the architect). We do a thriving enterprise business but seem to be unknown in the OSS world despite being Apache-licensed. Couchbase Lite meets a lot of this guy’s needs, aside from running in a browser. (IMHO in-browser DBs are of limited use because the browser doesn’t provide much persistent storage and likes to nuke it whenever it feels like it.)

                                                                          1. 3

                                                                            I think of immutability in this context as “immutable until compacted and GCed” so tombstones and partial updates get folded periodically into a new snapshot. (Like building a tarball from a git tag.)

                                                                            As for Couch vs. something new: there’s space for many models and engines here. Not everything is JSON-over-HTTP, and that’s okay. (Getting reliable storage in a browser is indeed hard, but compacted snapshots can help with recovering from a storage/cache miss too.)

                                                                            1. 3

                                                                              Well, I took the author at their word: “Being immutable means that only new information is added, no in-place update ever happens, and nothing is ever deleted.”

                                                                              What you’re describing is what I’d call append-only or log-based. That’s how CouchDB’s and Couchbase Server’s databases work. It has the downside of lots of write amplification, since all the live data gets rewritten every time you compact.

                                                                              On devices with limited storage, append-only has the worse problem that you can’t free up any storage unless you have enough free space to copy all the live data first. Which basically means it’s dangerous to fill up more than half of your storage, unless you carefully keep track of how much live data you have. On a device like a phone where you don’t control all the storage, you can find yourself, through no fault if your own, unable to compact because some other apps used up too much space!

                                                                              1. 1

                                                                                In fact, git itself implements this internally with “packfiles”, which is an internal binary format to represent diffs efficiently regarding storage. However every bit of data is still there, the “compaction” is transparent to the user.

                                                                                Having snapshots is an possibility, but this would be better if left to the application to do, if the database could expose the snapshot and build more data on top of it, and let the application delete old data when convenient.

                                                                              2. 3

                                                                                Storage efficiency would be the most challenging place to optimize for, and I agree that storage space is limited.

                                                                                But I also think that this is actually viable. A quick find ~/ -type d -name '.git' | wc -l returns me 260 entries, and all of those are instances where things grow “forever”, and that’s fine. My laptop has more storage than my phone, but only ~8 times more. So a simple translation would mean that I could have ~30 databases and be also fine.

                                                                                Sure, this doesn’t work for all types of applications. That’s what tools like Git Annex and Git LFS are trying to solve, and there are many instances that growing “forever” isn’t a good idea. However I do think that there are many other places that growing “forever” is a good idea, and that’s where I’m focusing at.

                                                                                Sorry about not mentioning Couchbase Lite. I do know it and I have actually used it in the past on a personal project, actually.

                                                                                1. 3

                                                                                  Whatever your definition of “embedded” is, storage space is limited.

                                                                                  That’s interesting, because that’s not what my interpretation of the word “embedded” means in an “embedded database.” My understanding is that an embedded database is one that is tightly coupled with an application, or rather, where the database itself is hidden from the end user. Compare that with something like PostgreSQL for example, where the end user typically has to maintain a running instance of PostgreSQL in order for the application to work. Contrast that with SQLite, and the end user might never know that SQLite is used at all.

                                                                                  It may be common association that an “embedded” database is typically used in environments with constrained storage space, but it is also common to use embedded databases outside said environments. So I don’t think “embedded” in this context actually has anything to do with available storage. (SQLite, for example, just increased its maximum database size to 281 TB because one of its customers was getting close to the previous 140 TB maximum.)

                                                                                  Also, with respect to immutability, I suppose it’s hard to know whether they mean truly immutable in that there is never any kind of garbage collection, or whether they’re using “immutable” in the data structure sense. It’s commonly understood, for example, that an “immutable data structure” will have some kind of garbage collection process that actually allows unused memory to be reused.

                                                                                  1. 1

                                                                                    My understanding is that an embedded database is one that is tightly coupled with an application

                                                                                    Crap, you’re right. And I know this, I’ve used “embedded” to describe the difference between SQLite and MySQL before. My brain just went the wrong direction yesterday … I blame the fact I’ve been trying to get a Seeed microcontroller to talk to MIDI so I’ve got embedded devices on the brain. 😣

                                                                                    1. 1

                                                                                      Haha no worries! I’m writing a kind of database myself and just recently looked up what precisely qualified as an “embedded” database, so it stuck out to me here. :-)

                                                                                  2. 3

                                                                                    I think the reason nobody mentions Couchbase Lite is because they probably assumed (as I did, before Googling) that it’s just a renamed CouchDB. In my experience, many people in OSS companies tried CouchDB at some point in the past and had bad experiences. Thus, anything with “Couch” in the name is going to be limited by those preconceptions from the start.

                                                                                    1. 2

                                                                                      Yeah, we [Couchbase] have been fighting that misconception since 2012. The company started as a merger of two tiny startups, one around memcached and the other around CouchDB (including creator Damien Katz), but found that using CouchDB to persist memcached’s data didn’t work because CouchDB was too slow to keep up. Fixing this involved tearing apart CouchDB and replacing big parts of it, like the b-tree storage engine, with optimized C code, as well as removing functionality like replication. So by the time the first “real” version of Couchbase Server shipped, it was far enough diverged from CouchDB to be a different species entirely. Today we do still have Erlang in the code base but I don’t think any original CouchDB code remains — even query is entirely different, using a SQL-derived query language called N1QL.

                                                                                  1. 24

                                                                                    There’s nothing I hate more than having to break up clean logic and pollute the class/module/whatever namespace by breaking a single function into many functions that are useless on their own, just to please some stupid code complexity / function size metric.

                                                                                    1. 13

                                                                                      It depends on how big the “clean logic” is. I worked on a code base that had a method with a cyclomatic complexity of 712. I wanted to break it up into a few smaller functions when I needed to modify it, but was told not to touch it. We later had a bug in it, so I had to re-read it. I found a suspect area in a 50-line chunk of quantitative logic that I then extracted into its own method and tested exhaustively (e.g. for all reasonable combinations of inputs) and immediately found a hole in the logic.

                                                                                      Now, I’m not saying that it was wrong to initially write the thing in one big procedural blob, but there’s a point at which you should probably think about refactoring.

                                                                                      The issue I have is with rules like “methods should never be more than four lines long,” which cause me to immediately write off anything else the author has to say.

                                                                                      1. 1

                                                                                        Any time you can extract a pure computation which isn’t simple enough to be “obviously correct” (defining “binaryMultiply(a, b int)” is probably a mistake, but “GCD(a, b int) int” probably isn’t) then I think that’s a good thing.

                                                                                        Many functions (and applications for that matter) run along the lines of:

                                                                                        • unpack/read/unmarshall/deserialise data on which to operate
                                                                                        • check constraints, return errors
                                                                                        • operate on data
                                                                                        • pack/write/marshall/serialise data

                                                                                        the “read” and “write” might be database, http request, etc.

                                                                                        In this case, the “operate on data” is a prime candidate for extraction - it should require no external dependencies (those are the things from which you’ll read and write) and can often be expressed as a pure function.

                                                                                      2. 1

                                                                                        If you do this well, you end up with one function that looks like clean pseudocode of the algorithm and a bunch of functions marked always-inline that describe one step of the algorithm and are well named. You can review the pseudocode and the small functions independently: if the small functions don’t do exactly what you’d expect from the name, they’re wrong, if the pseudocode doesn’t describe the algorithm you’d expect, it’s wrong.

                                                                                        You can also do this very badly and just pull everything out into chunks that correspond to sequences of operations but not to logical structure in the algorithm and end up with spaghetti code that’s even harder to review than the original.

                                                                                        1. 1

                                                                                          The problem with metrics isn’t that they are wrong, but that we don’t get buy-in from all team members on them.

                                                                                          Rewriting bad code as worse code to “please the metric” is of course a terrible thing. But the goal of the metric (and what we need to work to get more buy in from teams using metrics on) is to inform you of where your code has gone wrong – to invite you to rethink how it should be. Taking a big procedural blob and breaking it into 6 “step” procedures and a main one that calls them each in order is of course a disaster. But banishing procedures from the codebase will make maintainability nicer in the long run.