1. 5

    Unless you have very specific needs, I feel like the best answer should be; “why not?”. Both languages, (and C#, Java, …) are adequate to build web services. As long as the language is productive to you and your team, this is more important than picking the latest hip language.

    1. 2

      The irony here is we have Kay’s vision of networked objects while also caring deeply about the implementation details of those objects, which, we shouldn’t have to care about.


        … unless you’re the one implementing those details…


      Rust: long compile times. Far and away the biggest problem with Rust. Luckily, I’m not the only one who feels this way, and many people are working on it.

      1. 4

        Wow. I had forgotten what LoZ: ALttP looked like on CRT. Seeing the side by side comparison is pretty incredible. Very nostalgia inducing.

        1. 14

          This is true for any Taylor expansion of any finite function… The exponential is pretty incredible, but not so much because its Taylor expansion behaves like every other Taylor expansion…

          1. 2

            What do you mean by finite? Bounded? Exp isn’t bounded and yet its expansion at any point converges to e^x for all x. But e^(-1/x) (for x > 0, 0 otherwise) is both bounded and smooth yet it’s not analytic, i.e. T[f, 0](x) = 0 for all x.

            1. 1

              Finite just means it never reaches infinity, whereas bounded means it has a real maximum value.

              1. 1

                Silly me

          1. 3

            Finally getting around to releasing (after ~7 weeks of the branch sitting idle) the new scoreboard for my browser-based multiplayer game side project, https://alpha.sneakysnake.io !!!

            Other than a few bug fixes and some metric logging, the last major feature before trying to monetize will be player-entered player names! Any suggestions on how to blacklist bad-words? I would like the game to be family friendly.

            1. 3

              At first glance, this looks similar to https://cycle.js.org which has a similar concept of drivers. I’ve written one app with Cycle, and I really enjoyed the experience. The biggest issue I found was that some DOM APIs really don’t fit the functional reactive model. What is extremely nice about this model is that all data-flow is explicit and “static”: your code really becomes a description of all the ways that data flows around the app, which is really cool.

              What I don’t get is why this library needs to define its own view templating language, as it seems only superficially different from say JSX? Haven’t looked very deep so I don’t know if it’s essential. This is something that Cycle is very unopinionated about, which is nice.

              1. 1

                Cycle.js looks super interesting. But it looks like it’s at least 10x the size of this. So even if it’s just a more compact implementation of cycle.js, that sounds promising.

                1. 3

                  It’s similar to Cycle, but it isn’t based on the concept of streams. Instead, an application is just a function of driver inputs and returns driver outputs.

              1. 8

                Native oxide is stripped off the wafer with a quick dilute HF dip and then they are extensively cleaned in Piranha solution (H2SO4:H2O2), RCA 1 (H2O:NH3:H2O2), RCA 2 (H2O:HCL:H2O2), followed by another dilute HF dip.

                An obvious reminder: despite the context, do NOT try this at home unless you really know how to handle these chemicals. Sulfuric and hydrochloric acids are fairly benign when dilute… which these are not. Ammonia is toxic, concentrated hydrogen peroxide is caustic and can form all sorts of excitingly flammable and explosive substances if not handled with care, and killing you is probably the best thing HF can do to you.

                1. 4

                  Yup. You definitely should not mess with any of these without all the appropriate safety equipment (acid gloves, apron, and face mask, calcium gluconate gel, safety shower) and someone else available to help in the case of an emergency. HF is crazy dangerous. Direct contact with a 50% HF puddle the size of your palm is enough to kill you if not treated immediately, and even with immediate rinsing and calcium concatenate gel, treatment might require amputation. And it won’t hurt immediately. Once it starts to hurt, it’s already too late, and you’re in for a world of pain as it dissolves your bones.

                1. 4

                  Super impressive, especially for someone still in highschool! I still love everything about semiconductors, even though I found working in the industry too stressful. There’s just so much interesting physics, mathematics, and hardware, and its impact cannot be understated. It has impacted every other industry so thoroughly. And the number of man hours put into understanding silicon and how it interacts with basically every other element on the periodic table, with light, with heat, etc. boggles the mind.

                  For others interested in the topic, I highly recommend the book “The Story of Semiconductors” by J W Orton. It’s an interesting history set in a broader context.

                  1. 1

                    especially for someone still in highschool

                    oh my goodness I did not notice that. Wow.

                  1. 1

                    Looks very similar to LabVIEW, which I am not a fan of. Modern method chaining is much easier to both write and read.

                    The interactive development does sound nice, though. Similar levels of interactivity are available in Jupiter notebook or React hot reloading, though. And as demonstrated by Casey Muratory in Handmade Hero, you can even get the immediate feedback of sub-second compile times and hot reloading in C/C++, if you architect your code correctly.

                    1. 1

                      What’s “modern” method chaining?

                      1. 1

                        I just meant to distinguish method chaining from old-school one statement per line. Method chaining provides a more visual conveyance of the data flow, IMHO.

                        1. 1

                          I just asked because cascading has been around since long before I was born.

                          I do agree that multiple messages per statement are great.

                          1. 1

                            True. Just not as much in mainstream languages until the last decade or two. And more recent languages reaching mainstream, e.g. Rust, are fully expression oriented.

                    1. 5

                      “Also, someone already did it. And it works.”

                      Rust has done it once and, while it does work, it created quite a lot of mental overhead for new people and old until everyone more or less figured out what the hell was actually going on and a lot of docs and tutorials got updated. And that was with mostly quite minor changes that really didn’t affect the language itself, just the module system.

                      It’s an interesting proposal but don’t oversell it.

                      1. 4

                        Rust has done it once and, while it does work, it created quite a lot of mental overhead for new people and old until everyone more or less figured out what the hell was actually going on and a lot of docs and tutorials got updated.

                        And it hasn’t solved all problems yet. Rust 2018 was introduced with Rust 1.31.0. We use Rust 1.31.0 (besides the latest stable) in CI, mostly to check that stuff builds on distributions with older Rust compiler versions (e.g. NixOS 19.03). However, builds break every now and then, because some dependency in the transitive closure uses edition = 2018, but also use post-1.31 features (e.g. TryFrom). It would have been much nicer if edition = 2018 actually meant Rust 2018 and no newer features.

                        1. 5

                          Dependencies using too-new features is an orthogonal problem (existed before editions), and it can’t be fixed with editions. Even if editions hid new features, any dependency could still depend a newer edition than yours (e.g. request edition = 2020).

                          This is solvable with dependencies setting minimum required Rust version, and dependency resolution taking that into account. Completely independent of editions.

                          1. 4

                            Dependencies using too-new features is an orthogonal problem (existed before editions), and it can’t be fixed with editions.

                            I disagree. People often use new features accidentally, because they are on newer compiler versions and just consult the rustdoc and other online documentation without looking at the minimum version annotations. If edition = xyz would strictly enforce that Rust version xyz and the standard library version corresponding to the edition, such accidents do not happen.

                            1. 2

                              Such functionality could be included in the epoch system, but instead it is included in the already existing compiler version system. Basically all high quality crates specify their minimum required version, and CI test against that version. It probably would be good to include a field in Cargo.toml, but enforcement would require merging rustup into cargo, which has not yet happened.

                      1. 0

                        Algebraic data types are used extensively in Rust, where they’re called enums. It’s the same thing as a tagged union, but far more ergonomic thanks to pattern matching. If you want to understand their practical uses, I highly recommend reading some Rust code.

                        Once you become used to using them, it’s a pain to go back.

                        1. 3

                          What is the evolutionary advantage of synchronized flashing?

                          1. 5


                            In firefly mating rituals, the males cruise by, flying around and flashing their signals to let the ladies know that they are looking for love.

                            Meanwhile, female fireflies wait in the leaves, observing the males’ flashes. Each waits for a specific pattern of blinking light sequences are unique to each species. When they spot a pattern that they like, they flash the same signal back at the male as an invitation to come on over.

                            Scientists estimate that, of the roughly 2,000 species of fireflies around the world, only about 1 percent synchronize their flashes in large groups. However, flashing Photinus fireflies are very common, especially in North America. They evolved to flash in synchronizing patterns as a solution to specific behavioral, environmental or physiological conditions, said Moiseff.

                            Synchronous species of fireflies are often found in high densities, making it hard for female fireflies to see and register a lone male firefly’s signal. This suggests that there is a problem in the female’s information processing, which group synchronized flashing seems to compensate for, according to the study.

                            But once a female sees the mass synchronized signal and responds, how does she decide who in the group is to be her paramour?

                            “In the field, under natural conditions, we find that a responding female Photinus carolinus attracted several males,” Moiseff told Life’s Little Mysteries. “These males then cluster around her and interact among each other, as well as with the female.”

                            Researchers do not know whether the female’s initial response is directed at a single male within the synchronous group, or whether she is responding nonspecifically to the group as a whole. But because her response flash attracts many males, it appears that she isn’t communicating with any individual male, Moiseff said.

                            “Ultimately, however, she selected a single male to mate with,” Moiseff added. “The effect of this is that female choice is occurring separately from initial species recognition and attraction.”

                            1. 2

                              I’d be interested to know that too… although it may simply be that there is no evolutionary disadvantage to it and that’s why the behaviour has continued.

                              1. 2

                                You get a much brighter flash? I assume a single firefly is flashing with some kind of purpose (it’s a mating display for at least one species), so a bigger flash should be better.

                                1. 2

                                  You get a bright collective flash, but how are you going to attract mates towards yourself? That’s what I find puzzling.

                                  1. 5

                                    If they’re able to attract mates from a much larger radius, then more of them will come, so perhaps everybody is better off.

                                    1. 1

                                      Yeah, this suggests that flashing as a mating signal is limited to bringing potential mates into proximity. After that, flashing must not be a strong attractor, or synchronization would be strongly penalized. I’m guessing the synchronization is driven more by safety in numbers from predators.

                                  2. 1
                                  1. 5

                                    Children of the Fleet by Orson Scott Card. I’m listening through the whole Ender’s Game series. I wish I had read them years ago. This is #17 out of 18 released.

                                    1. 2

                                      I hadn’t realised there are that many in the series! And they’re all by him it seems.

                                    1. 2

                                      Are all these things prototyped and tested in realistic use cases prior to being finalized in the standard?

                                      1. 1

                                        gcc, clang, and msvc often have these features hidden behind experimental flags before the proposals are even approved, so the features certainly get tested in running code, and often also in production as the link from @tt points out:

                                        Most major C++20 features have been implemented in essentially their current draft standard form in at least one shipping compiler, and in most cases actually used in production code (i.e., has already been released to customers who are very happy with it). For example, coroutines (adopted only five months ago as of this writing) has been used in production in MSVC for two years and in Clang for at least a year with very happy customers at scale (e.g., Azure, Facebook).

                                        1. 2

                                          A better software analogy might be the difference between compiling without vs. with inlining and optimization enabled. Standard cells are essentially not, nand, nor, etc. gates always layed out the same way. Full custom design is when those smaller gates are “inlined” into larger cells and then optimized for space and performance.

                                          1. 2

                                            That’s true. It even fits what happens in full custom the way I was thinking of it. I just want to emphasize somehow the insane amount of manual labor that goes into the optimization. Maybe we could say what you said with the programmers doing all the optimizations by hand on each piece of the app.

                                          1. 9

                                            on the broad view, this is cool and i’m glad to have informed people in congress.

                                            on the other hand, this guy is behaving one of those sorry people who ask super-technical details after a talk in order to show how smart they are, and l don’t think he added anything to the discussion at all.

                                            1. 22

                                              He added one bloody important point: they are using Rust nightly. This is a fairly unstable dependency, and more importantly, this is a dependency that accepts outside contributions in a way that may not be as controlled as the core Libra codebase.

                                              It would be a freaking security risk if they pushed that to production. They are using Rust nightly now, but they probably should move to stable before they go to production, or at least freeze to a particular commit until the Libra association actually reviews the newer commits.

                                              I was actually disappointed that the Libra guy didn’t have an answer.

                                              1. 8

                                                I strongly disagree that nightly rust in and of itself is a security risk. Using a conservative set of #![feature] flags and pinned version of nightly I think it’s honestly more stable than many languages.

                                                All stable is is a mutually agreed upon pinned version of nightly with no feature flags.

                                                1. 5

                                                  I strongly disagree that nightly rust in and of itself is a security risk.

                                                  Understand where the congressman is coming from: Libra is (will be) a currency. Depending on adoption, it can get quite strategic, on par with weapons and the electric grid. The possibility of malicious contributions to the code base itself or its dependencies should indeed be investigated. Such malicious contribution have happened before: remember that NPM package that was stealing wallet private keys from the projects that uses it? (Or maybe it was mining?) It went unnoticed for months.

                                                  Rust is one such dependency. Rust nightly is the least reviewed part of Rust (besides experimental branches). Of course this makes some people nervous. Even if nightly Rust is as you say not a security risk, how it is not a security risk should be explained to those nervous people.

                                                  1. 1
                                                    • “No feature flags” is a big deal, since un-flagged operations are supposed to be frozen.

                                                    • Stable also goes through the Beta period, when new features aren’t allowed in but regression fixes are.

                                                    1. 1

                                                      Not quite. Bug fix point releases are not uncommon.

                                                    2. 4

                                                      He was also concerned that one of the top committers for one of the Libra projects was from Nigeria. I think we assume good intent and don’t discriminate based on where one lives. But since he’s coming from a “national security” background, I can understand why he might be more suspicious (justified or not) of “foreign” contributors.

                                                    3. 2

                                                      I think its good to remember that Congresspeople’s offices do followup for written details of what couldn’t be covered in these televised hearings. I hope his office does followup and gets the answers he seeks.

                                                    1. 20

                                                      And yet I have worked as a DevOps engineer whose job was orchestrating spreadsheets in a brokerage. I had a script that would spin specific versions of windows, install specific versions of excel on them, copy the last days spreadsheets into clean folders then start executing them in a specific order.

                                                      Once that was done everything was nuked and the results were saved to a network drive for the next day and other data pipelines.

                                                      Someone had cost the brokerage a few tens of millions by running the sheets in the wrong order which was why they were now locked down with no one having access to the ones that were used for trades any more.

                                                      This was not the only, or worst, example of excel insanity in industry I’ve been privy to.

                                                      There is a reason why we don’t let people build lego bridges for civil engineering and then put them in production. That we let it happen in software engineering in the name of ‘usability’ says a lot about how immature we are. Especially since spreadsheets have already killed thousands in Europe: https://www.washingtonpost.com/news/wonk/wp/2013/04/16/is-the-best-evidence-for-austerity-based-on-an-excel-spreadsheet-error/

                                                      1. 21

                                                        Are those issues because spreadsheets are conceptually bad or because we haven’t bothered to make better infrastructure around spreadsheets?

                                                        1. 5

                                                          This is an important point. There’s no fundamental reason modern VCS and deployment techniques cannot be applied to the spreadsheet concept. Thanks to software patents, you might have a tough time building a startup around the concept, though.

                                                          1. 7


                                                            What I was doing at the brokerage was pretty clearly not allowed by the licences of the software. No one would ever hear about it because we system was completely isolated and couldn’t phone home.

                                                            If I turned this into a startup I’d be sued to hell and back before you can say mvp. Patents are so far down the list of blockers for this I wouldn’t even think about them.

                                                            1. 2

                                                              Okay, but that’s for a specific instance of spreadsheet software (excel) and actual spreadsheet code. I’m talking about applying modern software engineering best-practices (e.g. VCS and dependency management) to the spreadsheet concept in general.

                                                              1. 3

                                                                You might as well be applying modern software engineering to forth. No one uses it in business and there is no money in it from the hobbyists. If you’re not bit compatible with xls files you might as well not exist.

                                                                1. 1

                                                                  You could provide function compatibility with excel. Macro compatibility would be much harder, but perhaps not necessary in order to gain some significant mindshare.

                                                                  Combined with a shared editing mode, this could be a great startup idea. Except for the risk of getting sued out of existence by Microsoft and Google.

                                                          2. 2

                                                            There’s constantly startups about replacing spreadsheets with something similar but better. I haven’t seen any of them make it. The moderator of Hacker News, Dan Gackle, even did one for YC called Skysheets. I don’t know any details about it. There was one that combined spreadsheets with a database that kept everything in sync instead of scattered around various PC’s. Lots of clever ideas. I think an interesting study would be a survey of all the failed companies to figure out what’s actually going on.

                                                            Meanwhile, I think it’s a situation combining a massively-popular tool, its usability, the herd mentality that brings new people into groups’ existing habits, and especially its format that was designed for lock-in with ridiculous switching costs. A bunch of Excel licenses with plumbing built around it is way easier to justify than getting off Excel in an already Excel-heavy industry with lots to lose in a failed transition with managers who have seen failed transitions eliminate jobs and bonuses.

                                                            1. 1

                                                              Yeah, I read the GP comment and I thought “start-up opportunity”. Spreadsheets / Excel aren’t going away. Maybe better infrastructure for managing them is really what people would want / be able to use.

                                                              1. 2


                                                                1. 3

                                                                  This seems like a replacement for Excel? I guess I did say “Spreadsheets” but I really meant “infrastructure around Excel”.

                                                            2. 14

                                                              And if those spreadsheets had instead been glorious Haskell programs it would have been impossible to run them in the wrong order?

                                                              1. 1


                                                                1. 0

                                                                  Or better yet, Idris, where it is trivial to prove mathematically that everything is happening in the correct order, by encoding state machines in types which then don’t let your programs transition incorrectly:D

                                                                  1. 4

                                                                    How does idris prevent you from running other programs out of order?

                                                                    1. 5

                                                                      By wrapping calls to those programs in an interface / type class of its own, and then controlling calls to that interface. The interface is stateful, that’s how it ensures correct protocols.

                                                                      1. 1

                                                                        I think the issue was probably that the running of the spreadsheets was done manually and/or the semantics of excel changed between windows/excel versions. In this context, a reasonably reliable bash script or makefile + statically compiled binaries would probably have been sufficient. No fancy tech required.

                                                                  2. 1

                                                                    Totally noob on spread sheets. How does one use the result of one spreadsheet on another? Is VBA magic involved?

                                                                    1. 4

                                                                      In excel you can refer to data in another file by including its filename and the sheet within the file you want to reference. The complexity progresses something like:

                                                                      Same sheet: =A3

                                                                      Same file: =!sheet3:A3

                                                                      Same filesystem: =[other.xslx]Sheet3:A3

                                                                      1. 1

                                                                        Ah thanks!

                                                                        One more question: In the case of OP, how does running it out of order work? Wouldn’t it have referred to empty cells and thrown an error? or does excel make up random values if you access a non-value cell?

                                                                        1. 3

                                                                          Daily updates got propagated through. A simple example were some conversion rates grabbed online.

                                                                  1. 3

                                                                    Flying back to Austin from vaca in Breckenridge, CO, then repacking for a work trip to Tokyo!

                                                                    On the flight, I might work a bit more on my browser-based multiplayer snake game, https://alpha.sneakysnake.io! I’m almost done adding a scoreboard. Just need to put the finishing css touches to correctly handle different window sizes. After that, I’ll make player names customizable.

                                                                    1. 5

                                                                      It is mostly an change that empowers developers; but it also is a change that will cause some existing code to break.

                                                                      This has been my impression of Rust, and why I’ve avoided doing much with it. It seems like it’s just a constantly moving target. I remember in its earlier days whole features (like classes) just being nuked out of existence. It may have settled down some now; I haven’t been keeping as close an eye on it.

                                                                      1. 27

                                                                        Since 1.0, this is the first major breaking change that I can recall. It’s also worth pointing out that any code that does break under NLL was fundamentally unsound – it shouldn’t have been compiling in the first place, but was, due to the limitations of the then-current lifetime analyzer. It’s also going to downgrade these breakages to just issuing warnings that this unsound code is going to stop compiling sometime in the future.

                                                                        My personal take is that, in a language that’s trying to prioritize safety and correctness, privileging correctness over the sanctity of “existing code that compiles” is the right move.

                                                                        Sure, in pre-release, there was a lot of churn as all manner of different ideas were tried out (like Classes) and subsequently removed. That’s, uh, why it was in pre-release. You need to get feedback somehow.

                                                                        1. 2

                                                                          It’s also going to downgrade these breakages to just issuing warnings that this unsound code is going to stop compiling sometime in the future.

                                                                          What’s the practical difference between “unsound” code that compiles and runs versus “undefined” or “implementation defined” behavior in C and C++?

                                                                          I suppose it’s a moot issue because there’s only one Rust implementation?

                                                                          1. 4

                                                                            What’s the practical difference between “unsound” code that compiles and runs versus “undefined” or “implementation defined” behavior in C and C++?

                                                                            I don’t think there’s any relationship there at all. Undefined/implementation defined code in C is code where the standard says, essentially, “in these cases the compiler can do whatever: compile, reject, crash, launch nethack”.

                                                                            Unsound code that was compiling under the AST based borrow checker in Rust were simply compiler bugs — explicitly disallowed things that slipped past due to defects in the borrow checker. The analogous situation in C is again a compiler bug

                                                                            1. 1

                                                                              What’s the practical difference between “unsound” code that compiles and runs versus “undefined” or “implementation defined” behavior in C and C++?

                                                                              There might be a difference between “this is unsound, we don’t know if the code is valid”, and “there is a data race” or some other genuine undefined behaviour.

                                                                              If you overlap borrows, one of which is mutable, your program should be rejected. But if you’re single threaded, overlapping borrows should be just fine. Perhaps confusing and bug prone, but as long as you don’t have any actual concurrent access, it should work.

                                                                              That’s most likely why there’s an unsafe mode: it’s like telling the compiler “I know you can’t prove my program doesn’t have any data races, but trust me, there isn’t any”.

                                                                              1. 4

                                                                                But if you’re single threaded, overlapping borrows should be just fine.

                                                                                Overlapping borrows are unsound even on a single thread. The canonical example of the borrow checker people use in intro talks is single threaded:

                                                                                let v: &mut Vec<T> = ...;
                                                                                let x0 = &v[0]; // overlapping borrow
                                                                                v.push(...); // potential resize invalidating x0
                                                                                println!("{:?}", x0); // use-after-free

                                                                                Or this more blatant case:

                                                                                let o: &mut Option<String> = ...;
                                                                                if let Some(s) = o { // overlapping borrow
                                                                                    *o = None; // string no longer has owner, is dropped
                                                                                    println!("{}", s); // use-after-free
                                                                                1. 1

                                                                                  Crap, didn’t think of pointer invalidation. Good point.

                                                                            2. 1

                                                                              It’s also worth pointing out that any code that does break under NLL was fundamentally unsound

                                                                              I don’t think this is true:


                                                                              This issue doesn’t mention unsafety, just inconvenience for them.

                                                                              1. 1

                                                                                That’s not my reading of it.

                                                                                From reading the various issues and reasoning behind stacked borrows it seems that:

                                                                                That particular lint identifies an unintended pattern that was allowed to compile as a two-phase borrow. The pattern is unintended, and undesirable, because it violates fundamental validity guarantees that all Rust code, safe or unsafe, must adhere to in order for there to be a coherent set of rules (“stacked borrows”) about pointer aliasing in Rust that unsafe code and compiler optimizations can be asked to adhere to.

                                                                                The two phase borrow pattern in question, in violating those rules, creates situations in which unsafe code or compiler optimizations that follow the rules will nevertheless result in safety and/or validity issues. This was argued about for several months with a bunch of people proposing various ways to make this particular 2PB pattern “work” with aliasing rules — but none of them seems to have managed a working solution.

                                                                                Hence, the lint and eventual removal.

                                                                            3. 12

                                                                              oh, maybe my standard is lower than yours but with the language itself, I was always impressed how remarkedly well managed stability. But yes, they fix compiler bugs eventually. I was once affected and got a pull request to my crate from the compiler team to fix it. The compiler release before issued a warning.

                                                                              So, this affects compiler bugs which might lead to unsafe code. The compiler issued warnings for some releases, now it will stop compiling that code.

                                                                              In my view, a remarkable balance between stability and upholding the fundamental guarantees of rust.

                                                                              (the library ecosystem is a different story)

                                                                              1. 4

                                                                                Maybe not the best wording on the author’s part, but if you read the rest of the post you would have read that only unsound code is affected, and it will continue to compile for now; only a future-compatibility warning will be raised.

                                                                                Rust has strong backwards compatibility guarantees, and has since the 1.0 release in 2015. It’s only a moving target if you want to use the latest and greatest features, which are admittedly being added at a considerable rate. But that’s only a drawback if the features are not worth the maintenance overhead, which so far has not been a problem for Rust.

                                                                                1. -1

                                                                                  ‘Unsound’ does not mean incorrect, it just means they can’t prove it is sound.

                                                                                  only a future-compatibility warning will be raised.

                                                                                  It is not useful to be told working code will maybe fail to compile at some nebulous point in the future when you specifically chose a stable release and edition to work with.

                                                                                  1. 3

                                                                                    ‘Unsound’ does not mean incorrect, it just means they can’t prove it is sound.

                                                                                    That’s what the unsafe blocks are for. If you didn’t intend a particular piece of code to be unsound, it shouldn’t be, and you should fix it.

                                                                                    1. 0

                                                                                      This is a bad argument taken to the logical extreme - as a compiler gets more and more intelligent it can reject more and more code, to the point is just rejects all code ever written due to all code we write having bugs.

                                                                                      My argument is simple, a rust edition should keep compiling things it accepted in the past. If they want to fix soundness problems, they should emit very loud and serious warnings and make a new edition. They shouldn’t retroactively stop compiling things they used to accept without a new rust edition.

                                                                                      1. 4

                                                                                        My argument is simple, a rust edition should keep compiling things it accepted in the past.

                                                                                        That argument is wrong. The soundness rules are not just defined by the (only) reference implementation. The soundness rules stipulated that multiple borrows (one of which is mutable) is not allowed to overlap, and it used scope as an approximation. If the compiler allow such an overlap, this is a bug and it should be fixed.

                                                                                        Likewise, if you unwittingly took advantage of this bug, and wrote unsound code outside of an unsafe block, you have a bug. Perhaps not a genuine bug, but you at least did not abide the soundness rules you should have. Thus, you should fix your code. I don’t care it’s something you consider “done” and no longer want to maintain. At the very least, you should accept a patch. If you don’t, well… there’s always the possibility of forking.

                                                                                        If they want to fix soundness problems, they should emit very loud and serious warnings and make a new edition.

                                                                                        Well, this is almost what they did: there’s a legacy compatibility mode, and warnings about that not compiling any more. That’s better than what C compilers do right now: when a new compiler spot an undefined behaviour it didn’t spot before, it could introduce a bug, without any warning, it didn’t used to introduce. (The magic of optimisations.)

                                                                                        But this is not about undefined behaviour. This is about soundness. Which unlike undefined behaviour in general is perfectly checkable statically. This won’t get worse and worse as compilers get better. It’s just a matter of fixing compiler bugs.

                                                                                        1. 0

                                                                                          I think it might annoy and cause reputational damage when all they need to do is make edition 2019-nll to avoid breaking the ecosystem.

                                                                                          Any crate with unsafe in it already has as much risk as something that has been there for years and nobody noticed any problem. They just need a warning and some bold flashy lights instead of permanently breaking our ability to compile a portion of crates.io. To maintain soundness they could make calling 2018 crates from 2019-nll an unsafe operation.

                                                                                          I think the right action depends how many crates they have obsoleted, which I don’t know. They should probably check and make it public, but I feel like they would rather not know.

                                                                                          1. 3

                                                                                            I think it might annoy and cause reputational damage when all they need to do is make edition 2019-nll to avoid breaking the ecosystem.

                                                                                            I dispute the assumption that they broke anything. Some code will stop compiling by default, but the old ways are just an option away. The warnings and the bold flashy lights is exactly what they have done. They have not broken your code, let alone permanently. Your code still compiles.

                                                                                            Sure, some users will get the warnings. Of course those users will file a bug. But your code still compiles, and will do for quite some time.

                                                                                            Any crate with unsafe in it already has as much risk as something that has been there for years and nobody noticed any problem

                                                                                            That’s just unsafe doing its job: a promise from the programmer that there isn’t any undefined behaviour, even though the borrow checker can’t verify it.

                                                                                            I think the right action depends how many crates they have obsoleted,

                                                                                            “Obsoleted” is such a strong word. I bet the changes required to fix the soundness errors in those crates will be minimal. I strongly suggest you take a look at your own crates, see where the new borrow checker got displeased, and do whatever is needed to please it again. This should be a quick fix.

                                                                                            1. 0

                                                                                              They have not broken your code, let alone permanently. Your code still compiles.

                                                                                              The warning specifically says they plan to stop it from compiling. Fine if it isn’t broken yet, but they told us the plan is to break things. They seem to have proposed adding these changes to edition 2015 to prevent even more code from compiling in the future.

                                                                                              I bet the changes required to fix the soundness errors in those crates will be minimal.

                                                                                              You also need to back port the changes to every major version release of your package to keep builds working for people depending on older API’s of your crates. Then you need to spend time testing each release, and publish them all. “Minimal” can quickly add up to an hour per crate., I don’t think all authors will do it, nobody is paying them to do it. Some probably don’t program rust anymore. It is just a loss for everyone.

                                                                                              “Obsoleted” is such a strong word. I bet the changes required to fix the soundness errors in those crates will be minimal.

                                                                                              Those crates simply won’t compile with newer versions of rustc 2018 edition without changes. The old versions just won’t work anymore without change, that sounds like obsoleting to me.

                                                                                              Anyway, obviously there are positives, like a lower maintenance burden so it isn’t totally bad.

                                                                                              1. 2

                                                                                                I don’t think all authors will do it,

                                                                                                I agree, they won’t. But I think it’s reasonable to assume that every single noteworthy crate will be addressed. The other can fall into oblivion like they would have anyway.

                                                                                                Those crates simply won’t compile with newer versions of rustc 2018 edition without changes.

                                                                                                The original post says: the 2018 edition of Rust […] has had NLL enabled ever since its official release.

                                                                                                It’s a new edition. If you don’t want to update your code, well, just put a note that you’re only Rust 2015 compatible. C++ broke compatibility in similar ways, by the way: remember how it hijacked the auto keyword ? Nobody complained, because everyone understood it was a major release of the language (and the auto keyword could easily be removed from old code).

                                                                                                And then there’s the migration mode, that allows you to take advantage of Rust 2018 even if you fall into one of those soundness bugs. Yes, they will turn it off eventually. But really, if you stopped maintaining your package, you are still using Rust 2015, and you will be fine. If you do maintain your package, well… what’s an hour per crate, really?

                                                                                                It is not possible, nor (I think) even desirable to add special cases to the NLL borrow checker so it is bug compatible with the old AST borrow checker. It doesn’t work the same way at all, and even if you could reach for bug compatibility, you’d still have a soundness bugs, and with it the possibility of data races or pointer invalidation in supposedly “safe” code. Is bug compatibility worth sacrificing correctness? Not in my book.

                                                                                                Then there are the benefits of the NLL borrow checker to begin with. Now pleasing the borrow checker will be much easier. Old complaints about it will likely fade away, and learning Rust will likely be less painful. Would you seriously sacrifice that just so you can be bug-compatible?

                                                                                                Make no mistake, this is bug compatibility we’re talking about. Breaking code that relied on a buggy version of the Rust compiler, and as a result were not as safe as rustc claimed it were. They did not remove any feature, they fixed a bug (several bugs, actually). Sucks that the bug lead rustc to accept unsound code, but it’s really really not the same as, say, removing support for some syntax sugar or whatever.

                                                                                2. 3

                                                                                  Rust has been stable for a long time now, so the moving target you mention has long settled. And as /u/pkolloch mentioned, the breaking changes are just bug fixes essentially, and they are downgrading the errors to warnings for an indefinite time. You should definitely check the language again if you feel like it.

                                                                                  1. 3

                                                                                    I thought the same about Rust, but then I realized that it was only going to break things if I upgraded my toolchain. This wasn’t something where a “yum/apt/brew install” or even a rustup would nuke my existing binaries. Instead, it only applies to upgrading your toolchain.

                                                                                    If the wrong version of python (2.6 instead of 2.7) is installed in a container or on a host I’m trying to use, I’ll see bugs or failures to run. God help me if I want to run Python 3 code. I hit that snag all the time.

                                                                                    With Rust, that problem is more or less nonexistent. I use Python A LOT. However, I still see the merit of Rust on this front. I’ve seen and used @yonkletron’s work written in Rust in an incredibly risk-averse environment and I was quite impressed at how little I had to think about it compared to my own Python work.

                                                                                    Rust may be less stable for me as a developer (and even that I’d question!) but it sure as hell seems pretty stable for me as an end user of apps written in it.

                                                                                    1. 2

                                                                                      It seems like it’s just a constantly moving target.

                                                                                      It’s definitely pretty active. But IMO this particular case strikes me as fixing a compiler defect (permitting unsound code to compile). It was a defect not to emit an error for this case, IMO. Fixing defects that result in new errors is not instability from the toolchain, it’s a bugfix that Rust customers should welcome (even though fixing their bug is a prerequisite to accepting the new toolchain release).

                                                                                      Maybe I didn’t quite read this article right but the fact that their 2015 example yields a warning that explicitly states that it was downgraded for compatibility makes it sound like the designation “will cause some existing code to break” is too pessimistic.

                                                                                      1. 0

                                                                                        They added warnings saying working code of mine in already released crates was going to stop compiling. I complained about it and nobody replied.

                                                                                        To put it another way, rust already broke code in one of my ALREADY RELEASED crates WITHOUT AN EDITION CHANGE. It pissed me off so much.

                                                                                        Not everyone has resources to go back and rewrite and retest code at their whims. In my opinion this change should be a strongly worded warning about potential unsafety + an edition change if they were serious about language stability. Don’t tell end users of my crate “hey, we might break your code maybe sometime, we don’t know when.”

                                                                                        If by future versions, they meant “future editions” I would be much more okay with it.

                                                                                        1. 2

                                                                                          If by “broke code”, you mean “emit warnings on newer versions of the compiler”, then maybe. What’s the crate? Where did you notify the developers (“complain”)? Are you sure the code is sound?

                                                                                          1. 0

                                                                                            Here is the issue, A report from a user of a released package:


                                                                                            Here is the complaint in the official thread for complaints of this issue:


                                                                                            Are you sure the code is sound?

                                                                                            My reading of that issue is that it is sound, but inconvenient for them, but I don’t really care, they should do an emergency edition change for unsound code if the change isn’t backwards compatible. If code can’t last 6 months, what use is it? I want to write code that keeps working as when I wrote it for 20 years, 200 years if possible. They invented the edition system, why don’t they use it.

                                                                                            I don’t like how it is deemed ok to disregard small projects who put faith in rust.

                                                                                            1. 5

                                                                                              they should do an emergency edition change for unsound code if the change isn’t backwards compatible

                                                                                              No… Compiler bugs should be warned about once it becomes feasible to do so, with ample time before making them hard errors. Which is exactly what they’re doing… This looks like a great example of that system working. The warning drew your attention to your dependence on the compiler bug, and you fixed it the same day. All dependencies continued to compile, and assuming you released a patch version and yanked the previous version they always will.

                                                                                              If fixing any compiler bug required an edition bump, then the compiler would be riddled with bugs. Don’t pretend that you would prefer that.

                                                                                              1. 0

                                                                                                Now 0.1, 0.2,0.3,0.4 and 0.5 versions of my project on crates.io are useless junk. What is the point of them being there?

                                                                                                If my crate were a library this would also turn all crates depending on them into useless junk too. In my complaint I asked if they checked how many crates they are no only deprecating, but outright obsoleting.

                                                                                                If you also note, the issue I linked doesn’t say it is a soundness issue, just a mistake they made accepting things that makes some future changes more annoying for them.

                                                                                                1. 1

                                                                                                  Traceability. Studying the history of the code. Reproducing the results if they download the needed version of Rust. Not too many practical reasons, though.

                                                                                      1. 4

                                                                                        Flying to Breckenridge, CO for family vacation!

                                                                                        On the plane, I’ll likely continue working on my browser-based multiplayer snake game, https://alpha.sneakysnake.io! Next steps are adding a score board and customizable player names.

                                                                                        Also, I just ordered the “Tap” input device to the vacation house and am excited to try it out and see if it’s a practical replacement for a keyboard and mouse. If it is, then all I’ll need for truly mobile computing is a retinal display! (I’ll be holding my breath :-)

                                                                                        1. 2

                                                                                          I approve of both of these things.

                                                                                          Would love to read your review of the Tap.