1. 37

    I hate to say it, but while the substance of the article is useful, it disproves the title, in my opinion.

    The title says that Nix is close to perfect, and then lays out a lot of shortcomings that take it far away from perfect.

    I personally wish that there was a Nix that was well-documented, not so academic and elitist, and in general, had some empathy for users, especially for new users. In fact, lacking empathy for users alone makes something not close to perfect, in my opinion.

    Also, the soft split that is mentioned makes me nervous. Why such a split? What makes flakes better enough that some people use them, but not better enough that others don’t?

    This all might sound very negative, and if so, I apologize. I want Nix’s ideas to take off, so I actually feel discouraged about the whole thing.

    1. 16

      Unpopular opinion here. The Nix docs are weird, but they are mostly fine. I usually don’t have any issue with them. The thing that usually gets me is the holes in my knowledge about how certain packaging technologies (both distro- and language-level ones) work and taking some of the things other distros do automatically for granted.

      Here’s an example. You are playing in a Ubuntu-based distro, and you are writing some Python. You pip install some-dependency, import it, and everything is easy, right. Well, it felt easy because two months ago you apt install-ed a C dependency you forgot about, and that brought in a shared lib that your Python package uses. Or your pip install fetches a pre-built wheel that “just runs” (only on Ubuntu and few other distros, of course).

      Nix is brutally honest and makes this shit obvious. Unfortunately, dealing with it is hard. [1] Fortunately, once you deal with all that, it tends to stay dealt with and doesn’t randomly break on other people’s computers.

      Learning Nix has helped me learn Linux in ways I never originally suspected. It’s tons of fun (most of the time)!


      [1] The rude awakening that a Python library can require a Fortran compiler is always fun to watch from the side. :)

      1. 10

        The Nix docs are weird because they’re written for the wrong audience: people who want to learn Nix. I don’t care about Nix. Every moment I spend learning about Nix is just an inconvenience. Most Nix users are probably like that too. Users just want a packaging system that works, all of this discussion about Nix fundamentals is anti-documentation, things we need to skip to get to what we want: simple recipes for common tasks.

        But Nix also has at least two fundamental technical issues and one practical issue that exacerbate the doc situation. The practical issue has to do with the name: it’s just a search disaster that Nix is three things (a distro, a language, and a package manager). On to the technical issues.

        1. I can’t explore Nix because of the choice of a lazy language. Forcing values by printing them with builtins.trace is a minefield in Nix. Sometimes printing an object will result in it trying to create thousands of .drv files. Other times you find yourself printing one of the many circular objects that Nix uses.

          In Haskell and C++ I get to look at types to figure out what kind of object I’ve got, in addition to the docs. In Scheme and Python I get to print values to explore any object. In Nix? I can do neither. I don’t get types and I don’t get to print objects at runtime easily. At least you can print .drv files to figure out that say, a package happens to have a lib output, and that’s what you need to depend on instead of the default out output.

        2. There are almost no well-defined APIs within the Nix world.

          Aside from derivations, it’s all ad-hoc. Different parts of the Nix ecosystem work completely differently to accomplish the same goals. So learning how to do something to C packages, doesn’t help you when you’re dealing with Python packages, and doesn’t help you when you’re dealing with Haskell packages (where there are two completely different ecosystems that are very easy for novices to confuse). Flakes add a bit of structure, but they’ve been unstable for 3 years now with no stability on the horizon.

        1. 2

          I agree on both technical issues. Static types and type signatures in Nix would be especially amazing. I spend so much time wondering “what type does this have” when looking at nixpkgs code. :(

          As for the fundamentals and anti-documentation features, I am not so sure. I think Nix is such a fundamentally different way of doing things, that you need to start somewhere. For example, I can’t give users a packaging script sprinkled with content SHA’s without explaining what those are and why we need them in the first place (It’s especially baffling when they sit right next to git commit SHA’s). The Nix pills guide has a good way of introducing the important concepts and maybe it can be shortened, so that people can go through most of the stuff they need in half an hour. I don’t know…

      2. 10

        not so academic and elitist

        For a language that is the bastard child of Bash and ML, I would not consider it “academic”. The ugliness of the language is due in no small part to the affordances for real-world work.

        As far as elitism…well, it’s a hard tool to use. It’s getting easier. It’s strange to me to expect that such powerful magic shouldn’t take some work to learn (if not master).

        1. 19

          For a language that is the bastard child of Bash and ML, I would not consider it “academic”. The ugliness of the language is due in no small part to the affordances for real-world work.

          I never said the language was academic. I don’t think it is. In fact, it’s less that the language is academic and more that the documentation and culture are.

          As far as elitism…well, it’s a hard tool to use. It’s getting easier. It’s strange to me to expect that such powerful magic shouldn’t take some work to learn (if not master).

          Power does not imply something must be hard to learn. That is a common misconception, but it’s not true.

          As an example, consider Python. It’s not that hard to learn, yet it is enormously powerful. Or Ruby.

          In fact, Ruby is a great example because even though it’s powerful, it is mostly approachable because of the care taken in helping it to be approachable, epitomized by _why’s Poignant Guide.

          _why’s efforts worked because he made Ruby approachable with humor and by tying concepts of Ruby to what people already knew, even if he had to carefully lay out subtle differences. Those techniques, applied with care, would work for Nix too.

          So the problem with Nix is that they use the power as an excuse to not put more effort into making it approachable, like _why did for Ruby. This, I think, is a side effect of the culture I mentioned above.

          If someone wrote a Nix equivalent of _why’s Poignant Guide, playing to their own strengths as writers and not just trying to copy _why, I think Nix would have a massive uptake not long after.

          In fact, please do write that guide, if you would like to.

          1. 12

            If I had more spoons I’d definitely do that

        2. 9

          I agree. It is some of the coolest Linux technology that is out there, but it is so hard to use. Both because its poor documentation and because of how different it is. When I used it, it felt like once a week I would try to do something not allowed/possible and then would have to go multiple pages deep on a thread somewhere to find multiple competing tools that claim to solve that problem best. I think I will try Nix the language on the next personal project I make that involves more than one language, but I haven’t had a chance to do that in a while.

          I would love to try NixOS again sometime. Hopefully they will come out with better documentation and/or a “let me cheat just this once so I can continue working” feature.

          Edit: I forgot to say, great article though! I enjoyed your perspective.

          1. 6

            I have found the Guix documentation quite good, and the community very welcoming, for what it’s worth.

            1. 6

              Keep in mind that the more familiar someone is with the subject the more issues they can talk about. I could go on for ages about problems with python, even though it is a perfect language for most of my use cases - It’s not a contradiction.

              The post just concentrated on the negatives rather than positives - and there are some really cool things about nix. Especially if you have use cases where everything else seems to be worse (looking at you chef/puppet/ansible).

              1. 1

                I wouldn’t feel discouraged if I were you. Nix’s community is nothing but growing. Most of these issues are warts, not dealbreakers.

                1. 1

                  makes me miss WORLDofPEACE. Didn’t know them, but they’re a good example of someone that can make anyone feel welcome IMO.

                1. 2

                  Ideas in this space will continue to fail because what users are lacking isn’t programming skills, it’s a mental model of how machines work which you learn by acquiring programming skills. The solutions naive users come up with are a disastrous mess that only get worse with time no matter the tools. And there’s an answer to this that the author dismisses out of hand:

                  Why not just teach everyone to program?

                  I hate this ideology and I always have. Human civilization progresses in part due to specialization, that we as a society don’t have to learn to do everything in order to keep things functional.

                  What’s the point in teaching people to count if we have calculators? Why bother learning anything about biology and your body, your doctor will figure out what’s up anyway?

                  There are some basic prerequisites that you need to have in order to be a productive member of society that can hold down a professional job. Computational thinking is becoming one of those prerequisites, there’s no way around this.

                  1. 3

                    Because learning how to parse the garbage that is a modern websites DOM isn’t computational thinking and it isn’t programming, it’s “sorting through someone else’s garbage”.

                    1. 1

                      What’s the point in teaching people to count if we have calculators? Why bother learning anything about biology and your body, your doctor will figure out what’s up anyway?

                      I never bothered to learn how to do surgery and am still a productive member of society.

                      1. 2

                        If your job involved doing something with surgical tools and you had no idea about how they’re used, that would be pretty terrifying!

                        Most professional jobs involve dealing with computers at many levels. There’s no excuse for not teaching computer literacy skills.

                        1. 4

                          Computer literacy does not necessarily mean programming in the same way learning to drive doesn’t mean being able to change an engine.

                          1. 2

                            But what what does it mean to be “computer literate?”

                            1. 2

                              I would say it’s having the “mental model of how machines work” that OP described, and therefore being able to navigate your way around the system. I also agree that programming is probably the best way to acquire this mental model.

                              That being said, there’s a huge difference between having some exposure to programming and having abilities that we at Lobsters would consider “competent programming”. Say every high school includes one required programming course: I would argue that this will not teach users enough programming to be able to automate things in today’s environment, but is still sufficient to give people this mental model. A lot of the reason for this difference is because, due to the lack of platform APIs like e.g. HyperCard or Automator/AppleScript to organize things around, today automation is heavily dependant not just on your fundamental ability to program but the depth of your understanding of the specific system you’re trying to automate. E.g. say you learn Python and have a good mental model for how things like control flow work. This will not be sufficient for automating the web because you don’t know the specifics of how CSS and HTML work. There isn’t a level of abstraction to help you out.

                              tl;dr while I totally agree with OP about the need to have a basic mental model for how the machine works - just like everyone should know e.g. a little bit about math, or science, or whatever, even if that’s not your specialty - and that you probably need to do some programming to get it, I don’t think it follows that this is a sufficient answer for the problem raised in the submission. And it shouldn’t be, because users’ time is valuable, they usually don’t have time to get past that basic model, and we should be doing better for them.

                          2. 2

                            You presumably use electricity at work; do you need to be familiar with generation and wiring standards?

                      1. 8

                        Missing: Data flow languages represented by Labview, Lusture etc.

                        1. 1

                          Interesting suggestion. This may just be a gap in my background. What would you say the key mental structures you get from them are?

                          1. 3

                            Dataflow programming is about modelling continuous systems. The focus is on how the data flows rather than the control flow in other languages. This answer explains it very well.

                            1. 1

                              Is there something there that isn’t already present in, say, generators in Python or laziness and composition of functions in Haskell?

                              1. 2

                                The entire concept is orthogonal to them, despite the way everything coalesces in the metal. Dataflow programming is much closer to excel than anything else in this list.

                                1. 1

                                  Thank you. I’ll do some more studying and consider how to update the list.

                            2. 2

                              LabVIEW is the predecessor of Unreal’s Blueprints if you want to try these ideas out in a modern setting. It’s also the origins of reactive programming.

                          1. 14

                            For a related but slightly different perspective on PL history, see also @hwayne’s 10 Most(ly dead) Influential Programming Languages.

                            1. 5

                              I have no idea why COBOL is listed as mostly dead. There are way more COBOL jobs than Elm or OCaml and as many COBOL jobs as there are Clojure ones. COBOL is dead on Github, but it’s very much alive in the real world.

                              1. 7

                                The entire thing was a spite-inspired by the original article leaving off Pascal because it was “mostly dead”, so I tried to fit everything into the “mostly dead” gimmick.

                                1. 1

                                  Of the four mother languages, ALGOL is the most “dead”; Everybody still knows about LISP, COBOL still powers tons of legacy systems, and most scientific packages still have some FORTRAN. But I’ve met plenty of programmers who haven’t even heard of ALGOL. You’d think it’d be the least important of the mother languages, but it’s the opposite. Of the four, only LISP comes anywhere close to the pervasive importance of ALGOL.

                              1. 5

                                Few people are excited about both monads and macros; only one person that I know comes to mind.

                                Plenty of Haskell projects use both Template Haskell (macros) and monads; probably every single large-scale Haskell program includes both. Not only is there nothing wrong with mixing the two, amusingly enough Template Haskell runs in a monad! So.. not only are both useful at the same time in Haskell, you don’t get macros without monads. At the same time some of the most popular Haskell libraries use macros like lens (Control.Lens.TH) and aeson (Data.Aeson.TH). I end up using these in every Haskell program I ever write.

                                Aside from that, the two concepts aren’t related at all in any way mathematically. They definitely aren’t both about information hiding.

                                The author sadly gets both monads and macros totally wrong.

                                Monads let you concentrate on functions by providing a sort of side channel for information associated with those functions

                                Maybe is a monad. It sequences computations that can fail. There is no side channel of information at all there; a computation either fails or doesn’t. Not to mention the Sum and functions (->) which are also monads and can’t be thought of as having any side channel – they compose actions. Or Product which combines functors. This is not a good mental model for monads.

                                Macros let you hide the fact that your programming language doesn’t have features that you would like

                                This is at best the C view of macros “Hack stuff together because C sucks”. It’s not the view of macros that you have any language that has a proper macro system (lisp, scheme, haskell, etc.). Macros let you treat code as data, so you can do things like perform static analysis on the code, have code that generates programs, etc.

                                Macros and monads are totally unrelated ideas. Macros let you modify code as if it was data. Monads sequence actions in interesting ways

                                1. 3

                                  Monads let you concentrate on functions by providing a sort of side channel for information associated with those functions

                                  This is not a good mental model for monads.

                                  It resembles my own mental model. Monads sweep repetitive logic under the rug and let you focus on a chain of computations. Methods from particular monads—not part of the Monad interface itself—let you access or interact with that submerged logic.

                                  My other mental model is “statements, but made out of expressions”

                                  1. 1

                                    Beware your mental models—they may be incorrect. My own mental model for monads, that they are new types that have no constants (so they disallow optimizations like constant propagation, or that values aren’t volatile), does explain the IO, random, and sequential sequencing monads, but that’s not how they actually work (it’s an incorrect mental model).

                                1. 11

                                  What’s different about computer science, at least for me, is that it’s accessible. One of the most complicated topics in computer science is operating system design…but I can sit at a computer and just piddle around and get an intuitive idea of “process” and “file” and what-have-you. I can do this with no prior foreknowledge beyond how to type and read and basic “computer literacy” skills.

                                  Pick a similarly complicated topic in mathematics, say, topology. I can’t sit down with basic “math literacy” and just piddle around and get an intuitive feeling for topology. Maybe there’s a way to do that, but I don’t know how.

                                  1. 15

                                    I used to feel this way, until very recently. What changed for me was that I realized I should be reading a math book with a notebook next to me. I know this sounds stupid or obvious, but it wasn’t to me. So when I read a definition, I rewrite it in the notebook and I try to really understand it. The very next thing is usually a very simple proof using that definition. I read the statement of the proof, and then I try to write the proof without looking at what’s in the book. Reading proofs is still a new skill for me, so they’re fairly opaque looking anyway, and it’s not hard for me to ignore it while I make my attempt. After five or ten minutes of struggling, I’ll read the proof in the book and by then, it’s like the struggling has made me really think about what’s going on, and I usually am in the right frame of mind to understand it. This also takes some time. I’ll wind up copying the proof from the book into my notebook, but in my own words or (occasionally) other notation.

                                    This isn’t that different from what you do with computer science by reading with a computer nearby. In both cases, you don’t really expect to understand what you’re reading on your own, without doing some experimentation.

                                    I have a Dover book on topology, Mendelsohn’s Introduction to Topology, and I have been trying to work through it for a long time. I’m in a class on abstract math now, and I’m hoping that I’ll make more progress in the topology book after I get through the class. But I was actually starting to get somewhere with it following this approach.

                                    1. 1

                                      I would very much appreciate some book recommendations if you’ve got the time.

                                      1. 6

                                        Introduction to Graph Theory notoriously espouses the ideas outlined here: https://www.goodreads.com/book/show/388049.Introduction_to_Graph_Theory

                                        1. 1

                                          Thank you, added to the list.

                                        2. 3

                                          Sure! On what? The text for my class is Introduction to Abstract Mathematics but the other book I mentioned is Introduction to Topology.

                                          1. 1

                                            Thank you!

                                          2. 2

                                            Pinter, “A Book of Abstract Algebra” is great for self-study. Each chapter is a short presentation of some basic definitions, followed by a series of exercises designed to guide you through discovering important facts for yourself. I highly recommend it!

                                            1. 1

                                              And it’s on the list too, thank you.

                                        3. 10

                                          I can’t sit down with basic “math literacy” and just piddle around and get an intuitive feeling for topology. Maybe there’s a way to do that, but I don’t know how.

                                          You can. It’s not called “math literacy”, it’s called mathematical maturity. It takes a lot of practice – the equivalent of a good chunk of an undergrad degree to develop it. It’s a fuzzy concept (literacy is more binary), but it’s when you become more self-sufficient. You come up with your own examples to probe different concepts, you don’t need someone to tell you if a proof or line of thinking is correct, you start to see the broader consequences of why a result is true and what it means outside of how it was defined, you start to see how different results are connected and how while a book or a paper took one path to a result there are many paths that could have been followed, etc.

                                          operating system design…but I can sit at a computer and just piddle around and get an intuitive idea of “process” and “file” and what-have-you. I can do this with no prior foreknowledge beyond how to type and read and basic “computer literacy” skills.

                                          This is because a lot of problems in computer science and still pre-theoretical. We muddle our way through what a good operating system should look like because we don’t have a theory that lets us formally define what “good” is and then reason about “goodness”. It’s the same in machine learning. We have theory to talk about how to optimize a function, but we don’t have theory to talk about what object detection really is as a problem besides “match the labels people give to objects”.

                                          Eventually, this will change. Theory in physics took a long time to mature. The ancients could ask questions about atoms, gravity, magnetism etc. just fine. And they came up with plenty of reasonable hypotheses, some of which they even tested. That’s where we are in computer science today. Fixing the situation and finding theory where these big questions can be asked precisely and where they can be given answers took 1000+ years. Hopefully computer science will move much faster.

                                          1. 9

                                            As a software engineer, I agree that software feels more accessible. But most us of were never taught mathematics in school. And by most I am suggesting a very significant majority. It would be terribly difficult for math to feel accessible if that’s true. In Paul Lockhart’s referenced diatribe (https://www.maa.org/external_archive/devlin/LockhartsLament.pdf) against the way math is taught, he makes a very strong case for this.

                                            1. 3

                                              In my first year of CS, I wrote some code that took a lot of samples from a uniform random distribution, bucketed them, and made a bar-plot of them (effectively plotting something like the probability distribution function – although I didn’t know this concept at the time). The result was as expected.

                                              Then, I replaced the random sample by the sum of two random samples. Suddenly the box-plot started looking more like a tent function. I didn’t understand why, but this seemed interesting! I tried the product of two random samples as well, which gave a similar interesting result.

                                              I was a little bit annoyed that I didn’t immediately understand something so simple. I understood how random numbers work, and how sums work, so certainly I should be able to deduce how the sum of two random variables behaves?

                                              I then sat at my desk for a long time and, by trying to understand the various graphs my code produced, gained a good intuition for pdfs, cdfs, and the concept of convolution. I just loved being able to have a problem, and just solve it by virtue of thinking hard enough about it.

                                              I started a maths degree after that year.

                                              Edit: On the other hand, I feel like in computer science it is much more common that you just have to know how certain things work under the hood, while there is zero indication of how you possibly can find out. I’ve had this experience when I used Arch Linux and NixOS a lot. It’s also common in C++. If you take a pointer to an element in a vector, it’s fine. If you do it but then add an element to the vector, your pointer might or might not point to accessible memory.

                                            1. 32

                                              Eh. This focuses on the distinction between Linux and Unix, and argues that Linux winning doesn’t mean that Unix wins. But honestly, I’d think the bigger issue is that a majority of Linux systems no longer have a Unix-like userland (because they are running Android or an embedded environment). IMO, that difference vastly eclipses even the difference between BSD init and systemd.

                                              (I used HP/UX, SunOS, Solaris, A/UX, and 386BSD before Linux existed, and I worked as a Linux sysadmin in the pre-systemd era. Systemd is good, actually. It solves problems that need solved, and would otherwise be solved in crufty and inconsistent ways. Systemd being good doesn’t mean something better won’t come along, either.)

                                              1. 29

                                                It’s also ahistorical, comparing Linux which has seen decades of development against a static target like POSIX.

                                                The reality is that POSIX is 33 years old and has been virtually unchanged for almost 20 years now. Of course Linux looks like it’s shrugging off POSIX. That’s just a consequence of the fact that we’ve learned a lot more about computing in 33 years and computing itself has also radically changed.

                                                Much of what Linux is doing is fixing serious shortcomings in POSIX. The async IO interface in POSIX isn’t useful. They never bothered with anything graphics-related. It’s clear that some system-wide messaging capability or a more flexible IPC method is needed, but that doesn’t exist in POSIX (every modern OS has adopted some solution to this like dbus). POSIX is woefully out of date when it comes with dealing with non-English speakers. Pretty much 100% of people that work on filesystems complain about the semantics of fsync. The “everything is a file” concept turned out to not be a great abstraction after all for many tasks. The POSIX IO consistency model is too strong, we’re hitting the limits of what is possible with it.

                                                We could go on and on. The two will continue to diverge and that’s not at all surprising. Eventually they will diverge so far that POSIX will need an update that surveys the common components between *nix like systems again.

                                              1. 34

                                                The idea of moving away from CSV and JSON to file formats like Avro, Parquet, or Arrow gives me nightmares. They all dispense with the most important aspect of CSV files that the author dismisses as something negative:

                                                trade human readability and writability for precision

                                                Hard pass.

                                                In science we need to keep stuff around for a long long time. I have data from 10 years ago that I can read just fine with my eyeball and in any programming language that I want. I can trivially verify that the data is correctly encoded with any text editor. I can sleep well at night that if someone asks for data from a paper I can give it to them and they can read it.

                                                Just look at the changelogs for any of these systems https://github.com/apache/parquet-format/blob/master/CHANGES.md or https://github.com/apache/avro/releases

                                                Even across just 6 languages there are Avro files that can’t be read by some of the implementations. And “Add BYTE_STREAM_SPLIT encoding” is crazy, now we have files that can’t be read by previous versions of the library.

                                                I want 10-50 year old code to read 10-50 year old files in languages that will be invented 10-50 years from now with zero support from any developers who may be long dead and docs that may be long gone.

                                                The kind of thinking that the article lays out is very shortsighted. Any file format that isn’t human readable will eventually be deprecated and unsupported and won’t be readable by machines either. Systems last far longer than anyone expects them to, we have to plan for that not just for our own short-term convenience.

                                                1. 12

                                                  This doesn’t even scratch the surface of Haskell comprehensions. They’re a full SQL-like sublanguage and they can operate over non-list Monads.

                                                  Some of their SQL-like abilities https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/generalised_list_comprehensions.html#generalised-list-comprehensions

                                                  output = [ (the dept, sum salary)
                                                           | (name, dept, salary) <- employees
                                                           , then group by dept using groupWith
                                                           , then sortWith by (sum salary)
                                                           , then take 5 ]
                                                  

                                                  All of the examples above are filters & maps, but with parallel comprehensions they can behave like zips: [ (x+y) | x <- [1..10] | y <- [11..20] ]

                                                  Monad comprehensions are even more powerful. This syntax works for anything, not just a list. It works for optional values, non-deterministic code, stateful code, generating actual database queries, etc.

                                                  1. 4

                                                    See also Wadler 1990, “Comprehending Monads”. I read this when I was first trying to grok monads, and it clarified a lot of things for me. After using Python, seeing that monads are “just” list comprehensions really helped!

                                                    1. 2

                                                      Hah. Yes, the list of things that monads “just” are is endless from “just list comprehensions” to “just burritos”. It’s better to focus on specific monads that are interesting and get a feel for them rather than looking to analogies. No one analogy is really enough. For example, if you think of them as list comprehensions it’s harder to see what transformers or comonads would be about.

                                                    2. 1

                                                      I mean, if you turn on more extensions they get more features, but naked Haskell they don’t do quite so many things :)

                                                      Conversely, in naked Haskell you have do which works for any Monad, including list, and has almost-identical syntax to the comprehensions

                                                      1. 4

                                                        Just because your compiler might, without any flags, default to “naked C++” meaning C++98 doesn’t mean that this is what C++ is today :)

                                                        Extensions are how Haskell evolves and they represent the language as it is today. This is like writing an article comparing C++ to Java but silently using C++98 (pretty much exactly because “naked Haskell” is Haskell 98). Missing out on 20 years of development will make anything seem less interesting.

                                                        It’s really unfortunate that we call them extensions. Maybe language feature flags or something would have been better.

                                                        Actually, you’re more right than you think. Even more modern comprehensions are simple to convert to do notation.

                                                        1. 1

                                                          Naked Haskell is at least Haskell2010, not 98! The fair comparison for new C++ versions is new Haskell versions. The fair comparison for Haskell extensions in C++ land would be things like GNU C++. Haskell does a much better job of course by naming all extensions and making them source-level opt-in.

                                                          And yes, that comprehensions can be written with do was my whole point :)

                                                          1. 3

                                                            Haskell2010 is not an actual language standard. It continues the terrible messaging of the community. Haskell98 describes the language in 1998, it’s a language standard. The community tried to write a new language standard, to describe new Haskell (Haskell Prime). And it was a disaster (repeatedly). Haskell 2010 is a minor update to 98 that doesn’t even describe the language as it was in 2000 never mind 2010. This is all described and explained in the report.

                                                            Even if there is an updated language spec one day, and there may never be, it would not change the situation with extensions. The language will always work by having a ~98 core and then having you enable extensions on top of it. All because this has been such an incredibly successful way of evolving the language.

                                                            Extensions aren’t 2nd tier in any way. Haskell in 2021 is GHC’s implementation plus a bunch of extensions enabled.

                                                      2. 1

                                                        Most of the time I use list comprehensions as a replacement for loops. I was not aware that Haskell has these capabilities. I try to use the subset that works in Python, Erlang and other languages.

                                                      1. 1

                                                        This is a good article, but the only reason branch prediction and caching are so important is that latency to main memory is not keeping up with increases in CPU speed. You can see graphs of this in the post in https://lobste.rs/s/qwx517/compiler_will_optimize_away

                                                        Corrected in reply :-)

                                                        1. 13

                                                          Branch prediction doesn’t exist because of the latency to RAM. It exists because of pipelined processors. Pipelined processors want to share and overlap a lot of resources between operations, like instruction decoding, register renaming, multiple ALUs with varying capabilities, and yeah, load/store units as well. This is what a modern core looks like https://en.wikichip.org/w/images/7/7e/skylake_block_diagram.svg You can’t share those execution units effectively if you’re going to stall at every branch because you don’t have a branch predictor.

                                                          1. 2

                                                            Stalling is one option; using a branch delay slot is another. Adding more branch delay slots would require recompiling your code, which is one reason they are not used as much any more.

                                                            1. 2

                                                              And of course you can’t come along later and make Processor 2 with more/less delay slots.

                                                        1. 9

                                                          This is all sorts of wrong and walks into a common and terrible way to think about AI: “AI needs to directly solve the problem I want it to solve in a way that I recognize”.

                                                          AI has been a remarkably successful field because it throws this idea out. The field of AI is all about discovering what problem we really want to solve and then solving that new problem in a way that has nothing to do with our original intuitions.

                                                          You want accurate web search, maybe people are more likely to point to good results, that really means looking at connectivity, and here’s a cool algorithm to do it. You want good models of human language, maybe words that occur in similar contexts are similar (the distributional hypothesis), that really means learning to represent the co-occurrence structure in some way as an object (this is how all modern natural language processing works). This is AI. We don’t solve the original problem. We figure out what the original problem was from a different perspective which unlocks a new set of algorithms, and of course, a new kind of data that would be helpful for solving the problem.

                                                          I’m sure there’s someone out there working tirelessly to perfect all the disparate technologies - computer vision, control systems, depth perception, etc - required in order for a Tesla to successfully navigate a McDonald’s drive through. Just as they get it sorted and demonstrate its utility, McDonalds will probably just calculate and provide those routes as public information. After all, why bother with the maths and machine vision when you can just write it down in an XML file?

                                                          This is how you go down the rabbit hole of absurdity. Why don’t people do that right now? There is so much value to this. Trillions of dollars of value in automated cars. Any amount of data effort is cheap by comparison. You could literally have tens of millions of people working for years on data entry and it would be a minor rounding error. Seriously, why don’t we do this?

                                                          Because we have no idea what should be in those XML files. Once we develop the right perspective and we make the right algorithms, we will reduce this problem to something that we can state nicely, and we will know what will go into those files. And yes, in retrospect it will look like “This AI stuff is worthless, look all I had to do is run this ‘metadata’ algorithm and give it some annotations, we didn’t we do that before?”

                                                          Or another way to put it. When you don’t know how to do it and you see the results it’s amazing AI. In retrospect, it’s just a bunch of clever ways to get around what you feel might be the real problem (which is pretheoretic, you can’t state mathematically) in order to get cool results.

                                                          1. 4

                                                            Haskell is awesome in all senses of the word. While all types of applications can be written in Haskell, there are some areas where it’s better suited. It’s amazing for applications that take in data in one end and spits out data in the other end. This mirrors the behavior of pure functions.

                                                            But viewing time and user input as what goes in in one end and pixels going out in the other end is stretching what Haskell is suitable for. Like for 3D FPS games. It’s doable, but to me, it’s a very unintuitive way to deal with both users and pixels, compared to a language that is centered around objects and state.

                                                            Include the idea that the real world is dirty, users are dirty, output is dirty and the uninutitiveness doubles.

                                                            I still think Haskell is awesome though (and have used it in production).

                                                            1. 8

                                                              You may be surprised by how nice it can work for building UIs, especially with a declarative library. I’m thinking of Brick for terminal UIs, which I’ve used a couple times. Each time it ended up looking a lot like react+redux, with a fn that takes state + action, state changes, and the UI is updated off the state.

                                                              Concur-replica looks interesting for web UIs, being a phoenix-liveview but for haskell. I think we’ll see many more of these, since updating via html over a websocket seems to be a little hot right now.

                                                              In a way they’re both taking the UI problem and reframing it as a data in, data out problem, hiding all the dirty stuff like diffing, updating, and user input.

                                                              1. 6

                                                                But viewing time and user input as what goes in in one end and pixels going out in the other end is stretching what Haskell is suitable for. Like for 3D FPS games. It’s doable, but to me, it’s a very unintuitive way to deal with both users and pixels, compared to a language that is centered around objects and state.

                                                                Check out godot-haskell. Works beautifully and is very performant. There’s nothing wrong with writing Haskell code on top of a 3D engine that is very imperative and loves objects. You get a lot of cool type safety that you don’t get anywhere else.

                                                                1. 1

                                                                  godot-haskell sounds like the best of both worlds. I’ll check it out, thanks.

                                                                2. 3

                                                                  But viewing time and user input as what goes in in one end and pixels going out in the other end is stretching what Haskell is suitable for.

                                                                  Have you considered FRP (functional reactive programming)? It models these UI cases well in Haskell; Reflex being a well-known library for it. I’ve written web apps and desktop apps using FRP in Haskell.

                                                                1. 10

                                                                  It’s amazing to me that AMD and Intel have managed to fall so incredibly behind. There’s literally no redeeming quality to AMD and Intel CPUs: they’re slower, they consume way more power, they run far hotter, even the price isn’t all that different.

                                                                  AMD and Intel have over half a century of experience building CPUs each. I can imagine that an incredibly inefficient market dominated by a single player would result in subpar CPUs, but we nominally have two big companies that compete with one another. How could they both fail so completely?

                                                                  1. 18

                                                                    Apple bought all the TSMC 5nm there was to be had to roll out the M1. Looking at the Zen3 performance, it seems a 5nm Zen3(4?) would be competitive with the M1. The new AMD laptop chips they announced in Jan are very close to M1 level power/performance already if I read the benchmarks correctly. So AMD are not so far behind - Apple has a small process lead by the looks of things.

                                                                    Of course, the end user (perfectly reasonably) doesn’t care about this - the only thing that matters to them is the performance of the box in front of them. Right now that crown very clearly goes to Apple.

                                                                    1. 4

                                                                      Do you really think it’s mostly just a process thing? That TSMC 5NM can do with ~30W (probably way less considering the MacBook Air’s cooling solution) what TSMC 7NM needs 65W+ to do?

                                                                      That seems unlikely to me. For such a gigantic difference in performance per watt with just a 1 node advantage, there has to be some major CPU architecture and design differences. My numbers are super conservative as well; the fanless MacBook Air isn’t going to run the CPU at 30W for minutes, it’s probably going to do most of the compilation at a much lower power draw. The 3700x in the desktop isn’t going to constrain itself to 65W if the desktop is at all remotely reasonably cooled, it’s probably going to do most of the compilation at a much higher power draw.

                                                                      1. 13

                                                                        Why are you comparing the M1 to a desktop CPU from 2019? AMD Cezanne APUs are competitive to the M1 despite being 7nm. In fact, some Cezanne APUs beat the M1 on multicore benchmarks when limited to 15W:

                                                                        https://www.anandtech.com/print/16446/amd-ryzen-9-5980hs-cezanne-review-ryzen-5000-mobile-tested

                                                                        Yes, Apple delivered a great competitive core. But can we stop with the superlatives on how they are generations ahead and how AMD is behind. Ryzen APUs and the M1 deliver about the same performance with comparable wattage. The only company that doesn’t have a good story is Intel.

                                                                        1. 4

                                                                          I’m discussing the article, yes, which compares the M1 to the 3700x.

                                                                          It would be interesting to see how the ryzen 5000 series holds up when put in a thin chassis with no fans under sustained multi-core load. Just limiting it to 15 watts seems like a bad way to simulate its performance under those conditions. I somehow doubt that it would match a 3700x, but maybe I’m wrong. I’m also open to the possibility that actually, the 3700x is way faster than the M1, but that GCC is way slower than (Apple’s build of) Clang.

                                                                        2. 8

                                                                          Yes. The M1 is designed around a specific power budget & everything is cut down to fit inside that target. AMD’s desktop chips have no such limits & therefore don’t bother optimising every last W out of the design. You can’t make direct comparisons between the two. (Also, AMD’s power draw quotes are much closer to peak power draw, whilst The M1’s 10W is more like Intel’s “normal power draw”. i.e. it’s a made up benchmarking number. You can’t directly compare those either. See https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested/8 for the difference.)

                                                                          It is more reasonable to compare AMD’s laptop SOCs with the M1 & there the latest AMD design appears to be about 90% of the M1 performance within a similar power budget, whilst running much slower memory. Give AMD’s chip designers free access to TSMC’s 5nm process & put the memory on the same substrate as the CPU & it seems likely they’ll match or exceed the M1.

                                                                          The M1 is a /great/ CPU, but it’s not the great breakthrough that everyone seems to think it is. It’s only because we’ve been forced to use expensive, sub-par Intel chips for years because Intel had a lock on the laptop market whilst they flailed around trying to get their two last fab generations to work properly that it looks like such a huge step forwards for the end user.

                                                                          1. 3

                                                                            Let’s keep in mind, too, that this is Apple’s first desktop CPU. I imagine that they will remain competitive even as their power budget expands, because the demands on a phone CPU and a laptop/desktop one are different.

                                                                            1. 2

                                                                              Isn’t it actually a Laptop CPU? I thought the “real” desktop ones are yet to come.

                                                                              1. 1

                                                                                You’re right – the distinction I was trying to make was that it’s basically still an iPad CPU.

                                                                          2. 3

                                                                            My understanding of other benchmarks is that the M1 Air can run at full cpu capacity for about ten minutes before throttling down, so these emacs builds were probably running at full power. However, full power for the Air is still only 10 watts, which is how they get away with not having a fan. It’s just a (normally fanless) phone chip scaled up to laptop standards, something people have been waiting for ever since the original iPad Pro out benchmarked many flagship laptops.

                                                                            1. 5

                                                                              According to Anandtech at full throttle the M1 draws about 27W. Not for very long in an Air though :)

                                                                        3. 5

                                                                          I think we’ll need to wait a few more years to know if they’ve really failed so completely.

                                                                          1. 4

                                                                            I think that’s already pretty amazing. Until a few months ago for decades we could always count on having the best hardware in the Intel / AMD world. For the first time in like 30 years Intel and AMD hardware is significantly inferior. Maybe they’ll catch up quickly, but this is a radically different state of affairs.

                                                                          2. 3

                                                                            Didn’t apple buy a year or so of exclusive use of the newest process at TMSC? How much of the performance gap is a willingness to spend a whole lot of money there?

                                                                            1. 2

                                                                              Have they really fallen behind? Is there any other non-apple CPU that I can buy at a similar price and use in a desktop with comparable performance? Power has good performance, but it still doesn’t surpass intel/amd; and it certainly doesn’t beat them at pricing. (It probably has better power consumption, granted.)

                                                                              1. 1

                                                                                See the “innovators dilemma” section of this post: https://apenwarr.ca/log/20201227. I don’t have domain knowledge to judge this is a right explanation, but it sounds convincing.

                                                                              1. 18

                                                                                What this rant does not focus on: It’s a good thing that these usecases are broken. Wayland prohibits your desktop applications from capturing keystrokes or recording other apps’ screens by default. X’s security model (and low level graphics APIs) is/are severely outdated, and Wayland promises not only to be more secure, but also expose cleaner APIs at the lower level (rendering, etc.)

                                                                                These usecases are/will still be supported though, but this time via standardized interfaces, many of which already exist and are implemented in today’s clients.

                                                                                X is based on a 30 year old code base and an outdated model (who runs server-side display servers these days?). Of course, switching from X to Wayland will break applications, and until they are rewritten with proper Wayland support they will stay that way. For most X11 apps there even is Xwayland, which allows you to run X11 apps in Wayland if you must.

                                                                                1. 27

                                                                                  What this rant does not focus on: It’s a good thing that these usecases are broken

                                                                                  You should have more compassion for users and developers who have applications that have worked for decades, are fully featured, and are being asked to throw all of that away. For replacements that are generally very subpar. With no roadmap when party will be reached. For a system that does not offer any improvements they care about (you may care about this form of security, not everyone does).

                                                                                  I could care less about whether when I run ps I see Xorg or wayland. And I doubt that most of the people who are complaining really care about x vs wayland. They just don’t want their entire world broken for what looks to them like no reason at all.

                                                                                  1. 5

                                                                                    I’m not saying that those apps should be thrown away immediately. Some of these work under XWayland (I sometimes stream using OBS and it records games just fine).

                                                                                    If your application really does not run under XWayland, then run an X server! X is not going to go away tomorrow, rather it is being gradually replaced.

                                                                                    I’m simply explaining that there are good reasons some applications don’t work on Wayland. I’m a bit sore of hearing “I switched to Wayland and everything broke” posts: Look behind the curtain and understand why they broke.

                                                                                  2. 17

                                                                                    I’m kind of torn on the issue.

                                                                                    On the one hand, the X security model is clearly broken. Like the UNIX security model, it assumes that every single application the user wants to run is 100% trusted. It’s good that Wayland allows for sandboxing, and “supporting the use cases, but this time via standardized interfaces” which allow for a permission system sounds good.

                                                                                    On the other hand, there’s clearly no fucking collaboration between GNOME and the rest of the Wayland ecosystem. There’s a very clear rift between the GNOME approach which uses dbus for everything and the everything-else approach which builds wayland protocol extensions for everything. There doesn’t seem to be any collaboration, and as a result, application authors have to choose between supporting only GNOME, supporting everything other than GNOME, or doing twice the work.

                                                                                    GNOME also has no intention of ever supporting applications which can’t draw their own decorations. I’m not opposed to the idea of client-side decorations, they’re nice enough in GTK applications, but it’s ridiculous to force all the smaller graphics libraries which just exist to get a window on the screen with a GL context - like SDL, GLFW, GLUT, Allegro, SFML, etc - to basically reimplement GTK just to show decorations on GNOME on Wayland. The proposed solution is libdecorations, but that seems to be at least a decade away from providing a good, native-feeling experience.

                                                                                    This isn’t a hate post. I like Wayland and use Sway every day on my laptop. I like GNOME and use it every day on my desktop (though with X because nvidia). I have written a lot of wayland-specific software for wlroots-based compositors. But there’s a very clear rift in the wayland ecosystem which I’m not sure if we’ll ever solve. Just in my own projects, I use the layer-shell protocol, which is a use-case GNOME probably won’t ever support, and the screencopy protocol, which GNOME doesn’t support but provides an incompatible dbus-based alternative to. I’m also working on a game which uses SDL, which won’t properly support GNOME on Wayland due to the decorations situation.

                                                                                    1. 13

                                                                                      the X security model is clearly broken

                                                                                      To be honest I feel the “brokenness” of the security model is vastly overstated. How many actual exploits have been found with this?

                                                                                      Keyloggers are a thing, but it’s not like Wayland really prevents that. If I have a malicious application then I can probably override firefox to launch something that you didn’t intend (via shell alias, desktop files) or use some other side-channel like installing an extension in ~/.mozilla/firefox, malicious code in ~/.bashrc to capture ssh passwords, etc. Only if you sandbox the entire application is it useful, and almost no one does that.

                                                                                      1. 10

                                                                                        This isn’t a security vulnerability which can be “exploited”, it’s just a weird threat model. Every single time a user runs a program and it does something to their system which they didn’t want, that’s the security model being “exploited”.

                                                                                        You might argue that users should never run untrusted programs, but I think that’s unfair. I run untrusted programs; I play games, those games exist in the shape of closed-source programs from corporations I have no reason to trust. Ideally, I should be able to know that due to the technical design of the system, those closed source programs can’t listen to me through my microphone, can’t see me through my webcam, can’t read my keyboard inputs to other windows, and can’t see the content in other windows, and can’t rummage through my filesystem, without my expressed permission. That simply requires a different security model than what X and the traditional UNIX model does.

                                                                                        Obviously Wayland isn’t enough on its own, for the reasons you cite. A complete solution does require sandboxing the entire application, including limiting what parts of the filesystem it can access, which daemons it can talk to, and what hardware it can access. But that’s exactly what Flatpak and Snaps attempts to do, and we can imagine sandboxing programs like Steam as well to sandbox all the closed source games. However, all those efforts are impossible as long as we stick with X11.

                                                                                        1. 3

                                                                                          Every single time a user runs a program and it does something to their system which they didn’t want, that’s the security model being “exploited”.

                                                                                          If you think a permission system is going to solve that, I going to wish you good luck with that.

                                                                                          Ideally, I should be able to know that due to the technical design of the system, those closed source programs can’t listen to me through my microphone, can’t see me through my webcam, can’t read my keyboard inputs to other windows, and can’t see the content in other windows, and can’t rummage through my filesystem, without my expressed permission.

                                                                                          Ah yes, and those closed-source companies will care about this … why exactly?

                                                                                          They will just ask for every permission and won’t run otherwise, leaving you just as insecure as before.

                                                                                          But hey, at least you made the life of “trustworthy” applications worse. Good job!

                                                                                          But that’s exactly what Flatpak and Snaps attempts to do […]

                                                                                          Yes, letting software vendors circumvent whatever little amount of scrutiny software packagers add, that will surely improve security!

                                                                                          1. 7

                                                                                            If you think a permission system is going to solve that, I going to wish you good luck with that.

                                                                                            It… will though. It’s not perfect, but it will prevent software from doing things without the consent of the user. That’s the goal, right?

                                                                                            You may be right that some proprietary software vendors will just ask for every permission and refuse to launch unless given those permissions. Good. That lets me decide between using a piece of software with the knowledge that it’ll basically be malware, or not using that piece of software.

                                                                                            In reality though, we don’t see a lot of software which takes this route from other platforms which already have permission systems. I’m not sure I have ever encountered a website, Android app or iOS app which A) asked for permissions to do stuff it obviously didn’t need, B) refused to run unless given those permissions, and C) wasn’t obviously garbage.

                                                                                            What we do see though is that most apps on the iOS App Store and websites on the web, include analytics packages which will gather as much info on you as possible and send it back home as telemetry data. When Apple, for example, put the contacts database behind a permission wall, the effect wasn’t that every app suddenly started asking to see your contacts. The effect was that apps stopped snooping on users’ contacts.

                                                                                            I won’t pretend that a capability/permission system is perfect, because it isn’t. But in the cases where it has already been implemented, the result clearly seems to be improved privacy. I would personally love to be asked for permission if a game tried to read through my ~/.ssh, access my webcam or record my screen, even if just to uninstall the game and get a refund.

                                                                                            Yes, letting software vendors circumvent whatever little amount of scrutiny software packagers add, that will surely improve security!

                                                                                            I mean, if you wanna complain about distros which use snaps and flatpaks for FOSS software, go right ahead. I’m not a huge fan of that myself. I’m talking about this from the perspective of running closed source software or software otherwise not in the repos, where there’s already no scrutiny from software packagers.

                                                                                            1. 3

                                                                                              There’s probably evidence from existing app stores on whether users prefer to use software that asks for fewer permissions. There certainly seems to be a market for that (witness all the people moving to Signal).

                                                                                              1. 3

                                                                                                But hey, at least you made the life of “trustworthy” applications worse. Good job!

                                                                                                “Trustworthy software” is mostly a lie. Every application is untrustworthy after it gets remotely exploited via a security bug, and they all have security bugs. If we lived in a world without so much memory-unsafe C, then maybe that wouldn’t be true. But we don’t live in that world so it’s moot.

                                                                                                Mozilla has its faults, but I trust them enough to trust that Firefox won’t turn on my webcam and start phoning home with the images. I could even look at the source code if I wanted. But I’d still like Firefox sandboxed away from my webcam because Firefox has memory bugs all the time, and they’re probably exploitable. (As does every other browser, of course, but I trust those even less.)

                                                                                              2. 1

                                                                                                A complete solution does require sandboxing the entire application, including limiting what parts of the filesystem it can access, which daemons it can talk to, and what hardware it can access. But that’s exactly what Flatpak and Snaps attempts to do

                                                                                                But that’s quite limited sandboxing, I think? To be honest I’m not fully up-to-speed with what they’re doing exactly, but there’s a big UX conundrum here because write access to $HOME allows side-channels, but you also really want your applications to do $useful_stuff, which almost always means accessing much (or all of) $HOME.

                                                                                                Attempts to limit this go back a long way (e.g. SELinux), and while this works fairly well for server applications, for desktop applications it’s a lot harder. I don’t really fancy frobbing with my config just to save/access a file to a non-standard directory, and for non-technical users this is even more of an issue.

                                                                                                So essentially I don’t really disagree with:

                                                                                                I should be able to know that due to the technical design of the system, those closed source programs can’t listen to me through my microphone, can’t see me through my webcam, can’t read my keyboard inputs to other windows, and can’t see the content in other windows, and can’t rummage through my filesystem, without my expressed permission. That simply requires a different security model than what X and the traditional UNIX model does.

                                                                                                and I’m not saying that the Wayland model isn’t better in theory (aside from some pragmatical implementation problems, which should not be so casually dismissed as some do IMHO), but the actual practical security benefit that it gives you right now is quite limited, and I think that will remain the case for the foreseeable future as it really needs quite a paradigm shift in various areas, which I don’t really seeing that happening on Linux any time soon.

                                                                                                1. 2

                                                                                                  I don’t really fancy frobbing with my config just to save/access a file to a non-standard directory

                                                                                                  If a standard file-picker dialog were used, it could be granted elevated access & automatically grant the calling application access to the selected path(s).

                                                                                                  1. 1

                                                                                                    there’s a big UX conundrum here because write access to $HOME allows side-channels, but you also really want your applications to do $useful_stuff, which almost always means accessing much (or all of) $HOME.

                                                                                                    This is solved on macOS with powerboxes. The Open and Save file dialogs actually run as a separate process and update the application’s security policy dynamically to allow it to access files that the user has selected, but nothing else. Capsicum was designed explicitly to support this kind of use case, it’s a shame that NIH prevented Linux from adopting it.

                                                                                                    1. 1

                                                                                                      This sounds like a good idea! I’d love to see that in the X11/Wayland/Unix ecosystem, even just because I hate that awful GTK file dialog for so many reasons and swapping it out with something better would make my life better.

                                                                                                      Still; the practical security benefit I – and most users – would get from Wayland today would be very little.

                                                                                                2. 5

                                                                                                  I think “broken” is too loaded; “no longer fit for purpose” might be better.

                                                                                                  1. 2

                                                                                                    Well, the security model is simply broken.

                                                                                                    I agree that a lot of focus is put on security improvements compared to Wayland’s other advantages (tear-free rendering being the one most important to me). But it’s still an advantage over X, and I like software which is secure-by-default.

                                                                                                    1. 1

                                                                                                      How many actual exploits have been found with this?

                                                                                                      They were very common in the ‘90s, when folks ran xhost +. Even now, it’s impossible to write a secure password entry box in X11, so remember that any time you type your password into the graphical sudo equivalents that anything that’s currently connected to your X server could capture it. The reason it’s not exploited in the wild is more down to the fact that *NIX distros don’t really do much application sandboxing and so an application that has convinced a user to run it already has pretty much all of the access that it needs for anything malicious that it wants to do. It’s also helped by the fact that most *NIX users only install things from trusted repositories where it’s less likely that you’ll find malware but expect that to change if installing random snap packages from web sites becomes common.

                                                                                                    2. 4

                                                                                                      It’s good that Wayland allows for sandboxing

                                                                                                      If I wanted to sandbox an X application, I’d run it on a separate X server. Maybe even an Xnest kind of thing.

                                                                                                      I’ve never cared to do this (if I run xnest it is to test network transparency or new window managers or something, not security), so I haven’t tried, but it seems to me it could be done fairly easily if someone really wanted to.

                                                                                                      1. 2

                                                                                                        Whoa, I’ve never heard about the GNOME issues (mostly because I’m in a bubble including sway and emersion, and what they do looks sensible to me). That sucks though, I hope they somehow reconcile.

                                                                                                        Regarding Nvidia I think Simon mentioned something that hinted at them supporting something that has to do with Wayland, but I could just as easily have misunderstood.

                                                                                                      2. 8

                                                                                                        Wayland prohibits your desktop applications from capturing keystrokes or recording other apps’ screens by default

                                                                                                        No, it doesn’t. Theoretically it might enable doing this by modifying the rest of the system too, but in practice (and certainly the default environment) it is still trivial for malware to keylog and record screen on current Wayland desktop *nix installs.

                                                                                                        1. 3

                                                                                                          it is still trivial for malware to keylog and record screen on current Wayland desktop *nix installs.

                                                                                                          I don’t think that’s true. The linked article says recording screens and global hotkeys is “broken” by Wayland. How can it be so trivial for “malware” to do something, and absolutely impossible for anyone else?

                                                                                                          Or is this malware that requires I run it under sudo?

                                                                                                          1. 10

                                                                                                            It’s the difference between doing something properly and just doing it. Malware is happy with the latter while most non malware users are only happy with the former.

                                                                                                            There are numerous tricks you can use if you are malware, from using LD_PRELOAD to inject code and read events first (since everyone uses libwayland this is really easy), to directing clients to connect to your mitm Wayland server, to just using a debugger, and so on and so forth. None of these are really Wayland’s fault, but the existence of them means there is no meaningful security difference on current desktops.

                                                                                                            1. 2

                                                                                                              I don’t know if I agree that the ability to insert LD_PRELOAD in front of another application is equivalent to sending a bytestring to a socket that is already open, but at least I understand what you meant now.

                                                                                                          2. 5

                                                                                                            I’m sick of this keylogger nonsense.

                                                                                                            X11 has a feature which allows you to use the X11 protocol to snoop on keys being sent to other applications. Wayland does not have an equivalent feature.

                                                                                                            Using LD_PRELOAD requires being on the other side of an airtight hatch. It straight-up requires having arbitrary code execution, which you can use to compromise literally anything. This is not Wayland’s fault. Wayland is a better lock for your front door. If you leave your window open, it’s not Wayland’ fault when you get robbed.

                                                                                                            1. 7

                                                                                                              Indeed, it’s not waylands fault, and I said as much in response to the only reply above yours, an hour and 20 minutes before you posted this reply. You’re arguing against a straw man.

                                                                                                              What is the case is that that “airtight hatch” between things that can interact with wayland and things that can do “giant set of evil activities” has been propped wide open pretty much everywhere on desktop linux, and isn’t reasonably easy to close given the rest of desktop software.

                                                                                                              If you were pushing “here’s this new desktop environment that runs everything in secure sandboxes” and it happened to use wayland there would be the possibility of a compelling security argument here. Instead what I see is people making this security argument in a way that could give people the impression it secures things when it doesn’t actually close the barn doors, which is outright dangerous.

                                                                                                              In fact, as far as I know the only desktop *nix OS that does sandbox everything thing is QubesOS, and it looks like they currently run a custom protocol on top of an X server…

                                                                                                              1. 3

                                                                                                                Quoting you:

                                                                                                                Wayland prohibits your desktop applications from capturing keystrokes or recording other apps’ screens by default

                                                                                                                No, it doesn’t.

                                                                                                                Yes, it does. Wayland prohibits Wayland clients from using Wayland to snoop on other Wayland clients. X11 does allow X11 clients to use X11 to snoop on other X11 clients.

                                                                                                                Other features of Linux allow you to circumvent this within the typical use-case, but that’s a criticism of those features moreso than of Wayland, and I’m really tired of it being trotted out in Wayland discussions. Wayland has addressed its part of the problem. Now it’s on the rest of the ecosystem to address their parts. Why do you keep dragging it into the Wayland dicsussion when we’ve already addressed it?

                                                                                                                1. 7

                                                                                                                  This

                                                                                                                  Wayland prohibits your desktop applications from capturing keystrokes or recording other apps’ screens by default

                                                                                                                  And this

                                                                                                                  Wayland prohibits Wayland clients from using Wayland to snoop on other Wayland clients.

                                                                                                                  Are two very different statements. The latter partially specifies the method of snooping, the former does not.

                                                                                                                  Why do you keep dragging it into the Wayland dicsussion when we’ve already addressed it?

                                                                                                                  I do not, I merely reply to incorrect claims brought up in support of wayland claiming that it solves a problem that it does not. It might one day become part of a solution to that problem. It might not. It certainly doesn’t solve it by itself, and it isn’t even part of a solution to that problem today.

                                                                                                          3. 4

                                                                                                            X’s design has many flaws, but those flaws are well known and documented, and workarounds and extensions exist to cover a wide range of use cases. Wayland may have a better design regarding modern requirements, but has a hard time catching up with all the work that was invested into making X11 work for everyone over the last decades.

                                                                                                            1. 3

                                                                                                              X’s design has many flaws, but those flaws are well known and documented, and workarounds and extensions exist to cover a wide range of use cases.

                                                                                                              Once mere flaws become security issues it’s a different matter though.

                                                                                                              [Wayland] has a hard time catching up with all the work that was invested into making X11 work for everyone over the last decades.

                                                                                                              This may be true now, but Wayland is maturing as we speak. New tools are being developed, and there isn’t much missing in the realm of protocol extensions to cover the existing most-wanted X features. I see Wayland surpassing X in the next two, three years.

                                                                                                              1. 2

                                                                                                                Yeah, I started to use sway on my private laptop and am really happy with it. Everything works flawlessly, in particular connecting an external HiDPI display and setting different scaling factors (which does not work in X). However, for work I need to be able to share my screen in video calls occasionally and record screencasts with OBS, so I’m still using X there.

                                                                                                            2. 4

                                                                                                              I wonder if X’s security model being “outdated” is partly due to the inexorable slide away from user control. If all your programs are downloaded from a free repo that you trust, you don’t need to isolate every application as if it’s out to get you. Spotify and Zoom on the other hand are out to get you, so a higher level of isolation makes sense, but I would still prefer this to be the exception rather than the rule.

                                                                                                              In practice 99.9% of malicious code that is run on our systems is done via the web browser, which has already solved this problem, albeit imperfectly, and only after causing it in the first place.

                                                                                                              1. 4

                                                                                                                If all your programs are downloaded from a free repo that you trust, you don’t need to isolate every application as if it’s out to get you

                                                                                                                I completely agree, as long as all of my programs are completely isolated from the network and any other source of untrusted data, or are formally verified. Otherwise, I have to assume that they contain bugs that an attacker could exploit and I want to limit the damage that they can do. There is no difference between a malicious application and a benign application that is exploited by a malicious actor.

                                                                                                                1. 1

                                                                                                                  all of your programs are completely isolated from the network?

                                                                                                                  how are you posting here?

                                                                                                                  1. 2

                                                                                                                    They’re not, that’s my point and that’s why I’m happy that my browser runs sandboxed. Just because I trust my browser doesn’t mean that I trust everyone who might be able to compromise it.

                                                                                                                    1. 1

                                                                                                                      that makes sense for a browser, which is both designed to run malicious code and too complex to have any confidence in its security. but like i said i would prefer cases like this to be the exception. if the rest of your programs are relatively simple and well-tested, isolation may not be worth the complexity and risk of vulnerabilities it introduces. especially if the idea that your programs are securely sandboxed leads you to install less trustworthy programs (as appears to be the trend with desktop linux).

                                                                                                                      1. 2

                                                                                                                        Okay, what applications do you run that never consume input from untrusted sources (i.e. do not connect to the network or open files that might come from another application)?

                                                                                                                        1. 1

                                                                                                                          I don’t think you are looking at this right. The isolation mechanism can’t be 100% guaranteed free of bugs any more than an application can. Your rhetorical question is pretty far from what I thought we were discussing so maybe you could rephrase your argument.

                                                                                                              2. 1

                                                                                                                This argument seems similar to what happened with cinnamon-screensaver a few weeks ago:

                                                                                                                https://github.com/linuxmint/cinnamon-screensaver/issues/354#issuecomment-762261555 (responding to https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/)

                                                                                                                It’s a good thing for security (and maybe for users in the long term once they work again) that these usecases are broken, but it is not a good thing for users in the short term that these usecases don’t work on Wayland.

                                                                                                              1. 13

                                                                                                                A few months ago I started tinkering with Guix. The docs are clear, they used an existing language (Guile Scheme), the CLI is coherent, the error messages mostly make sense. I’ve had to put the side project on hold, but overall it’s been a really positive experience and I’m looking forward to getting back to it.

                                                                                                                Checking back for the repost, I see the bug I filed that Nix’s “hello world” doesn’t build is still open. Looks like the commenters have found a solution, and I see the docs have changed, so maybe it’s solved.

                                                                                                                1. 8

                                                                                                                  As a user I’ve been happier with guix than I have been with nix. Like you I found the docs to be clear and the CLI to be coherent. Where it falls short for me is there doesn’t seem to be consistent support for things like GNOME or KDE.

                                                                                                                  1. 7

                                                                                                                    Guix looks great and after hitting many frustrating roadblocks with Nix I was also hoping to use it. The problem is that it suffers from the same disease that many GNU projects do. It prefers ideological purity over actually working for users. I’m not allowed to have CUDA support, MKL, etc. There’s a reason why Nix has far more users even though it appears to be inferior.

                                                                                                                    1. 3

                                                                                                                      It goes against the principles of the Guix developers, but if you don’t share all their principles, you can immediately install the nonguix Guix channel from nonguix

                                                                                                                      1. 4

                                                                                                                        It’s not so easy. I can’t ask questions about these packages or get help with them:

                                                                                                                        Please do NOT promote or refer to this repository on any official Guix communication channels.

                                                                                                                        They’re also very thin, for example, there are no CUDA packages.

                                                                                                                        Guix developers can of course use whatever principles to guide their development, but it is sad that some types of thoughts are ideologically forbidden in the community. I don’t want to be a part of that personally. It’s also a huge waste of developer time.

                                                                                                                        1. 1

                                                                                                                          CUDA isn’t really something that with be on the guix maintainers to make work. Like most community projects it will be a matter of growing the community and waiting for people to take up the task of packaging CUDA.

                                                                                                                          There is a guix HPC group and while they haven’t added CUDA support that is one of those things I sort of expect to be coming with time and as interest in guix mounts.

                                                                                                                          1. 2

                                                                                                                            For sure, the Guix maintainers don’t need to get it working, but it’s not that they don’t care about CUDA or any of these other packages. They are actively hostile by not even allowing people to discuss them in their presence. They also refuse to, for example, test if any Guix changes break these packages. You cannot even file a bug report that a Guix change breaks a non-free package!

                                                                                                                            There is a big difference between “it’s not up to the devs to do this” and the “devs are actively opposed”. Compare the Guix approach to the Debian one. Debian also doesn’t want people to use non-free software and it lives in a separate directory. But I am allowed to discuss such packages on the mailing list and IRC. I can ask questions if I have difficulty with a package, of course, the devs don’t need to answer, but someone else maybe can. I can file a bug report to say that a change affects me. All of these are forbidden and enforced by the Guix developers.

                                                                                                                            It’s a shame that Guix developers are so dogmatic and politicized that they actively expend effort to hurt users when they could just let them be.

                                                                                                                      2. 2

                                                                                                                        I know it’s annoying, but nobody is stopping you from writing derivations (or whatever the Guix equivalent is called) for those features. It’s just not supported by the Guix developers and project in an official capacity, because it goes against the push for people to use Free Software and hardware which supports that.

                                                                                                                        1. 6

                                                                                                                          because it goes against the push for people to use Free Software and hardware which supports that. This is why Nix will always have more users. Programers need to solve problems and sometimes the easiest/best solution involves proprietary software. Nix gives its users the freedom to (more easily) use non-free software.

                                                                                                                          At work when I have a deadline or for personal projects where I have limited free time, I don’t want to have a lot of extra work just because the best solution uses some proprietary code. In a perfect world I would only use free software, but I have work to do.

                                                                                                                          1. 4

                                                                                                                            Well yeah, I’m not saying you’re wrong, I’m saying you’re not the target audience for Guix.

                                                                                                                            1. 5

                                                                                                                              That is a fair point. My worry is that that target audience for this very useful piece of technology would be much greater if they were slightly less dogmatic with their approach to non-free software.

                                                                                                                  1. 14

                                                                                                                    Why did Haskell’s popularity wane so sharply?

                                                                                                                    What is the source that Haskell’s popularity are declining so sharply? Is there really some objective evidence for this, I mean numbers, statistics, etc.?

                                                                                                                    It’s anecdotal and just my personal impression by observing the Haskell reddit 1 for 10 years, but I have never seen so many Haksell resources, Conferences, Books and even postings for jobs as now. I have not at all the impression that the language is dying. It has accumulated cruft, has some inconsistencies, is struggling to get a new standard proposal out, but other than that I have the impression that it attracts quite some people that come up with new ideas.

                                                                                                                    1. 2

                                                                                                                      Haskell had glory days when SPJ/Marlow were traveling to various conferences talking about the new language features. Mileweski’s posts, LYAH, Parsec, STM, and Lenses are from that era. The high-brow crowd was of course discussing Lenses. Sure, these things drove adoption, and there’s a little ecosystem for the people who went on the Haskell bandwagon back then.

                                                                                                                      What innovation has it had over the last 5 years? The community couldn’t agree on how to implement any of the features of a respectable dependent-type system, so they invented a bunch of mutually incompatible flags, and destroyed the language. Thanks to the recent hacking, GHC is plastered with band-aids.

                                                                                                                      It’s true that you can’t explain these things with some points on a pretty graph, but that doesn’t make it anecdotal. Look at the commits going into ghc/ghc, and look at the activity on the bread-and-butter Haskell projects: lens, trifecta, cloud-haskell. Maintenance mode. Where are the bold new projects?

                                                                                                                      1. 23

                                                                                                                        These assertions about Haskell are all simply false. There are plenty of problems with Haskell, we don’t need to add ones that aren’t true.

                                                                                                                        The community couldn’t agree on how to implement any of the features of a respectable dependent-type system, so they invented a bunch of mutually incompatible flags, and destroyed the language. Thanks to the recent hacking, GHC is plastered with band-aids

                                                                                                                        The reason GHC didn’t just turn on all flags by default is that many of them are mutually incompatible, so your individual .hs file has to pick a compatible set of language features it wants to work with.

                                                                                                                        You keep saying this in multiple places, but it’s not true. Virtually no GHC extensions are incompatible with one another. You have to work hard to find pairs that don’t get along and they involve extremely rarely used extensions that serve no purpose anymore.

                                                                                                                        The community is also not divided on how to do dependent types. We don’t have two camps and two proposals to disagree about. The situation is that people are working together to figure out how to make them happen. GHC also doesn’t contain bad hacks for dependent types, avoiding this is exactly why building out dependent types is taking time.

                                                                                                                        That being said, dependent types work today with singletons. I use them extensively. It is a revolution in programming. It’s the biggest step forward in programming that I’ve seen in 20 years and I can’t imagine life without them anymore, even in their current state.

                                                                                                                        Look at the commits going into ghc/ghc, and look at the activity on the bread-and-butter Haskell projects: lens, trifecta, cloud-haskell. Maintenance mode. Where are the bold new projects?

                                                                                                                        Haskell is way more popular today than it was 5 years ago, and 10 years ago, and 20 years ago. GHC development is going strong, for example, we just got linear types, a huge step forward. There’s been significant money lately from places like cryptocurrency startups. For the first time I regularly see Haskell jobs advertised. What is true, is that the percentage of Haskell questions on stack overflow has fallen, but not the amount. The size of Stack Overflow exploded.

                                                                                                                        Even the community is much stronger than it was 5 years ago. We didn’t have Haskell Weekly news for example. Just this year a category theory course was taught at MIT in Haskell making both topics far more accessible.

                                                                                                                        Look at the commits going into ghc/ghc

                                                                                                                        Let’s look. Just in the past 4 years we got: linear types, a new low-latency GC, compact regions, deriving strategies & deriving via, much more flexible kinds, all sorts of amazing new plugins (type plugins, source plugins, etc.) that extend the language and provide reliable tooling that was impossible 5 years ago, much better partial type signatures, visible type applications (both at the term level and the type level), injective type families, type in type, strict by default mode. And much more!

                                                                                                                        This totally changed Haskell. I don’t write Haskell the way I did 5 years ago, virtually nothing I do would work back then.

                                                                                                                        It’s not just GHC. Tooling is amazing compared to what we had in the past. Just this year we got HLS so that Haskell works beautifully in all sorts of editors now from Emacs, to vscode, to vim, etc.

                                                                                                                        look at the activity on the bread-and-butter Haskell projects: lens, trifecta, cloud-haskell. Maintenance mode. Where are the bold new projects?

                                                                                                                        lens is pretty complete as it is and is just being slowly polished. Haskell packages like lens are based on a mathematical theory and that theory was played out. That’s the beauty of Haskell, we don’t need to keep adding to lens.

                                                                                                                        I would never use trifecta today, megaparsec is way better. It’s seen a huge amount of development in the past 5 years.

                                                                                                                        There are plenty of awesome Haskell packages. Servant for example for the web. Persistent for databases. miso for the frontend. 5 years ago I couldn’t dream of deploying a server and frontend that have a type-checked API. For bold new ideas look at all the work going into neural network libraries that provide type safety.

                                                                                                                        I’m no fanboy. Haskell has plenty of issues. But it doesn’t have the issues you mentioned.

                                                                                                                        1. 1

                                                                                                                          Right. Most of my Haskell experience is dated: from over five years ago, and the codebase is proprietary, so there are few specifics I can remember. I’m definitely not the best person to write on the subject. In any case, I’ve rewritten the Haskell section of the article, with more details. Thanks.

                                                                                                                          1. 6

                                                                                                                            From my definition of “dying language” it means losing popularity, or losing interest. For Haskell this is absolutely not clear. Also your section is about “why Haskell is bad” not “why it is dying”. People do not talk about Haskell as they used to in my opinion, but I still see a lot of activity in Haskell ecosystem. And it doesn’t really look like it’s dying.

                                                                                                                            I think it is easier to agree about Clojure dying looking at Google trends for example: https://trends.google.com/trends/explore?cat=5&date=all&geo=US&q=haskell,clojure

                                                                                                                            But Haskell looks more like a language that will never die but still probably never become mainstream.

                                                                                                                            1. 5

                                                                                                                              I’m definitely not the best person to write on the subject. In any case, I’ve rewritten the Haskell section of the article, with more details. Thanks.

                                                                                                                              Great! Although there are still many issues that are factually untrue.

                                                                                                                              I think this is just a sign that you’ve been away from the community for many years now, and don’t see movement on the things that were hot 5-10 years ago. Like “The high-brow crowd was obssessed with transactional memory, parser combinators, and lenses.” Well, that’s over. We figured out lenses and have great libraries, we figured out parser combinators, and have great libraries. The problems people are tackling now for those packages are engineering problems, not so much science problems. Like how do we have lenses and good type errors? And there, we’ve had awesome progress lately with custom error messages https://kodimensional.dev/type-errors that you would not have seen 5 years ago.

                                                                                                                              The science moved on to other problems.

                                                                                                                              The issue is that different extensions interact in subtle ways to produce bugs, and it’s very difficult to tell if a new language extension will play well with the others (it often doesn’t, until all the bugs are squashed, which can take a few years).

                                                                                                                              This still isn’t true at all. As for the release cadence of GHC, again, things have advanced amazingly. New test environments and investments have resulted in regular GHC releases. We see several per year now!

                                                                                                                              In Atom, the Haskell addon was terrible, and even today, in VSCode, the Haskell extension is among the most buggy language plugins.

                                                                                                                              That was true a year ago, it is not true today. HLS merged all efforts into a single cross-editor package that works beautifully. All the basic IDE functionality you would want is a solved problem now, the community is moving on to fun things like code transformations.

                                                                                                                              Then there’s Liquid Haskell that allows you to pepper your Haskell code with invariants that it will check using Z3. Unfortunately, it is very limited in what it can do: good luck checking your monadic combinator library with LH

                                                                                                                              Not true for about 3 years. For example: https://github.com/ucsd-progsys/liquidhaskell/blob/26fe1c3855706d7e87e4811a6c4d963d8d10928c/tests/pos/ReWrite7.hs

                                                                                                                              The worst case plays out as follows: the typechecker hangs or crashes, and you’re on the issue tracker searching for the issue; if you’re lucky, you’ll find a bug filed using 50~60% of the language extensions you used in your program, and you’re not sure if it’s the same issue; you file a new issue. In either case, your work has been halted.

                                                                                                                              In 15 years of using Haskell I have never run into anything like this. It is not the common experience. My code is extremely heavy and uses many features only available in the latest compiler, with 20-30 extensions enabled. Yet this just doesn’t happen.

                                                                                                                              There is almost zero documentation on language extensions. Hell, you can’t even find the list of available language extensions with some description on any wiki.

                                                                                                                              Every single version of GHC has come with a list of the extensions available, all of which have a description, most of which have code: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html You can link to the manual that neatly explains everything, rather than to the git repo.

                                                                                                                              Looking at the big picture: first, this is a poor way to do software development; as the number of language extensions increase, your testing burden increases exponentially.

                                                                                                                              This is only true if you can’t prove how extensions interact, or more fundamentally, that they don’t interact.

                                                                                                                              Second, the problem of having a good type system is already solved by a simple dependent type theory; you study the core, and every new feature is just a small delta that fits in nicely with the overall model.

                                                                                                                              That’s totally untrue. There is no such general-purpose language today. We have no idea how to build one.

                                                                                                                              As opposed to having to read detailed papers on each new language extension. And yes, there’s a good chance that very few people will be able to understand your code if you’re using some esoteric extensions.

                                                                                                                              Again, that’s just not true. You don’t need to know how the extensions are implemented. I have not read a paper on any of the extensions I use all the time.

                                                                                                                              In summary, language extensions are complicated hacks to compensate for the poverty of Haskell’s type system.

                                                                                                                              That’s just the wrong way to look at language extensions. Haskell adds features with extensions because the design is so good. Other languages extend the language forcing you into some variant of it because their core is too brittle and needs fundamental changes. Haskell’s core is so solid we don’t need to break it.

                                                                                                                              However, PL research has shifted away from Haskell for the most part

                                                                                                                              That’s again totally factually untrue. Just look at Google Scholar, the number of Haskell papers per year is up, not down. The size of the Haskell workshop at ICFP is the same as 5 years ago.

                                                                                                                              Moreover, there are no tools to help you debug the most notorious kind of bug seen in a complicated codebase: memory blowups caused by laziness.

                                                                                                                              Again, that’s not factually true.

                                                                                                                              We have had a heap profiler for two decades, in the past few years we got ThreadScope to watch processes in real time. We have systematic ways to find such leaks quickly, you just limit the GC to break when leaks happen. https://github.com/ndmitchell/spaceleak We also got stack traces in the past few years so we can locate where issues come from. In the past few years we got Strict and StrictData.

                                                                                                                              As for the code examples. I can pick 2 lines of any language out of context and you’ll have no idea what they do.

                                                                                                                              Who cares what every extension does for every example? That’s the whole point! I have literally never looked at a piece of Haskell code and wondered what an extension does. I don’t need to know. GHC tells me when I need to add an extension and it tells me when an extension is unused.

                                                                                                                              How many more language features are missing?

                                                                                                                              Extensions are not missing language features.

                                                                                                                            2. 1

                                                                                                                              GHC also doesn’t contain bad hacks for dependent types, avoiding this is exactly why building out dependent types is taking time.

                                                                                                                              Honestly, I’d much rather prefer a simple core model, like that of HoTT.

                                                                                                                              1. 3

                                                                                                                                Honestly, I’d much rather prefer a simple core model, like that of HoTT.

                                                                                                                                I’d love that too! As would everyone!

                                                                                                                                But the reality is, we don’t know how to do that. We don’t even know how to best represent computations in HoTT. It might be decades before we have a viable programming language. We do have dependent types that work well in Haskell today, that I can deploy to prod, and that prevent countless bugs while making code far easier to write.

                                                                                                                                1. 1

                                                                                                                                  I think HoTT with computations is “cubical type theory”? It’s very active currently.

                                                                                                                                  As for the dependent types as the backend for advanced type level features, I think it’s what Dotty/scala 3 is about. It’s definitely not the only way to do it, but it’s also not decades away. Idris 2 is also an interesting effort.

                                                                                                                            3. 4

                                                                                                                              Dependent types aren’t that useful for production software, and full blown dependent types are really contrary to the goals of Haskell in a lot of ways. Any language that’s >20 years old (basically 30) is gonna have some band-aids. I’m not convinced that Haskell is waning in any meaningful way except that people don’t hype it as much on here/hn. Less hype and more doing is a good thing, imho.

                                                                                                                              1. 3

                                                                                                                                Reminds me of the days when people said FP and complete immutability weren’t useful for production software. It is true that there is no decent general purpose language that implements dependent types, but that’s besides the point.

                                                                                                                                It’s true, hype is a poor measure.

                                                                                                                                1. 4

                                                                                                                                  Yeah, that’s an interesting comparison, but I think it’s a totally different situation. Immutability and dependent types both are things you do to make certain assumptions about your code. In that, immutability allows you to know that some underlying value won’t change. Dependent types allow you to make more general statements/proofs of some invariant. The big difference is that immutability is a simplification. You’re removing complexity by asserting some assumption throughout your code. Generally, dependent types are adding complexity. You have to provide proofs of some statement externally or you have to build the proof of your invariants intrinsically into your constructions. IMHO, that’s a huge difference for the power to weight ratio of these two tools. Immutability is really powerful and fairly light weight. Dependent types are not really that powerful and incredibly heavy. I’m not saying dependent types are worthless. Sometimes you really really want that formal verification (eg. compilers, cryptography, etc). The vast majority of code doesn’t need it, and you’re just adding complexity, something I think should be avoided in production software.

                                                                                                                                  1. 3

                                                                                                                                    Tl;dr I have a good amount of experience with dependently typed languages, and I write Haskell for a living. After all of my experience, I have come to the conclusion that dependent types are over hyped.

                                                                                                                                    1. 1

                                                                                                                                      I’ve started writing a post on dependent types. Here’s early draft: https://artagnon.com/articles/dtt

                                                                                                                                    2. 3

                                                                                                                                      What about Ada?

                                                                                                                              1. 13

                                                                                                                                What I don’t get is why this type of stories about Elm is so reliably posted and upvoted, even though they’re all about the same two issues that aren’t really technical and have been discussed ad nauseam here and in other forums.

                                                                                                                                There are far more interesting things happening. For example, the other day a new version of elm-review came out. elm-review is a static analysis tool with rules written in Elm. Seems more relevant to Lobste.rs.

                                                                                                                                I don’t see many stories about Elm on here, but when one of these pops up, I know it’s going to be posted and upvoted.

                                                                                                                                1. 23

                                                                                                                                  If you think they’re more relevant, then post them! There are plenty of “topic” posters here and they usually do just fine.

                                                                                                                                  1. 22

                                                                                                                                    I think these stories get upvoted because a lot of people here are bitter, like I am. I was a very heavy Elm user with tens of thousands of lines of code across many projects in Elm + Haskell with extensive bindings between the two. All of that effort and time spent teaching people Elm and getting it adopted by coworkers/collaborators were all trashed. We had to throw away everything we built. All because of an arbitrary decision to cripple the language.

                                                                                                                                    In my opinion Elm is now a toy language completely unsuited for any serious development. You cannot bet your company on a language where the answer to a missing library is “wait and see if the devs will take you seriously one day”.

                                                                                                                                    Sorry! I’m one of these people that upvotes these posts :)

                                                                                                                                    1. -8

                                                                                                                                      Well, you can sure hold a grudge! We’re talking about events from two years ago. The thing is, while upvoting these stories might give you and others a sense of vindication, it’s not really helping with the quality of content on Lobste.rs, in my view. There is little value in endlessly rehashing old issues that are not even technical in nature. So perhaps take that into account next time?

                                                                                                                                      1. 17

                                                                                                                                        This was a pretty rude reply to my very nice comment! Maybe you should take that into account next time?

                                                                                                                                        The relationship between open source projects and developers is an ongoing discussion and obviously is of interest to everyone. As evidenced by the fact that people are reading and upvoting this.

                                                                                                                                        1. 4

                                                                                                                                          Aside from your lack of empathy with people who had to throw away their hard work, what I don’t get is why would you engage with Lobsters content that you personally don’t like. Not everything is for everyone, people who personally don’t like some topics here normally don’t question why it’s even here, they just keep scrolling…

                                                                                                                                      2. 13

                                                                                                                                        I’ve read and dismissed other examples of elm griping, but I think this one is very articulate and argues its case very well. I’m convinced on most points where I wasn’t before.

                                                                                                                                        1. 7

                                                                                                                                          I think people should be warned about this over and over again. It’s more beneficial to the innocent bystander to know about this weird situation that’s unique to Elm than some new release of some Elm library. People should have an idea about what they’re risking by choosing to invest in Elm.

                                                                                                                                          1. 5

                                                                                                                                            I’m not using Elm at the moment (just not doing front-end), but I’d be pretty happy to upvote them if you posted interesting Elm stories here. Anyway, I agree that this one isn’t especially interesting, but it seems on-topic enough. It also didn’t scare me away from the language.

                                                                                                                                          1. 12

                                                                                                                                            This has nothing to do with tech, it happens everywhere in higher paid jobs when comparing the US to the EU. Everyone is giving you gut feel answers, but this is an economics question and has answers that we can back up with data.

                                                                                                                                            The driving force for this is inequality. The inequality in the US is far larger than that in the EU. So people who have worse jobs have worse lives than in the EU and people who have really good jobs do far better. Just to put this in context. You’re in the top 1% of earners in France with $215k per year but you need $475k per year to be in the top 1% in the US.

                                                                                                                                            You can also see this from another angle. You say that devs are paid doctor or lawyer salaries in the US compared to the EU. But those are EU doctors and lawyers. In the US they also make far more.

                                                                                                                                            Another, but much smaller contributor to this, is that the average salary in the US is 30% higher than the richer EU countries.

                                                                                                                                            1. 5

                                                                                                                                              You can see this across almost all scales in almost all fields, too. As a professor in Denmark, I made significantly less than most American professors—but our PhD students and non-academic staff made significantly more than most American equivalents. In the US you often have 5x or more ratios between different levels, e.g.: cafeteria worker makes $20k, PhD student makes $25k, prof makes $100k, senior administrator makes $500k. In Denmark, it’s more often 0.5x than 5x, something like: cafeteria worker makes $40k, PhD student makes $55k, prof makes $70k, senior administrator makes $100k. By American standards, some of these salaries are low and some are high.

                                                                                                                                              1. 2

                                                                                                                                                The driving force for this is inequality. The inequality in the US is far larger than that in the EU.

                                                                                                                                                It also has to do with global inequality.

                                                                                                                                                1. 1

                                                                                                                                                  I was investigating software engineering jobs in the EU about 1-2 years ago; this was roughly the conclusion I came to. The EU has less inequality and, usually, better social benefits. While I like being paid US salaries, I can’t help but think the EU is generally a healthier place on most axes.

                                                                                                                                                1. 29

                                                                                                                                                  I’d like to provide a more sympathetic outside perspective.

                                                                                                                                                  There are a few common complaints about Elm and Elm community:

                                                                                                                                                  • Blocking discussion (locking threads etc.)
                                                                                                                                                  • Insufficient communication about Elm development
                                                                                                                                                  • Things getting removed from the language.

                                                                                                                                                  With regards to blocking discussion, I think the logic is something like this:

                                                                                                                                                  • The core developers have a roadmap for Elm development and they want to stick to it
                                                                                                                                                  • They tried including more developers but haven’t found an effective way to deal with more contributors
                                                                                                                                                  • Therefore, they have limited time
                                                                                                                                                  • They can spend this time rehashing the same arguments and debating half-baked ideas, or they can spend this time following their roadmap, but not both.

                                                                                                                                                  I would prefer that the discussions weren’t removed or locked, but on the other hand, it’s got to be grating to deal with the same entitled, uninformed or complaining comments all the time. I’ve read most of these discussions, and other than people venting, nothing is ever achieved in them. My reflexive reaction is to be uncomfortable (like a lot of other people) but then, there is also a certain clarity when people just say that they will not engage in a discussion.

                                                                                                                                                  With regards to insufficient communication, I think the main things to understand is that Elm is an experiment in doing things differently, and it’s causing a clash with conventional understanding. Elm is about getting off the upgrade treadmill. So, for example, when a new release like Elm 0.19 comes out, it happens without a public alpha and beta phases, and it’s not actually the point where you go and immediately migrate your production code to it! It’s only the point to start experimenting with it, it’s the point where library and tool authors can upgrade and so on. (There was quite a bit of activity prior to release anyway, it just wasn’t advertised publicly.)

                                                                                                                                                  Finally, the most contentious example of a “feature” getting removed is the so called native modules (which basically means the ability to have impure functions written in JS in your Elm code base). As far as I can tell (having followed Elm since 0.16), native modules were always an internal implementation detail and their use was never encouraged. Nevertheless, some people started using them as a shortcut anyway. However, they were a barrier to enabling function-level dead code elimination which is the main feature of the 0.19 release, so the loophole was finally closed. Sure, it’s inconvenient for people who used them, but does anyone complain when, say, Apple removes an internal API?

                                                                                                                                                  Ultimately, Elm is just an open source project and the core maintainers don’t really owe anybody anything - no contracts are entered into and no funds are exchanged. They can do whatever they want.

                                                                                                                                                  Of course, there is a question of the long term effects this approach is going to have on the community. Will it alienate too many people and cause Elm to wither? Will Elm remain a niche language for a narrow class of applications? That remains to be seen.

                                                                                                                                                  1. 24

                                                                                                                                                    but on the other hand, it’s got to be grating to deal with the same entitled, uninformed or complaining comments all the time.

                                                                                                                                                    Over the years, I have come to believe this is a vital part of building a community. Using draconian tactics to stomp out annoying comments is using power unwisely and worse yet – cripples your community in multiple ways.

                                                                                                                                                    The first thing to remember is that when a comment (entitled, uninformed or otherwise) comes up repeatedly – that is a failure of the community to provide a resource to answer/counter/assist with that comment. That resource can be a meme, a link, an image, a FAQ, a full on detailed spec document, whatever. This type of thing is part of how a community gets a personality. I think a lot of the reason there are a bunch of dead discourse servers for projects is too stringent policing. You should have a place for people to goof off and you have to let the community self police and become a real community. Not entirely, obviously, but on relevant topics.

                                                                                                                                                    This constant repetition of questions/comments is healthy, normal, it is the entrance of new people to the community. More importantly, if gives people who are just slightly deeper in the community someone to help, someone to police, someone to create resources for, even to a degree someone to mock (reminding them they aren’t THAT green anymore) – a way to be useful! This is a way to encourage growth, each “generation” of people helps the one that comes after them – and it is VITAL for building up a healthy community. In a healthy community the elders will only wade in occasionally and sporadically to set the tone and will focus on the more high minded, reusable solutions that move the project forward. Leave the minor stuff be done by the minor players, let them shine!

                                                                                                                                                    Beyond being vital to build the community – it is a signal of where newcomers are hurting. Now if documentation fixes the problem, or a meme… terrific! But if it doesn’t, and if it persists … that is a pain point to look at – that is a metric – that is worth knowing.

                                                                                                                                                    1. 7

                                                                                                                                                      Yeah, each one of these people gives you a chance to improve how well you communicate, and to strengthen your message. But shutting down those voices then run the risk of surrounding yourself with ‘yes people’ who don’t challenge your preconceptions. Now, it’s entirely up to the Elm people to do this, but I think they are going to find it harder to be mainstream with this style of community.

                                                                                                                                                      Note that I’m perfectly fine with blocking and sidelining people who violate a CoC, or are posting hurtful, nonconstructive comments. You do have to tread a fine line in your moderation though. Being overly zealous in ‘controlling the message’ can backfire in unpredictable ways.

                                                                                                                                                      Anyway, I continue to follow Elm because I think the designer has some excellent ideas and approaches, even if I do disagree with some of the ways the way the community is managed.

                                                                                                                                                      1. 7

                                                                                                                                                        even if I do disagree with some of the ways the way the community is managed.

                                                                                                                                                        I don’t think the two jobs (managing the community and managing the project) should necessarily be done by the same person. I actually think it probably shouldn’t. Each job is phenomenally challenging on its own – trying to do both is too much.

                                                                                                                                                        1. 2

                                                                                                                                                          Yeah, completely agree! I think it would take a huge weight of that person’s shoulders too! :)

                                                                                                                                                          1. 1

                                                                                                                                                            I don’t think Evan personally moderates the forums. Other people do it these days.

                                                                                                                                                            1. 4

                                                                                                                                                              But, they do it on his behalf? This policy of locking and shutting down discussions comes from somewhere. That person directly or indirectly is the person who “manages” the community, the person who sets the policies/tone around such things.

                                                                                                                                                              I personally have no idea, I am not active in the Elm community.

                                                                                                                                                              1. 1

                                                                                                                                                                I’m not sure who sets the policy and how.

                                                                                                                                                        2. 2

                                                                                                                                                          That’s a very interesting perspective, thanks.

                                                                                                                                                        3. 14

                                                                                                                                                          I’ll add the perspective of someone who loved Elm and will never touch it again. We’re rewriting in PureScript right now :) I’m happy I learned Elm, it was a nice way of doing things while it lasted.

                                                                                                                                                          In Elm you may eventually hit a case where you can’t easily wrap your functionality in ports, the alternative to native modules. We did, many times. The response on the forum and other places is often to shut down your message, to give you a partial version of that functionality that isn’t quite what you need, to tell you to wait until that functionality is ready in Elm (a schedule that might be years!), or until recently to point you at native modules. This isn’t very nice. It’s actually very curious how nice the Elm community is unless you’re talking about this feature, in which case it feels pretty hostile. But that’s how open source rolls.

                                                                                                                                                          Look at the response to message linked in the story: “We recently used a custom element to replace a native modules dealing with inputs in production at NoRedInk. I can’t link to it because it’s in a proprietary code base but I’ll be writing an speaking about it over the next couple months.”

                                                                                                                                                          This is great! But I can’t wait months in the hope that someone will talk about a solution to a problem I have today. Never mind releasing one.

                                                                                                                                                          Many people did not see native modules as a shortcut or a secret internal API. They were an escape valve. You would hit something that was impossible without large efforts that would make you give up on Elm as not being viable. Then you would overcome the issues using native modules which many people in the community made clear was the only alternative. Now, after you invest effort you’re told that there’s actually no way to work around any of these issues without “doing them the right way” which turns out to be so complicated that companies keep them proprietary. :(

                                                                                                                                                          I feel like many people are negative about this change because it was part of how Elm was sold to people. “We’re not there yet, but here, if we’re falling short in any way you can rely on this thing. So keep using Elm.”

                                                                                                                                                          That being said, it feels like people are treating this like an apocalypse, probably because they got emotionally invested in something they like and they feel like it’s being changed in a way that excludes them.

                                                                                                                                                          You’re right though. Maybe in the long term this will help the language. Maybe it will not. Some people will enjoy the change because it does lead to a cleaner ecosystem and it will push people to develop libraries to round out missing functionality. In the short term, I have to get things done. The two perspectives often aren’t compatible.

                                                                                                                                                          I’m personally more worried about what will happen with the next major change where Elm decides to jettison part of its community. I don’t want to be around for that.

                                                                                                                                                          1. 2

                                                                                                                                                            If people encouraged you to use native modules, then that was unfortunate.

                                                                                                                                                            I’m not sure I understand the issue with custom elements. Sure, they’re a bit complicated and half baked but it certainly doesn’t require a research lab to use them (in fact, I’ve just implemented one now).

                                                                                                                                                            I would agree, however, that the Elm developers have a bit of a hardline approach to backward compatibility. Perhaps there is a misunderstanding around the state of Elm - ie whether it’s still an experiment that can break compatibility or a stable system that shouldn’t.

                                                                                                                                                            I’m not sure how I feel about backward compatibility. As a user, it’s very convenient. As a developer, it’s so easy to drown in the resulting complexity.

                                                                                                                                                          2. 10

                                                                                                                                                            I would prefer that the discussions weren’t removed or locked, but on the other hand, it’s got to be grating to deal with the same entitled, uninformed or complaining comments all the time. I’ve read most of these discussions, and other than people venting, nothing is ever achieved in them. My reflexive reaction is to be uncomfortable (like a lot of other people) but then, there is also a certain clarity when people just say that they will not engage in a discussion.

                                                                                                                                                            I’ll go one further and say I’m quite glad those discussions get locked. Once the core team has made a decision, there’s no point in having angry developers fill the communication channels the community uses with unproductive venting. I like the decisions the core team is making, and if those threads didn’t get locked, I’d feel semi-obligated to respond and say that I’m in favor of the decision, or I’d feel guilty not supporting the core devs because I have other obligations. I’m glad I don’t have to wade through that stuff. FWIW, it seems like the community is really good at saying “We’re not going to re-hash this decision a million times, but if you create a thread about a specific problem you’re trying to solve, we’ll help you find an approach that works” and they follow through on that.

                                                                                                                                                            I don’t have a lot of sympathy for folks who are unhappy with the removal of the ability to compile packages that include direct JS bindings to the Elm runtime. For as long as I’ve been using Elm the messaging around that has consistently been that it’s not supported, it’s just an accidental side effect of how things are built, and you shouldn’t do it or you’re going to have a bad time. Now it’s broken and they’re having a bad time. This should not be a surprise. I also think it’s good decision to actively prohibit it. If people started using that approach widely, it would cause a lot of headaches for both the community and hamstring the core team’s ability to evolve the language.

                                                                                                                                                            1. 7

                                                                                                                                                              I’m quite glad those discussions get locked

                                                                                                                                                              and

                                                                                                                                                              I like the decisions the core team is making

                                                                                                                                                              Do you believe your perspective would change if you didn’t agree with the developers decisions? Obviously I have a different perspective but I am curious if think you would still have this perspective if you were on the other side?

                                                                                                                                                              Additionally, just because the core team has “made a decision” doesn’t mean it wasn’t a mistake, nor that it is permanent. Software projects make mistakes all the time, and sometimes the only way to really realize the mistake is the hear the howls of your users.

                                                                                                                                                              1. 4

                                                                                                                                                                I’m pretty confident I wouldn’t change my position on this if I wasn’t in agreement with the core team’s choices. I might switch to PureScript or ReasonML, if I think the trade-offs are worth it, but I can’t see myself continuing to complain/vent after the decision has been made. I think appropriate user input is “I have this specific case, here’s what the code look like, here’s the specific challenge with any suggested alternative” If the core team decides to go another way after seeing their use cases, it’s clear we don’t have the same perspective on the trade-offs for those decisions. I can live with that. I don’t expect everybody to share my opinion on every single technical decision.

                                                                                                                                                                As an example, I use Clojure extensively at work, and I very much disagree with Rich Hickey’s opinions about type systems, but it’s pretty clear he’s thought through his position and random folks on the internet screaming differently isn’t going to change it, it’ll just make his job more difficult. I can’t imagine ever wanting to do that to someone.

                                                                                                                                                                sometimes the only way to really realize the mistake is the hear the howls of your users

                                                                                                                                                                It’s been my experience that the folks who can provide helpful feedback about mistaken technical decisions rarely howl. They can usually speak pretty clearly about how decisions impact their work and are able to move on when it’s clear there’s a fundamental difference in goals.

                                                                                                                                                                1. 3

                                                                                                                                                                  It’s been my experience that the folks who can provide helpful feedback about mistaken technical decisions rarely howl.

                                                                                                                                                                  We fundamentally disagree on this point (and the value of the noisy new users), and I don’t think either of us is going to convince the other. So, I think this is a classic case of agree to disagree.

                                                                                                                                                            2. 10

                                                                                                                                                              I think what bothers me the most about the core team’s approach to features is not that they keep removing them, but that for some they do not provide a valid alternative.

                                                                                                                                                              They’ll take away the current implementation of native modules, but coming up with a replacement is too hard, so even though the core libraries can use native code, us peasants will have to do without.

                                                                                                                                                              They won’t add a mechanism for higher rank polymorphism because coming up with a good way to do it is hard, so even though the base library has a few magic typeclasses for its convenience, us peasants will have to make do with mountains of almost duplicated code and maybe some code generation tool.

                                                                                                                                                              So where does that leave Elm right now? Should it be considered a production-ready tool just by virtue of not having very frequent releases? Or should it be regarded as an incomplete toy language, because of all the breaking changes between releases, all the things that haven’t been figured out yet, and how the response to requests for ways to do things that are necessary in real code is either “you don’t need that”, which I can live with most of the time, or “deal with it for the moment”, which is unacceptable.

                                                                                                                                                              I think Elm should make it more clear that it’s ostensibly an unfinished project.

                                                                                                                                                              1. 3

                                                                                                                                                                They’ll take away the current implementation of native modules, but coming up with a replacement is too hard

                                                                                                                                                                They won’t add a mechanism for higher rank polymorphism because coming up with a good way to do it is hard

                                                                                                                                                                I don’t think this is a fair characterization of the core team’s reasons for not supporting those features. I’ve read/watched/listened to a lot of the posts/videos/podcasts where Evan and other folks discuss these issues, and I don’t think I’ve ever heard anyone say “We can’t do it because it’s too difficult.” There’s almost always a pretty clear position about the trade-offs and motivations behind those decisions. You might not agree with those motivations, or weigh the trade-offs the same way, but it’s disingenuous to characterize them as “it’s too hard”

                                                                                                                                                                1. 5

                                                                                                                                                                  I exaggerate in my comment, but what I understood from the discussions around rank n polymorphism I’ve followed is basically that Evan doesn’t think any of the existing solutions fit Elm.

                                                                                                                                                                  I understand that language design, especially involving more complex features like this, is a hard issue, and I’m sure Evan and the core team have thought long and hard about this and have good reasons for not having a good solution yet, but the problem remains that hard things are hard and in the meantime the compiler can take an escape hatch and the users cannot.

                                                                                                                                                                2. 2

                                                                                                                                                                  Should it be considered a production-ready tool just by virtue of not having very frequent releases? Or should it be regarded as an incomplete toy language

                                                                                                                                                                  I always struggle with this line of questioning because “incomplete and broken” describes pretty much all of the web platform in the sense that whenever you do non-trivial things, you’re going to run into framework limitations, bugs, browser incompatibilities and so on.

                                                                                                                                                                  All you can do is evaluate particular technologies in the context of your specific projects. For certain classes of problems, Elm works well and is indeed better than other options. For others, you’ll have to implement workarounds with various degrees of effort. But again, I can say the same thing for any language and framework.

                                                                                                                                                                  Is it good that it’s so easy to bump up against bugs and limitations? No. But at least Elm is no worse than anything else.

                                                                                                                                                                  Taking a tangent, the main problem is that Elm is being built on top of the horrifically complex and broken foundation that is the web platform. It’s mostly amazing to me that anything works at all.

                                                                                                                                                                  1. 11

                                                                                                                                                                    Is it good that it’s so easy to bump up against bugs and limitations? No. But at least Elm is no worse than anything else.

                                                                                                                                                                    Having worked with ClojureScript on the front-end for the past 3 years, I strongly disagree with this statement. My team has built a number of large applications using Reagent and whenever new versions of ClojureScript or Reagent come out all we’ve had to do was bump up the versions. We haven’t had to rewrite any code to accommodate the language or Reagent updates. My experience is that it’s perfectly possible to build robust and stable tools on top of the web platform despite its shortcomings.

                                                                                                                                                                    1. 5

                                                                                                                                                                      I have the opposite experience. Team at day job has some large CLJS projects (also 2-3 years old) on Reagent and Re-Frame. We’re stuck on older versions because we can’t update without breaking things, and by nature of the language it’s hard to change things with much confidence that we aren’t also inadvertently breaking things.

                                                                                                                                                                      These projects are also far more needlessly complex than their Elm equivalents, and also take far longer to compile so development is a real chore.

                                                                                                                                                                      1. 6

                                                                                                                                                                        Could you explain what specifically breaks things in your project, or what makes it more complex than the Elm equivalent. Reagent API had no regressions in it that I’m aware of, and re-frame had a single breaking change where the original reg-sub was renamed to reg-sub-raw in v 0.7 as I recall. I’m also baffled by your point regarding compiling. The way you develop ClojureScript is by having Figwheel or shadow-cljs running in the background and hotloading code as you change it. The changes are reflected instantly as you make them. Pretty much the only time you need to recompile the whole project is when you change dependencies. The projects we have at work are around 50K lines of ClojureScript on average, and we’ve not experienced the problems you’re describing.

                                                                                                                                                                      2. 2

                                                                                                                                                                        I think the ease of upgrades is a different discussion. There is a tool called elm-upgrade which provides automated code modifications where possible. That’s pretty nice, I haven’t seen a lot of languages with similar assistance.

                                                                                                                                                                        My point was, you cannot escape the problems of the web platform when building web applications. Does ClojureScript fully insulate you from the web platform while providing all of its functionality? Do you never run into cross-browser issues? Do you never have to interoperate with JavaScript libraries? Genuinely asking - I don’t know anything about ClojureScript.

                                                                                                                                                                        1. 3

                                                                                                                                                                          My experience is that vast majority of issues I had with the web platform went away when my team started using ClojureScript. We run into cross-browser issues now and then, but it’s not all that common since React and Google Closure do a good job handling cross-browser compatibility. Typically, most of the issues that we run into are CSS related.

                                                                                                                                                                          We interoperate with Js libraries where it makes sense, however the interop is generally kept at the edges and wrapped into libraries providing idiomatic data driven APIs. For example, we have a widgets library that provides all kinds of controls like data pickers, charts, etc. The API for the library looks similar to this to our internal widgets API.

                                                                                                                                                                          1. 1

                                                                                                                                                                            Sounds like a great development experience!

                                                                                                                                                                            Let me clarify my thinking a bit. For a certain class of problems, Elm is like that as well. But it certainly has limitations - not a huge number of libraries etc.

                                                                                                                                                                            However, I think that pretty much everything web related is like that - limitations are everywhere, and they’re much tighter than I’d like. For example, every time I needed to add a date picker, it was complicated, no matter the language/framework. But perhaps your widgets library has finally solved it - that would be cool!

                                                                                                                                                                            So I researched Elm and got a feel for it’s limitations, and then I could apply it (or not) appropriately.

                                                                                                                                                                            I would agree, however, that the Elm developers have a bit of a hardline approach to backward compatibility. Perhaps there is a misunderstanding around the state of Elm - ie whether it’s still an experiment that can break compatibility or a stable system that shouldn’t.

                                                                                                                                                                            I’m not sure how I feel about backward compatibility. As a user, it’s very convenient. As a developer, it’s so easy to drown in the resulting complexity.

                                                                                                                                                                            1. 4

                                                                                                                                                                              Yeah, I agree that the main question is around the state of Elm. If the message is that Elm isn’t finished, and don’t invest into it unless you’re prepared to invest time into keeping up, that’s perfectly fine. However, if people are being sold on a production ready language that just works there appears to be a bit of a disconnect there.

                                                                                                                                                                              It’s obviously important to get things right up front, and if something turns out not to work well it’s better to change it before people get attached to it. On the other hand, if you’re a user of a platform then stability is really important. You’re trying to deliver a solution to your customers, and any breaking changes can become a serious cost to your business.

                                                                                                                                                                              I also think it is important to be pragmatic when it comes to API design. The language should guide you to do things the intended way, but it also needs to accommodate you when you have to do something different. Interop is incredibly important for a young language that’s leveraging a large existing ecosystem, and removing the ability for people to use native modules in their own projects without an alternative is a bit bewildering to me.

                                                                                                                                                                      3. 8

                                                                                                                                                                        To me the problem is that Elm is not conceptually complete. I listed those issues specifically because they’re both things that the compiler and the core libraries can do internally, but the users of the language cannot.

                                                                                                                                                                        But at least Elm is no worse than anything else.

                                                                                                                                                                        No, Elm is a language, and not being able to do things in a language with so few metaprogramming capabilities is a pretty big deal compared to a missing feature in a library or a framework, which can easily be added in your own code or worked around.

                                                                                                                                                                        1. 1

                                                                                                                                                                          But how is this different from any other ecosystem? The compiler always has more freedom internally. There are always internal functions that platform APIs can use but your library cannot. Following your logic, we should condemn the Apple core APIs and Windows APIs too.

                                                                                                                                                                          1. 4

                                                                                                                                                                            No, what I meant is that the core libraries use their “blessed” status to solve those problems only for themselves, thus recognizing that those problems effectively exist, but the users aren’t given any way to deal with them.

                                                                                                                                                                            1. 2

                                                                                                                                                                              But there are actually solutions on offer: ports and custom elements. What’s wrong with using them?

                                                                                                                                                                              1. 5

                                                                                                                                                                                Ports are very limiting and require much more work to set up than a normal library, and I haven’t used custom elements so I can’t speak for those.

                                                                                                                                                                                There’s also no workaround for the lack of ad-hoc polymorphism. One of the complaints I hear the most about Elm is that writing json encoders and decoders is tedious and that they quickly become monstrously big and hard to maintain; often the json deserialization modules end up being the biggest modules in an Elm project.

                                                                                                                                                                                This is clearly a feature the language needs (and already uses with some compiler magic, in the form of comparable, appendable, and so on).

                                                                                                                                                                    2. 2

                                                                                                                                                                      I was hoping to read other points of view on that matter, thanks for taking the time writing down yours!

                                                                                                                                                                    1. 4

                                                                                                                                                                      I know it’s easy to be in a constant state of rage at Uber, and this news makes it extremely easy to pile on. An innocent person died here, at the fault of a team of engineers attempting to something incredibly difficult. I know for sure that this will bring up (and has already, I’m sure) talking head discussions on ethics of AI, who will be charged (why/why not), and tons more litigation and law suits. But, let’s not forget to sympathize with the engineering team here, as well. This has to be the worst feeling ever, and it could have happened to any of us—it had to happen to someone.

                                                                                                                                                                      My condolences to the innocent pedestrian’s family and friends. Also, my condolences to the team who will carry this loss on their sleeve for the rest of their lives.

                                                                                                                                                                      1. 2

                                                                                                                                                                        It seems like you haven’t read the article very carefully.

                                                                                                                                                                        1. You completely forgot to mention the operator behind the wheel - If anyone, that person will most likely be charged and, regardless of the verdict, carry it for the rest of their life.

                                                                                                                                                                        2. From https://www.sfchronicle.com/business/article/Exclusive-Tempe-police-chief-says-early-probe-12765481.php:

                                                                                                                                                                        … it’s very clear it would have been difficult to avoid this collision in any kind of mode (autonomous or human-driven) based on how she came from the shadows right into the roadway, …

                                                                                                                                                                        … I suspect preliminarily it appears that the Uber would likely not be at fault in this accident, either, …

                                                                                                                                                                        Sylvia Moir, police chief in Tempe, Arizona

                                                                                                                                                                        1. 9

                                                                                                                                                                          Two things.

                                                                                                                                                                          First, the operator is the one person that can hardly be blamed. The idea that a car can drive itself and someone will step in when something goes wrong is fundamentally flawed. Engineers have known about the fact that this doesn’t work for many decades. Understanding what happens at the point of handoff and how long it takes is a fundamental part of aircraft safety and CRM. It takes humans time to asses a situation and step in to take control.

                                                                                                                                                                          Second, police often blame victims in car crashes. That’s in part why so few ever get prosecuted and the situation doesn’t change. I’ll believe it when Uber releases video of what happened.

                                                                                                                                                                          1. 1
                                                                                                                                                                            1. You completely forgot to mention the operator behind the wheel - If anyone, that person will most likely be charged and, regardless of the verdict, carry it for the rest of their life.

                                                                                                                                                                            Presumably the operator is part of the engineering team, no? I’m not a District Attorney, or an attorney, or even a law enforcement officer. Therefore, I’m unable to comment on whether or not the operator will be charged, if it makes sense to charge this person, or if we’ll find that Uber put on the road a car that was not street legal, which contributed to it.

                                                                                                                                                                            Please don’t assume I didn’t read carefully. I tried to choose my words carefully in order to not speculate on the details of an on-going investigation.

                                                                                                                                                                            1. … it’s very clear it would have been difficult to avoid this collision in any kind of mode (autonomous or human-driven) based on how she came from the shadows right into the roadway, …

                                                                                                                                                                            Exactly. This makes the investigation all that more important. Maybe no one will be charged because investigators will rule it an accident based purely on the fact that, autonomous or not, it was unavoidable based on the pedestrian’s actions.

                                                                                                                                                                            1. 1

                                                                                                                                                                              I think your second point raises an interesting issue. It may have been difficult for a human driver to see this person, but from the information given and all the pictures I’ve seen, it shouldn’t have been difficult for an autonomous driver to see them using different sensors (like depth or IR).

                                                                                                                                                                              It shouldn’t have been speeding and it should have slowed down further or changed lanes when it saw that it was coming up on a pedestrian in the median.

                                                                                                                                                                              This is the second incident I know of where an autonomous car has got into trouble, in part, by mimicking stupid human behavior. We have the technology to avoid things like this, and the standard for computer drivers need to be significantly higher than the standard for humans. The NTSB needs to get these things off the road until they’re properly tested.

                                                                                                                                                                            2. 1

                                                                                                                                                                              The fault is actually in the driver, who was instructed to be alert and keep both hands at the wheel at all times. Uber should not have released this obviously and they should get shit for it but I think until there’s nobody behind the wheel the responsibility of any accident falls on the driver, just as it does with planes presently.

                                                                                                                                                                              1. 7

                                                                                                                                                                                The fault lies with the people that put the driver there. It’s beyond comprehension that they would rely on a safety driver. We’ve known for decades that humans cannot effectively monitor a system that’s mostly reliable. The fact that this cannot be done goes back to Kibler (1965), was already understood by Bainbridge (1983), and by Molly & Parasuraman (1995) there was extensive research digging deep into why people are unable to do this and how to design environments where they can.

                                                                                                                                                                                It is irresponsible of Uber/Waymo/GM and all of the manufacturers to put people in an impossible situation.

                                                                                                                                                                                1. 1

                                                                                                                                                                                  Apparently according to reports it required intervention roughly every mile. I do agree there should be laws against putting such a weak system on the road. It should be able to drive unassisted at least as well as a human driver before we put humans behind the wheel, but after that point the driver should be culpable for failing to pay attention. Especially if the driver were for example watching a feature length film in the drivers seat.

                                                                                                                                                                                  1. 2

                                                                                                                                                                                    If a company knowingly puts you in an impossible situation where you cannot possibly do a task safely without injuring yourself or others they are generally liable, not you. Unless for example, you’re a professional engineer in which case you have a certain responsibility to inform yourself and say no. Those poor drivers don’t know the research behind visual attention, automation, and fatigue. It feels very unfair to prosecute them for doing their jobs, that they have been told they can do, to the best of their abilities, when they’ve been set up for failure.

                                                                                                                                                                                    1. 1

                                                                                                                                                                                      I completely agree with what you said here.

                                                                                                                                                                                      Now, in retrospect, don’t you think that without such an antropomophic language selling “intellingense” and “learning” of machines, Uber (and Google, and Tesla) would have had an harder time to put such cars on the road?

                                                                                                                                                                                      This language is dangerous for each person who do not understand the math and inner working of them: they can be manipulated too easily.

                                                                                                                                                                                2. 1

                                                                                                                                                                                  … it’s very clear it would have been difficult to avoid this collision in any kind of mode (autonomous or human-driven) based on how she came from the shadows right into the roadway, …

                                                                                                                                                                                  It sounds plausible that autonomous or not, this may have happened. I don’t want to get into an argument over an investigation that I don’t have any insight into – I’d only be able to speculate, as would you.