1.  

    I have a big problem there: I don’t dislike programming languages…

    1. 3

      Mercurial is the only thing I use that depends on Python 2. I guess git would be the only way to go then.

      1. 3

        Python 3 support is in Beta, though.

        https://www.mercurial-scm.org/wiki/Python3

      1. 40

        Sorry for the grumpyness, but:

        I’m getting more and more convinced that in general programmers should not try satire nor rants.

        This is as bland as it gets, each argument are the cookie-cutter arguments made pro and con all the languages since their inception. There’s not a little bit of creativity and there’s not a bit of insight to be had.

        You could delete it and nothing of value is lost.

        I’m dead sure this article would not be spread if it weren’t published under a big name.

        1. 14

          Sometimes the resulting discussion is interesting. I learned my understanding of 100% pure differs from that of Haskell.

          1. 16

            I’m sorry you didn’t like it. I didn’t write it to “spread” it, though, I just wrote it because I wanted to. Am I not allowed such things because my blog posts frontpage on Lobsters too often? I didn’t submit this here, nor anywhere else.

            And for the record, I do think that there is value in all programmers being able to briefly summarize the advantages and drawbacks of a variety of technologies like this. This kind of thinking can help steer your judgement when starting new projects, and extends past languages and into operating systems, architectures, frameworks, etc, and is an essential kind of thinking for project design.

            1. 15

              The curse of popularity. No fun allowed.

              1. 5

                I do think that there is value in all programmers being able to briefly summarize the advantages and drawbacks of a variety of technologies like this.

                That’s great when you’re writing from a place of experience as you are for most of your post. The problem is the small bits where you aren’t, which you included presumably for completeness sake.

                1. 1

                  haters gonna hate. I guess if you just put a disclaimer that it is satire and opinion.

                2. 2

                  dead sure this article would not be spread if it weren’t published under a big name.

                  Not true, I wrote a similar one and it was up voted too. Hating on C++ is just lots of fun for everyone. C++ is a big boy and can handle it.

                  I’m getting more and more convinced that in general programmers should not try satire nor rants.

                  Hey, let’s not be ‘jobist’, SirCmpwn may be a dirty programmer, but he is also an entrepreneur and community manager too. Let’s not let those jobs have fun either.

                1. 9

                  Does anyone else think this announcement is written using unusually simple English prose? It has a sort of Simple English Wikipedia vibe to it.

                  1. 41

                    Python has a massive user base, many for whom English is not their first language. Making this as clear and unambiguous as possible is good.

                    1. 9

                      That’s one reason I advocate for plain English in business (esp support/docs/training) and government (esp anything mandatory). It also helps the illiterate and people with bad memory that forget uncommon words.

                      1. 11

                        Applicable: Native English speakers are the world’s worst communicators

                        often talk too fast for others to follow, and use jokes, slang and references specific to their own culture

                        This can even be a problem among English speaker. I was meeting this fella from NYC a few weeks ago via couchsurfing, and told him via WhatsApp that I’d join him for the craic after getting back from the chipper. He had no idea what I was on about. English is tricky because there are so many variants, and once you get in to the habit of using a regional variant of it, it’s hard to get rid of that.

                        1. 10

                          Applicable: Native English speakers are the world’s worst communicators

                          More accurate title: “Native English speakers are worse at communicating with ESL folk than ESL folk are at communicating with other ESL folk, in English.”

                          Like c’mon it’s not like English is the only language with slang

                          1. 1

                            Did he ask if there was chance for a shift? (… in your diction?)

                      2. 14

                        What language would you expect? It’s specifically meant for all users, including those that “just use” Python 2.

                        I think it is very clear (except the word “sunsetting”, which is worst of US marketing speak and is not understandable to many second language speakers).

                        1. 3

                          I believe you meant to write “sunsetting”. I do agree that “subsetting” is hard to understand 😉

                          1. 8

                            Correct. lobste.rs is pretty usable on mobile, but that also makes it vulnerable to autocorrect :D.

                        2. 11

                          They’re trying to communicate with people who are still using Python 2 in 2019.

                          1. 2

                            I bet there are a lot. The “tech industry” is lead by people following closely the upstream projects, but a long long tail of activities just getting stuff done imitating the others follow, and changing that will be long.

                            There are also many code bases in production to convert. There is a tendency to not daring to touch to anything in production if it works, even though maintenance is required.

                          2. 5

                            A lot of people don’t have the necessary attention span time to be able to read long blog posts, announcements or messages. They refer to such messages as “it doesn’t tell about anything”, “meaningless” and “they don’t want to waste time”. I think by using simplest language possible, they’re trying to embrace the short-attention-span people so that they’ll be able to actually read and “digest” the message.

                            I’ve used “they”, but I know I’m not separated from this issue myself. Many times when I’m stumbling over some article in English, I’m discouraged by the overly flowery language, which I often can’t easily understand (as I’m not a native speaker). So I perfectly understand why the Python note uses Simple English mode :)

                            1. 4

                              It’s not you, I had the same reaction. From the tone of the article my impression was that their target audience is four years old. I get that shrouding a simple message in complicated verbiage is a great way to alienate readers but going to far in the opposite direction makes it sound condescending which is possibly worse. But in this case I’m sure that was not the intent of the author, my assumption is that English is not the writer’s first language and they were trying to be very sure they didn’t make anything unclear or misleading. Sometimes my own writing turns into this after I’ve rewritten it 20 times.

                              1. 6

                                To quote my mentor at Amazon: “Communication is impossible”.

                                Have you ever watched a really painful exchange between a non native English speaker and well meaning but frustrated people on a chat channel trying to help?

                                The non native English speaker asks a question in the best way they can, using imprecise wording and breaking every rule in the English language because, to non speakers, they make no sense :)

                                So yeah, this announcement is written in a way that optimizes for minimizing mis-understanding, and in this context I see that as the right choice, and if I’m reading you right, so do you :)

                              2. 1

                                I’m guessing it’s because they wrote sentences starting with And and But a fair bit, which is potentially easy to read but makes all of the sentences seem really short. It’s a little strange, but much better than paragraph-length sentences.

                              1. 2

                                It’s kinda weird that one of the new “features” is the ability to run as a daemon is being removed

                                1. 4

                                  Why? The reasoning is sound, daemonising is much better handled by specialised tooling instead of implemented in every program.

                                  1. 2

                                    “All programs should run in the foreground” is one of the few times DJB was right

                                    1. 1

                                      Major versions can have breaking changes. It was worth explaining this one as part of the announcement

                                    1. 4

                                      Still on holidays in Canada and I can tell you, my plan of staying away from the computer is working out great. 😊

                                      Flying home tomorrow.

                                      1. 3

                                        I love this. I love this so much. The chat even scrolls from top to bottom, I thought they had made a mistake and scrolled there myself. It’s like they said fuck it to all the rules.

                                        1. 1

                                          Maybe it’s so old that there wasn’t a well established chat ordering back then. I mean we ended up with email clients standardizing on top-posting.

                                          1. 2

                                            I used to administrate a metal chat and a bulletin board back in 1998-2003 (then moving on to getting a modbit in a Ruby Forum and so on) and the chat had top to bottom. It was quite usual.

                                            In any case anyone ever wonders why I got this very community drift to interacting with technology: it’s my path and the by and large, the community has treated me well for it.

                                        1. 8

                                          The changes in Scala 3 are so dramatic that all Scala developers will need to be re-trained and all codebases will need to undergo a migration.

                                          Is there any source to support such claim? I briefly looked at Dotty’s website but apart from a few dropped features didn’t find anything that alarming.

                                          Blog written by Odersky claims that:

                                          It’s worth emphasizing that Scala 2 and Scala 3 are fundamentally the same language. The compiler is new, but nearly everything Scala programmers already know about Scala 2 applies to Scala 3 as well, and most ordinary Scala 2 code will also work on Scala 3 with only minor changes.

                                          Heck, further down he even claimed that it’d be possible to use Scala 2 artifacts, use -language:Scala2 option that “lets it compile most Scala 2 code and at the same time highlights necessary rewritings as migration warnings” or even that “compiler can perform many of the rewritings automatically using a -rewrite option”.

                                          My judging is that the tone of the article was unnecesarily dramatic and unless some crucial information is hidden from project’s website and Odersky’s blogpost, I really do understand why Scala dev’s would perceive it as toxic trolling or FUD. It’s generally good to avoid overly emotional people who fail to disclose sources for their statements.

                                          1. 0

                                            I think the author is spot-on with his article.

                                            Scala devs have mastered the ability to promise things and then do a switcheroo and reinterpret what they said in the most restrictive way until they can claim they “never said that”. Also, claiming that things one doesn’t like hearing are “toxic” or “FUD” is Scala community management 101.

                                            Like when they tried to make it appear as if Scala 3 was a smaller, simpler language, when it’s painfully obvious that it’s not true. I’m just waiting for them to claim “that this was only talking about our (useless) DOT calculus, people must have misunderstood us!”.

                                            Speaking from my personal experience, Martin saying $thing does not convey whether they are in fact true or not, only that saying $thing was most convenient at that point in time.

                                            1. 7

                                              All I ask for is some evidence. I could easily go and make ill-minded fake accusations about virtually any project and, provided the community is large enough, there would probably be a handful of people agreeing with me. I’m definitely not saying that’s the case here, but at the same time would much rather construct my own opinion instead of just adopting one.

                                              It all boils down to providing some verifiable statements – most preferrably with sources. After making sure these statements are correct (or at least probably correct, depending on how much I care), I can make my own judgement.

                                              Since I didn’t get a single example of “a dramatic change” that would require “all Scala developers to be retrained and all codebase to undergo a migration”, I tried to search them up myself. What I found seems incompatible with Scala 2, but not really “dramatic” and recquiring a complete retraining.

                                              Now you are saying that Martin Odersky is not trustworthy – again without a single example that I could look up and verify. Since Odersky isn’t the one starting the emotional battle here and I value him for his previous work, I trust him more.

                                              So far the only thing I learned is that some people have negative feelings about Scala and its community. To convince me to join them, it’d take a whole lot more than that.

                                              PS: I learned a little bit of Scala a while back and always thought it was an interesting and in a way a really nice language, but at the same time was somewhat sceptical about using it for larger projects. I generally tend to think that overly complex languages are a source of pain in a team work.

                                              1. 1

                                                Speaking from my personal experience, Martin saying $thing does not convey whether they are in fact true or not, only that saying $thing was most convenient at that point in time.

                                                I have a hard time in figuring out what the problem is? Obviously, it’s not unusual to say different things on different occasions, in several levels of detail. Or things may have been true in the past, but are not now. Are you saying that Martin actively says wrong things?

                                                1. 5

                                                  I once tried to talk to him about wanting to work on improving the Scala websites’ documentation for beginners. His response was that it wasn’t necessary because “everyone already knows Scala”.

                                                  After multiple other efforts and offers to help I announced that would give up trying to improve the website if nobody cared.

                                                  That’s when he suddenly claimed that he was happy to receive contributions.

                                                  This caused me to leave Scala, because I’m not willing to be gas lighted in front of a thousand people, and it’s frankly not my problem that he says different things in private and public.

                                                  Then there was the time where he sent an emotional email to my university’s dean about some non-existing thesis, others have spilled some of the beans here.

                                                  1. 1

                                                    Thanks! That clears things up a little for the bystander.

                                                    I heard about the website thing being a regular issue.

                                            1. 3

                                              I’ll spend one day at the Mozilla office in Portland, writing up stuff I heard and wanted to act upon on RustConf.

                                              Tomorrow, I’ll fly to Victoria for a week of holidays.

                                              1. 6

                                                I find it very odd to see “Python3 and Perl6” in one sentence. Python3 has succeeded despite the mismanaged transition—but it’s also far less of a dramatic change than Perl6. Not sure about Scala 3, I haven’t looked.

                                                1. 4

                                                  Python 3 is doing quite well, but the other shoe - of actually ceasing to support python 2 - has not yet dropped. We’ll see what happens then.

                                                  1. 3

                                                    Legacy systems are the norm. The new one runs in parallel instead of replacing the old one given its many users and investment. That both are doing well is probably a good thing in light of this.

                                                    1. 4

                                                      Sure. Which is why python 2 ceasing to receive even security patches is going to prompt some responses.

                                                      We’re either going to see pushes to migrate (what guido and the python dev gang expect) or some efforts to continue running those python2 codebases with security patches (maybe a switch to pypy and continued community support of that project). The latter has the potential to reshape the politics of the python community.

                                                      1. 3

                                                        “dev gang” sounds weird? Is that really a term that is used in the python community?

                                                        The Ruby community has found solutions to that. There’s specialised agencies keeping old codebases secure for old Rails and Ruby versions against reasonable fees. It’s infeasible for community maintainers to support legacy.

                                                        On the other hand, as rough as it was, the MRI team has also made sure that there’s feasible migration paths, so that you can make a reasonable decision whether to put money/effort into migration or paid maintenance.

                                                        1. 1

                                                          I see “python-dev” used pretty frequently in the Python community to refer to the language developers (as distinct from library developers or the wider community) — it’s a reference to this mailing list.

                                                        2. 2

                                                          The question is really about who’ll be providing the support. There is no question in my mind that there will be Python 2 updates following the drop dead date for support. The question is whether the Python core team will decide to push the updates, have support forked by another community, or whether vendors (ActiveState, RedHat, etc.) will be the ones driving the support. The thinking seems to be that it’ll be the latter since open source projects have much less reason to get stuck than companies. That said, I’m sure the Python core team would consider pushing an update for some critical (security) issue, if it was decided in the best interests of the community and industry. I doubt that scenario will arise though, but it’s a possibility for a well run and organized community to consider.

                                                          Where does your understanding of Guido’s expectations come from? I’ve been present at all PyCons since 2008, except two in recent years. I’ve never seen explicit expectations like the ones you describe from Guido, or others in leadership positions. They have been pretty pragmatic with their understanding of how any Python 2 to 3 migration will happen with an understanding that eventually it’ll make sense to sunset Python 2. The wider Python and online communities however have understood or listened to little of what has been said. That extends to async, and many other developments in the language/runtime over the past decade.

                                                  1. 4

                                                    Rust gets similar complaints about compile times and complexity, but its adoption seems to be on the S-curve:

                                                    https://www.openhub.net/languages/compare?language_name[]=rust&language_name[]=scala&measure=contributors

                                                    1. 5

                                                      Rust has some unique selling points, Scala doesn’t.

                                                      1. 2

                                                        This has been my general feeling with Scala. I have worked through some Scala books 2008-2012 and wrote some Scala programs for internal use. I also encountered quite a lot of student-submitted Scala code in one of my courses a few years back, because a colleague had taught a Scala seminar. To me Scala resembled C++: a lot of accidental complexity, trying to be everything to everybody, and long build times without the main benefit of C++, namely performance. I think the only minor benefit was that gives access to JVM ecosystem (if you need that), but for the people who just wanted a better Java there is Kotlin and Java >= 8 now.

                                                        1. 3

                                                          True.

                                                          The only sad thing is that – when only looking at the common language subset shared between Kotlin and Scala – Scala is substantially better than Kotlin.

                                                          I’m back to Java, and simply stopped hoping for a high-quality language on the JVM.

                                                          1. 2

                                                            I definitely agree about Kotlin. I think the most appealing part is the when keyword, which is almost what you would expect from pattern matching, except it isn’t.

                                                            What other languages have you tried on the JVM? I’m curious about you experience with Clojure, if any.

                                                      2. 4

                                                        Scala can’t match Rust’s speed, though.

                                                        1. 21

                                                          That and Rust’s core team are deliberately trying to avoid the biggest problems this blog post mentioned:

                                                          Rust will never have a breaking migration like Dotty or Python 3 (or, $DIETY forbid, Perl 6). Rather than fixing soundness holes by releasing an entirely new language, Rust just ships both verification passes and issues warnings if their results differ, until eventually the red line is drawn and NLL is permanently shipped. And rather than fixing papercuts by releasing a whole new language, they just use “edition numbers,” basically the same thing as use strict.

                                                          Also, the thing where Scala is supposed to “hand over the improvement process to the industry” is exactly what Mozilla already did. I only counted two Mozilla employees on the core team, with a lot of others employed by random companies like NPM, CloudFlare, Pingcap, Integers32 (which, being a Rust consultancy, really isn’t “random”). Other teams have members from Microsoft, Parity, Chef, Ferros systems (the other Rust consultancy), Diffeo, Wayfair, RMS… While Mozilla seems to have more employees than anyone else still, I’m pretty sure they’re less than half (it’s hard to be sure, because some team members don’t list their employer at all, so it’s hard to tell if they’re unemployed, academically employed, or employees of a company that didn’t fill it in on their GitHub profile).

                                                          1. 4

                                                            Thanks for the writeup! I haven’t counted recently, but already at RustFest Kyiv 2017, the quoted number of contribution Mozilla vs. non-Mozilla was <25% Mozilla. I’m sure that stayed the same.

                                                            BTW, there’s also members of Ferrous Systems in core (me), but not by virtue of being employed at Ferrous. Core team is picked by involvement in parts of the project and willingness to do meta things (like legal, phew), Carol from integer is also one of the core maintainers of crates.io, Ashley is very active in the WASM side, Steve is docs team, etc.

                                                        2. 0

                                                          That graph is irrelevant, it appears to be tracking changes to the language itself

                                                        1. 10

                                                          I write a fair bit of Rust and have mostly ignored binary size as a thing to optimise for so far but I’d like to learn more. Assuming the extra size ends up as executable code and not just stuff in the data segment, I’m curious, what are the drawbacks to a bigger binary/more generated code? One possible reason that come to mind are less efficient use of CPU caches if code is more “spread out”. Are there RAM consumption consequences of a larger binary?

                                                          1. 15

                                                            There’s also the wasm case, which is going to become increasingly important.

                                                            The most interesting single feature of the feedback from this post is the extremely wide variance in how much people care about this. It’s possible I personally care more just because my experience goes back to 8 bit computers where making things fit in 64k was important (also a pretty long stretch programming 8086 and 80286). Other people are like, “if it’s 100M executable but is otherwise high quality code, I’m happy.” That’s helping validate my decision to include the localization functionality.

                                                            1. 5

                                                              My experience with Rust binary size has let me to assume that it’ll be a non-starter in WASM, which is a pity. It’s going to be hard to compete with JS for startup time.

                                                            2. 5

                                                              There’s a finite-size instruction cache. You don’t have to fit the whole program in it, but hot-looping tasks should.

                                                              At least for inlining, the compiler is supposed to understand the tradeoff between code size and performance.

                                                              The biggest bloat potential comes from large generic functions used with many different parameters. For each type you get new copy of the function, so you may end up with 8 versions of the same function. cargo-bloat is useful for finding these.

                                                              Libstd has this pattern:

                                                              fn generic(arg: impl AsRef<Foo>) {
                                                                  non_generic(arg.as_ref());
                                                              }
                                                              
                                                              fn non_generic(arg: &Foo) {…}
                                                              

                                                              this way even if you call generic with 10 different types, you still get 1 non_generic copy, and the rest will probably inline down to nothing.

                                                              1. 5

                                                                I often heard critique for C++ that classes are “slow” because of dynamic dispatch. Not sure if it’s true problem. Rust does monomorphization by default and it’s critiqued for bloated binaries. It’s not easy tradeoff. Also, it looks like dynamic dispatch with dyn trait objects is considered somewhat “non-idiomatic”.

                                                                I think at-runtime features such as trait objects and Rc should be more widely used, at least in application code.

                                                                1. 6

                                                                  Exactly. Rust has the reverse problem. There’s a hyperfocus on never doing dynamic dispatch and I feel it’s underused. I have yet to see a performance problem directly related to trait object outside of a narrow set up programs, mainly synthetic benchmarks.

                                                                  Also, some libraries tend to be hypergeneric, which only allows you to roll out the code when assembling the main program, hampering early compilation in crates.

                                                                2. 1

                                                                  The biggest bloat potential comes from large generic functions used with many different parameters.

                                                                  In this case is there a drawback aside from the larger binary? I.e. is there a runtime performance impact of the larger binary?

                                                                  1. 5

                                                                    If every single program on a system requires hundreds of megabytes things just become unwieldy. Cutting waste is good, pointlessly large programs waste bandwidth everywhere from disks, ram and internet.

                                                                    Ever wonder why windows update takes minutes instead of seconds? I often do…

                                                                    1. 4

                                                                      Cool, I can get behind that. Just trying to work out if the primary motivation is disk use or something else.

                                                                      1. 3

                                                                        Disk, but also things like your CPU’s instruction cache is a scarce resource. You want a hot loop’s instructions to fit entirely in it, so each iteration of the loop doesn’t involve re-pulling the loop instructions from a slower level of memory.

                                                                        Excessive bloating from a lot of calls to different versions of monomorphized functions and inlining could potentially mean that that kind of important code won’t fit in the cache.

                                                                    2. 1

                                                                      I haven’t looked for or seen measurements showing (or not showing) this, but one assumes that this could result in more frequent instruction cache misses if you are commonly using the different monomorphized versions of the generic function.

                                                                1. 6

                                                                  The number of times I’d wished I had this feature on Travis.

                                                                  Instead you just end up blindly pushing changes to the branch in the hope that it works :P

                                                                  1. 4
                                                                    1. 3

                                                                      Only on Travis-ci.com (the paid version), and not Travis-ci.org (the free version).

                                                                      1. 4

                                                                        sr.ht is also a paid service, right?

                                                                        1. 4

                                                                          It’s up to you whether to pay or run the exact same free software on your own infra.

                                                                          1. 2

                                                                            Is it easy to run on your own? That’s kind of cool. I may pay them anyway but still run it myself.

                                                                            1. 9

                                                                              https://man.sr.ht/installation.md

                                                                              Reach out to the mailing list if you run into trouble :)

                                                                              1. 1

                                                                                Wow, cool! Thanks :)

                                                                            2. 1

                                                                              You can also run travis-ci.org on your own infra (I currently do this) but there isn’t a lot of info about it.

                                                                          2. 3

                                                                            The trick is that for public repos, you have to email support: https://docs.travis-ci.com/user/running-build-in-debug-mode/#enabling-debug-mode

                                                                            1. 1

                                                                              Weird… I guess that they’re trying to prevent wasted containers by adding manual process in the middle?

                                                                              1. 2

                                                                                It’s a security risk, especially for public repos.

                                                                                1. 2

                                                                                  Eeeek, that’s rough. builds.sr.ht’s SSH access uses the SSH keys we already have on your account for git authentication et al.

                                                                                  1. 1

                                                                                    You get that from Github, too. But I also think it doesn’t help, because GH projects are liberal with adding people to orgs/repos and while they cam be grouped, there’s no way to assign structures roles. GH as an identity provider is mediocre at best.

                                                                                  2. 1

                                                                                    Like, in terms of things which they may do in the shells, DDoSing by creating too many, etc? They use your SSH key from GitHub to prevent others from SSHing in, right?

                                                                                    1. 4

                                                                                      They use your SSH key from GitHub to prevent others from SSHing in, right?

                                                                                      Not AFAIR. It gives a temporary login/password in the build log (which is public). And anyone who logs in can see the unencrypted secrets (e.g. API keys used for pushing to GitHub).

                                                                                      1. 1

                                                                                        oooooooh… yipes. Super dangerous. CircleCI uses SSH keys to improve on this.

                                                                              2. 1

                                                                                Aren’t they doing some funky reorganization to eliminate the split? I haven’t looked closely so I might be wrong.

                                                                              3. 2

                                                                                I guess I’ve just been too cheap to pay then ;)

                                                                              4. 1

                                                                                This feature is on Travis, but their new configuration API is so excruciatingly painful and lacking of reasonable documentation that it fails to help when it’s really needed.

                                                                                1. 1

                                                                                  With Gitlab you can debug CI stages on your machine by starting a local Gitlab Runner.

                                                                                  1. 31

                                                                                    My position has essentially boiled down to “YAML is the worst config file format, except for all the other ones.”

                                                                                    It gets pretty bad if your documents are large or if you need to collaborate (it’s possible to have a pretty good understanding of parts of YAML but that’s not always going to line up with what your collaborators understand).

                                                                                    I keep wanting to say something along the lines of “oh, YAML is fine as long as you stick to a reasonable subset of it and avoid confusing constructs,” but I strongly believe that memory-unsafe languages like C/C++ should be abandoned for the same reason.

                                                                                    JSON is unusable (no comments, easy to make mistakes) as a config file format. XML is incredibly annoying to read or write. TOML is much more complex than it appears… I wonder if the situation will improve at any point.

                                                                                    1. 21

                                                                                      I think TOML is better than YAML. Sure, it has the complex date stuff, but that has never caused big surprises for me (just small annoyances). The article seems to focus mostly on how TOML is not Python, which it indeed is not.

                                                                                      1. 14

                                                                                        It’s syntactically noisy.

                                                                                        Human language is also syntactically noisy. It evolved that way for a reason: you can still recover the meaning even if some of the message was lost to inattention.

                                                                                        I have a mixed feeling about TOML’s tables syntax. I would rather have explicit delimiters like curly braces. But, if the goal is to keep INI-like syntax, then it’s probably the best thing to do. The things I find really annoying is inline tables.

                                                                                        As of user-typed values, I came to conclusion that everything that isn’t an array or a hash should just be treated as a string. If you take user input, you cannot just assume that the type is correct and need to check or convert it anyway, so why even bother having different types at the format level?

                                                                                        Regardless, my experience with TOML has been better than with alternatives, despite its flaws.

                                                                                        1. 6

                                                                                          Human language is also syntactically noisy. It evolved that way for a reason: you can still recover the meaning even if some of the message was lost to inattention.

                                                                                          I have a mixed feeling about TOML’s tables syntax. I would rather have explicit delimiters like curly braces. But, if the goal is to keep INI-like syntax, then it’s probably the best thing to do. The things I find really annoying is inline tables.

                                                                                          It’s funny how the exact same ideas made me make the opposite decision. I came to the conclusion that “the pain has to be felt somewhere” and that the config files are not the worst place to feel it.

                                                                                          I have mostly given up on different config formats and just default to one of the following three options:

                                                                                          1. Write .ini or Java properties-file style config-files when I don’t need more.
                                                                                          2. Write a dtd and XML when I need tree or dependency-like structures.
                                                                                          3. Store the configuration in a few tables inside an RDBMS and drop an .ini-style config file with just connection settings and the name of the config tables when things get complex.

                                                                                          As of user-typed values, I came to conclusion that everything that isn’t an array or a hash should just be treated as a string. If you take user input, you cannot just assume that the type is correct and need to check or convert it anyway, so why even bother having different types at the format level?

                                                                                          I fully agree with this well.

                                                                                        2. 23

                                                                                          Dhall is looking really good! Some highlights from the website:

                                                                                          • Dhall is a programmable configuration language that you can think of as: JSON + functions + types + imports
                                                                                          • You can also automatically remove all indirection in any Dhall code, converting the file to a logic-free normal form for non-programmers to understand.
                                                                                          • We take language security seriously so that your Dhall programs never fail, hang, crash, leak secrets, or compromise your system.
                                                                                          • The language aims to support safely importing and evaluating untrusted Dhall code, even code authored by malicious users.
                                                                                          • You can convert both ways between Dhall and JSON/YAML or read Dhall configuration files directly into a language that supports a native language binding.
                                                                                          1. 8

                                                                                            I don’t think the tooling should be underestimated, too. The dhall executable includes low-level plumbing tools (individual type checking, importing, normalization), a REPL, a code formatter, a code linter to help with language upgrades, and there’s full blown LSP integration. I enjoy writing Dhall so much that for new projects I’m taking a more traditional split between a core “engine”, and then pushing out the logic into Dhall - then compiling it at a load time into something the engine can work with. The last piece of the puzzle to me is probably bidirectional type inference.

                                                                                            1. 2

                                                                                              That looks beautiful! Can’t wait to give it a go on some future projects.

                                                                                              1. 2

                                                                                                Although the feature set is extensive, is it really necessary to have such complex functionality in a configuration language?

                                                                                                1. 4

                                                                                                  It’s worth understanding what the complexity is. The abbreviated feature set is:

                                                                                                  • Static types
                                                                                                  • First class importing
                                                                                                  • Function abstraction

                                                                                                  Once I view it through this light, I find it easier to convince myself that these are necessary features.

                                                                                                  • Static types enforce a schema on configuration files. There is almost always a schema on configuration, as something is ultimately trying to pull information out of it. Having this schema reified into types means that other tooling can make use of the schema - e.g., the VS Code LSP can give me feedback as I edit configuration files to make sure they are valid. I can also do validation in my CI to make sure my config is actually going to be accepted at runtime. This is all a win.

                                                                                                  • Importing means that I’m not restricted to a single file. This gives me the advantage of being able to separate a configuration file into smaller files, which can help decompose a problem. It also means I can re-use bits of configuration without duplication - for example, maybe staging and production share a common configuration stanza - I can now factor that out into a separate file.

                                                                                                  • Function abstraction gives me a way to keep my configuration DRY. For example, if I’m configuring nginx and multiple virtual hosts all need the same proxy settings, I can write that once, and abstract out my intention with a function that builds a virtual host. This avoids configuration drift, where one part is left stale and the rest of the configuration drifts away.

                                                                                                  1. 1

                                                                                                    That’s very interesting, I hadn’t thought of it like that. Do you mostly use Dhall itself as configuration file or do you use it to generate json/yaml configuration files?

                                                                                                2. 1

                                                                                                  I finally need to implement Dhall evaluator in Erlang for my projects. I <3 ideas behind Dhall.

                                                                                                3. 5

                                                                                                  I am not sure that there aren’t better options. I am probably biased as I work at Google, but I find Protocol Buffer syntax to be perfectly good, and the enforced schema is very handy. I work with Kubernetes as part of my job, and I regularly screw up the YAML or don’t really know what the YAML is so cutty-pasty from tutorials without actually understanding.

                                                                                                  1. 4

                                                                                                    Using protobuf for config files sounds like a really strange idea, but I can’t find any arguments against it.
                                                                                                    If it’s considered normal to use a serialisation format as human-readable config (XML, JSON, S-expressions etc), surely protobuf is fair game. (The idea of “compiled vs interpreted config file” is amusing though.)

                                                                                                    1. 3

                                                                                                      I have experience with using protobuf to communicate configuration-like information between processes and the schema that specifies the configurations, including (nested) structs/hashes and arrays, ended up really hacky. I forgot the details, but protobuf lacks one or more essential ingredients to nicely specify what we wanted it to specify. As soon as you give up and allow more dynamic messages, you’re of course back to having to check everything using custom code on both sides. If you do that, you may as well just go back to yaml. The enforced schema and multi language support makes it very convenient, but it’s no picnic.

                                                                                                      1. 2

                                                                                                        One issue here is that knowing how to interpret the config file’s bytes depends on having the protobuf definition it corresponds to available. (One could argue the same is true of any config file and what interprets it, but with human-readable formats it’s generally easier to glean the intention than with a packed binary structure.)

                                                                                                        1. 2

                                                                                                          At Google, at least 10 years ago, the protobuf text format was widely used as a config format. The binary format less so (but still done in some circumstances when the config file wouldn’t be modified by a person).

                                                                                                          1. 3

                                                                                                            TIL protobuf even had a text format. It sounds like it’s not interoperable between implementations/isn’t “fully portable”, and that proto3 has a JSON format that’s preferable.. but then we’re back to JSON.

                                                                                                    2. 2

                                                                                                      JSON can be validated with a schema (lots of tools support it, including VSCode), and it’s possible to insert comments in unused fields of the object, e.g. comment or $comment.

                                                                                                      1. 17

                                                                                                        and it’s possible to insert comments in unused fields of the object, e.g. comment or $comment.

                                                                                                        I don’t like how this is essentially a hack, and not something designed into the spec.

                                                                                                        1. 2

                                                                                                          Those same tools (and often the system on the other end ingesting the configuration) often reject unknown fields, so this comment hack doesn’t really work.

                                                                                                          1. 8

                                                                                                            And not without good reason: if you don’t reject unknown fields it can be pretty difficult to catch misspellings of optional field names.

                                                                                                            1. 2

                                                                                                              I’ve also seen it harder to add new fields without rejecting unknown fields: you don’t know who’s using that field name for their own use and sending it to you (intentionally or otherwise).

                                                                                                          2. 1

                                                                                                            Yes, JSON can be validated by schema. But in my experience, JSON schema implementations are widely diverging and it’s easy to write schemas that just work in your particular parser.

                                                                                                          3. 1

                                                                                                            JSON is unusable (no comments, easy to make mistakes) as a config file format.

                                                                                                            JSON5 fixes this problem without falling prey to the issues in the article: https://json5.org/

                                                                                                            1. 2

                                                                                                              Yeah, and then you lose the main advantage of json, which is how ubiquitous it is.

                                                                                                              1. 1

                                                                                                                In the context of a config format, this isn’t really an advantage, because only one piece of code will ever be parsing it. But this could be true in other contexts.

                                                                                                                I typically find that in the places where YAML has been chosen over JSON, it’s usually for config formats where the ability to comment is crucial.

                                                                                                          1. 1

                                                                                                            This is not a tutorial on PBT, but rather a collection of motivating examples. That said, you should be able to follow along without prior knowledge of PBT.

                                                                                                            I’m reading this like it might be best if I did have some background in PBT before coming to the book? If that’s true, what would be a good starting point?

                                                                                                            1. 2

                                                                                                              I personally found that the concept of PBT itself is quite easy to understand and library docs do a good job at explaining. But they often lack deep examples for complex and practical test. So I’d say: go ahead, if the topic is of interest!

                                                                                                            1. 14

                                                                                                              FD: minor contributor here, please read adjusting for my biased enthusiasm but I’m incredibly excited about this!

                                                                                                              This is the first time I’ve enjoyed working with async rust after years of frustration with the ergonomics and lock-in of the old libraries. This is the work of Stjepan Glavina, who has authored some of the high-performance foundations that libraries like rayon and tokio depend on in their most critical hot paths, and his perspectives on sound API design and performance-critical software really came together strongly for this.

                                                                                                              The main punchline: if you’re familiar with the rust standard library, you already know how to use async-std. If multi-hour compiler sparring matches are your thing, you will be sorely disappointed.

                                                                                                              The second punchline: async-task has been able to achieve single-allocation tasks that finally realize the goal set out years ago to achieve a zero-cost async abstraction. Other attempts until now have needed at least two allocations, and involve far more unsafe code. This is a seriously nice foundation to build atop.

                                                                                                              One of the first things people have mentioned to me when I’ve told them that this was coming was concern over fragmentation in the Rust ecosystem. Never fear! This is built in such a way that you can run the futures in a totally runtime-agnostic way, which unfortunately has not been a goal with many existing rust async libraries.

                                                                                                              Once async-await lands on stable, the rust ecosystem is going to begin a great migration away from the combinator-heavy style used until now. As a long-time async Rust skeptic, I finally feel like there’s a way to do asynchronous programming that doesn’t require much thought beyond what I know from the standard library.

                                                                                                              Check it out :D

                                                                                                              1. 5

                                                                                                                There is still a fragmentation: is code async or not.

                                                                                                                My fear would be that most new libraries start to favor being async just to be more ‘flexible’, which actually means they require a runtime and have a less ergonomic coding style even at times when you don’t actually need async.

                                                                                                                For me personally, I like rust because it doesn’t have a runtime and can use it in contexts where that matters.

                                                                                                                1. 2

                                                                                                                  I don’t see your point? That was there before, code was either a mountain future code or green.

                                                                                                                  We actually advocate for measured use of async, we see huge problems with async-only codebases. But we see this as a teaching problem. All of the main authors of async-std are by the way training Rust, so we see ourselves in a great position for “when not to async”.

                                                                                                                  The point behind Rusts async/await support is that it doesn’t mandate a runtime and you can link one if wanted.

                                                                                                                  1. 2

                                                                                                                    The parent comment seemed to be saying there was no fragmentation because you can choose your own runtime.

                                                                                                                    I was saying there is fragmentation because you must choose a runtime to use this code. The amount of fragmentation, or if it is a problem in the long run is something I don’t know. I was just pointing out it exists.

                                                                                                                    Of course, for what it does do, rust async is amazing, and definitely does provide benefit.

                                                                                                                    1. 1

                                                                                                                      To clarify what I meant by fragmentation, I was referring to the existing async rust ecosystem, which async-std takes care to be a team player with by avoiding hard-wired runtime decisions that cause lock-in.

                                                                                                                      You’re right that when you depend on a future, you then additionally need a way to drive it to completion, and that additional complexity needs to be considered in terms of its effect on developer productivity, latency distributions, and throughput for your specific workload on realistic hardware. I’ve long been a harsh critic of what I’ve called “gratuitous asynchronicity” in the rust ecosystem, but a huge part of why I’m excited about async-std is how much lower it makes the costs of using async along each of those vital aspects.

                                                                                                                      1. 1

                                                                                                                        Agreed, async-std itself is a step in the right direction lowering the costs for everyone.

                                                                                                              1. 3

                                                                                                                I’m thinking of redirecting https://cipherli.st/ to the Mozilla generator. Did it once before to the wiki, but that was disliked.

                                                                                                                1. 3

                                                                                                                  Ah, I love cipherli.st! Thanks so much for providing it, it’s been a handy reference on several occasions.

                                                                                                                  The Mozilla generator is good but cipherli.st is more comprehensive.

                                                                                                                  1. 2

                                                                                                                    Quick question for an upcoming project: is there a rather canonical, maintained list of cypher considered “state of the art” that doesn’t come in the form of a webserver config around somewhere?

                                                                                                                    1. 2

                                                                                                                      No! cipherli.st is more comprehensive than Mozilla’s ssl-config, if includes more services (e.g. dovecot, etc)

                                                                                                                      1. 2

                                                                                                                        Disliked by whom? Want me to put you in touch with the author of the config generator?

                                                                                                                        1. 1

                                                                                                                          I like cipherli.st! I’d be sad if it just would be a redirect to the Mozilla generator.

                                                                                                                        1. 2

                                                                                                                          @skade, are you the author of this?

                                                                                                                          1. 12

                                                                                                                            Somewhat. I’m one of the project managers, I wrote the website, an ample amount of docs, some code and partially ghostwrote the announcement. The implementation is mainly Stjepan Glavina. I was a bit on the edge of marking it is as author, but erred on that side.