1. 3

    I think the title is misleading: This is not about simply using Redux and TypeScript but about improving on the recommended patterns by using advanced TypeScript features.

    1. 2

      That’s a good point. I can see in hindsight that it might sound like an introductory tutorial.

      Would it be good lobste.rs etiquette to edit the title after posting it?

      1. 3

        Since I updated the title on my website I updated the lobste.rs title to match. Since it’s only the sub-heading part I hope its obvious to people it’s the same story.

    1. 3

      I agree with the sentiment “we have to stop thinking about elegance, beauty”. I have often been in discussions like this:

      • it’s ugly
      • does it do the right thing
      • yes, but it’s ugly
      • do you understand what it does?
      • yes, …
      • do you think that it will break unintentionally?
      • no, …

      Elegance and beauty are trained sentiments. A suspicion of ugliness can be a useful signal to look again for alternative solutions or also pitfalls. But ultimately, they change and are meaningless for themselves.

      1. 0

        hmmm, the time that I program in my programming job might be but to far of what Peter Norvig still achieves while managing.

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

                            A lot of interesting concerns. But the author thinks that web components directly compete with web frameworks. I’d see web components more as a building block for frameworks and as an integration point. For example, in Elm you can use a web component implemented in another framework. Without web components this was difficult because Elm wants to own the DOM as many other frameworks. With web components, elm still owns the outer DOM, the other framework the shadow DOM.

                            (the global namespace makes this awkward)

                            1. 16

                              “…The idea of strong opinions, loosely held is that you can make bombastic statements, and everyone should implicitly assume that you’ll happily change your mind in a heartbeat if new data suggests you are wrong…”

                              No, it does not. It means that as a professional, you do not associate your passion for a technical topic with your self-worth. It’s okay to feel strongly about something without being a jerk about it. It’s permission to speak honestly and get feedback from others. If you do this, others may very well call you an asshole! They may vote you off the island. So you learn what’s important and what’s not. What’s worth having public passion over and what’s just being a jerk.

                              You should have strong opinions about error handling, or customer service. You should speak up about your opinions so we might learn from you. You might have strong opinions about the pasta down at Luigis, but nobody cares. And we’ll tell you so. The requirement with strong opinions lightly held is that you have to agree to suck it up and do things you might not agree with. You can’t have one without the other.

                              It’s just the opposite of what this author thinks it is. It’s the thing that over time prevents people from being jerks, not encourages them to.

                              ADD: Does our industry have a problem with tech bros and people making bombastic statements? Most definitely. But I don’t think that’s related to SOLH. In fact, for every one of these bozos, I can show you five tech people that should be speaking up and are not. Those are the ones who cause real damage to an organization.

                              1. 21

                                You should have strong opinions about error handling, or customer service. You should speak up about your opinions so we might learn from you.

                                There is a famous Bertrand Russell quote: “The whole problem with the world is that fools and fanatics are always so certain of themselves, and wise people so full of doubts.”

                                It matches my experience exactly. The more I learn about complex topics like error handling or customer service, the more I realize that there is no “One True Way”™, and that it’s actually really complex and a series of trade-offs.

                                Does our industry have a problem with tech bros and people making bombastic statements? Most definitely. But I don’t think that’s related to SOLH. In fact, for every one of these bozos, I can show you five tech people that should be speaking up and are not. Those are the ones who cause real damage to an organization.

                                At least some people are not speaking up out of fear or exasperation by being told that their viewpoints are “absurd” or “not sane”.

                                I just tap out of discussions these days once someone starts acting like that, and I know that in a few instances it has caused real damage to the business. I’m not happy with that, but there is a limit to what I’m able to put up with before it starts affecting my mood to an unreasonable degree.

                                1. 7

                                  Strong opinions does not necessarily mean obnoxious or loud. I don’t understand how we got to the point where people think that. I feel strongly about fishing in the rain. Doesn’t mean I ever yell about it. It’s an odd conflation of ideas, as if the demonstration is as important as the strength. I wouldn’t think that would be true at all.

                                  We have to self-correct. In order to self-correct, it is necessary to make a case for some path we recommend and then negotiate/argue/arm-wrestle as part of a decision-making process. Passion allows us to make our case. It does not have to involve yelling or being rude. We just have to care, to feel strongly. After all, we’re professionals. Why wouldn’t we feel strongly about various parts of our job? I’d argue we aren’t worth a bucket of warm spit if we don’t. I know I wouldn’t want to work with anybody who had no passion in our work.

                                  It’s such a weird confusion of ideas. Feeling strongly about something does not mean acting like a bozo. In fact, that’s pretty much acting childish.

                                  Yep, everything is complex and people who oversimplify and are too sure of themselves can be problems. It is also true that given incomplete and sometimes self-contradictory information, we are required to make choices. We should do what we can to make sure these are the best choices possible. Tapping out ain’t cutting it.

                                  1. 5

                                    What you’re describing doesn’t sound like a “strong opinion” to me, but rather just “an opinion”.

                                    Perhaps this is just a case of semantics, but the adjective “strong”, to me at least, means either “not likely to be convinced otherwise” or “obnoxious or loud” These are indeed two very different things, but generally neither of them are very constructive, and doesn’t really seem like what you’re describing.

                                    1. 1

                                      I thought the strong was an adjective on your belief in the opinion. As in, you believe with all your heart that a particular option/action/way is the right one.

                                      1. 1

                                        If you’ve got extremely strongly-held priors, you’re liable to be hard to convince (and require a lot of evidence to budge). This is a problem because such priors are not typically based on reality. As a general guideline, if you want to be more right about things, you ought to be less sure about them.

                                  2. 2

                                    I agree. I am not going to have a shouting match with my coworkers. It’s not worth the aggravation.

                                    1. 1

                                      There is a famous Bertrand Russell quote: “The whole problem with the world is that fools and fanatics are always so certain of themselves, and wise people so full of doubts.”

                                      Well, I am personally full of doubts. Still I would give some of this type of decision makers more credit. It is easy to criticize everything since nobody knows anything of relevance with certainty (or you wouldn’t need to argue about it). In a tech context (and many others), it is often more effective to go with one reasonable choice, stick with it and control doubt with overconfidence.

                                      1. 1

                                        I like the quote and agree on the spirit ( https://quoteinvestigator.com/2015/03/04/self-doubt/ ) but you are confusing strong opinions with overconfidence / inflated egos.

                                      2. 2

                                        There’s something valuable about SOLH, so long as the LH part is taken to mean both qualifying statements based on an honest and informed estimate of confidence & actually updating your priors. And, some folks who stand by SOLH (including, presumably, some of its popularizers) take it this way. I’ve seen too many folks who apply it in the way OP describes to believe that it isn’t being used as a justification for ultimately destructive behaviors, though, even if that application is based on a misunderstanding of what the original popularizers intended.

                                        OP’s suggestion of annotating statements with confidence levels (which is popular in the rationalist community for blog posts, & seems to have come from Robert Anton Wilson, who recommended it along with e-prime for avoiding common patterns of miscommunication) is a good one, because it rewards accurate estimates of confidence, providing a road for careful folks to gain social status over pundits & blowhards by raising a useful metric above being loud and contrarian (which, unless it’s paired with careful thought, introspection, and a rigorous and accurate estimate of one’s own confidence levels, usually ends up being equivalent to being annoying and wrong).

                                        Of course, this runs contrary to norms. We live in an environment where qualifiers are called ‘weasel words’ & no matter how much you signal your level of confidence, all those signals will be stripped away as you are judged on your conclusions as though your confidence were 100%. Furthermore, confidence is held in esteem before it can even be proven to be justified, so we cheer on demagoges for being bold as they lead us full speed ahead into obvious traps. In such an environment, people who can get away with avoiding being held to account are incentivized to sound very sure, and everybody else is incentivized to keep their mouths shut.

                                        1. 3

                                          I think all of us are missing the point when it comes to passion, confidence, truth, and so on.

                                          These are language games. Most of what teams do are language games. Put another way, everybody wants to do a “good job”. The rest of what we do is trying to come to common agreement on what the phrase “good job” means.

                                          The certainty number isn’t awful. It just misses the point of what we’re trying to do. As arp242 pointed out, things are complex. What we’re looking for is the simplest question we can agree on that’s important, testable, and that we disagree on the answer. That question might be something like “Switching to SONAR will result in 10% fewer bugs to production” (I can’t give you a good example because it varies widely depending on the circumstances.)

                                          To get to that pivot question, we have to take strong opinions about fuzzy things, then work our way towards being more reasonable about absolute things. This is the job of being a smart person who creates technology. A user comes in and says “I hate this! Make it stop sucking so badly!” and we work towards testable chunks of code.

                                          It’s perfectly fine to respond with “What do you mean this sucks? This is awesome!” This is the beginning of that back-and-forth. Checking out is not an option. You could try to go the percentage route but then you’re not working towards better definitions of terms. Instead taking a strong position and then following it up with something like “Which parts are sucky?” takes the game forward a step.

                                          “I like X!” vs. “I hate X!” are fine places to start. There’s passion there. Now add some technique and flexibility. If everybody is appropriately apathetic, you are in stasis. Not a good place.

                                          1. 3

                                            That makes sense when the origin of the decision-making process is passion, and when nobody comes to the situation with a nuanced understanding. In most professional situations, neither of these are the case: developers are working on things they don’t care about for users who see the application as a necessary evil, and one or two folks in the group have 30 years of professional experience to everybody else’s three months (along with complex nuanced and experience-backed takes that simply can’t be boiled down to a slogan). Three junior devs shouting irrelevant preferences doesn’t help in this situation, and because their nuance-free takes are low-information, they can be repeated over and over (and thus gain control over the thinking of everybody else). The person with the best chance of designing a usable system gets shut out of the discussion, because when takes are optimized for hotness nobody wants to read an essay.

                                            This notional experienced dev has a greater justification for confidence in their general position, but will necessarily express lower confidence in any individual element, because they have experienced instances that provide doubt. Meanwhile, the junior devs will be more confident because they have never been contradicted. This confidence is not representative of justified confidence.

                                      1. 34

                                        Its OK to write unsafe Rust code. Honest! Compile time safety is the main innovation of Rust and its killer feature, but its ok for parts of an API to be unsafe. Rust enforces safety by guarenteeing a certain pattern of memory use, and if that is a bad fit for your problem then thats just life. The halting problem guarentees that no one-size-fits-all solution will ever exist.

                                        I’m currently writing unsafe Rust for graphics library code. I’m reasonably sure it can’t corrupt memory because I’ve structured it so it can’t. Rust could enforce some of the invariants I’ve imposed at compile time, but it would make the entire process viciously painful.

                                        Even unsafe rust has real enums, strong types, macros, pattern matching, a module system, and all the other things C (and C++) doesn’t. Using C instead is like finding out you new dirt bike gets sand in your face and going back to riding offroad on a donkey instead of wearing a helmet.

                                        1. 9

                                          The effort to write unsafe rust seems to me far more than just writing C. So if you don’t get the safety benefit, it is just a pain.

                                          1. 7

                                            But the point is that only the unsafe parts will be unsafe. Besides that, writing unsafe Rust is subjectively more fun than writing C.

                                            1. 3

                                              I think it It depends on what you are interfacing with. Interfacing with a C framework can be very hard because there will be so many assumptions and things to work around and the unsafety will be pervasive, for small C libraries it is not bad. I’ve tried both some of both types of rust wrapping, and that is just my feeling so far. .

                                              1. 2

                                                Although I have no experience in Rust, but I can still acknowledge this: I have interfaced with suite some C code from C#, and if that C code was not designed in a mindset that it will be wrapped it was really painful. Now I can imagine that strict ownership of memory references can only add a lot of more hardship and complexity.

                                              2. 2

                                                The takeaway of the pre-poop your pants bug was that unsound, unsafe code does create bugs in safe code.

                                                1. 2

                                                  Yeah, this section of the rustonomicon https://doc.rust-lang.org/nomicon/working-with-unsafe.html talks about exactly that too.

                                              3. 3

                                                There are a lot more safety benefits to rust then preventing pointer dereferencing (which is primarily what unsafe allows). Too many to list from a smartphone. And Rust provides far more than just safety.

                                                1. 1

                                                  I think that the difficulty lies in wrapping it with safe code which is true to all safety guarantees.

                                                  Or do you genuinely mean writing unsafe rust all the way is more difficult than writing C? I’d love to hear why.

                                                  1. 3

                                                    genuinely mean writing unsafe rust all the way is more difficult than writing C?

                                                    I found very low level rust code dealing with C types has excessive casting + far more verbose code. Interfacing with C is not idiomatic rust, needing to use types like CString and CStr and doing lots conversions, it is just more annoying for some things.

                                                    1. 3

                                                      I think it is in part a fault of C library, not Rust. Null-terminated C string is not null safe and in general a bad interface to provide for libraries.

                                                      1. 1

                                                        I didn’t say it was rust’s fault, just that it can be lots of extra work to do interop.

                                              1. 18

                                                I have long had trouble understanding how the blockchain gets the very many magical properties ascribed to it. Every time I’ve asked, I have gotten a lecture in hashes and proof of work. I know the fundamentals of blockchains, what I don’t understand is how the fundamentals lead to these amazing emergent properties.

                                                This article sorta kinda makes me think I might not be missing anything at all – the people talking about it may have been full of shit.

                                                1. 8

                                                  I have been wrong before but to me it seems like a mass psychological phenomenon. That many people and that much money cannot be wrong! So they add more people and money.

                                                  In the best case, some companies use the label “block chain” to market some established cryptographic techniques that are not block chain at all…

                                                  1. 7

                                                    yep. You might think “blockchain” meant something like “append-only ledger with a consensus mechanism”, but it turns out in practice to literally just mean “whatever I’m trying to sell you today”.

                                                    I was talking about this a few months ago with a well-meaning non-techie, who suggested that Uber - the money-burning minicab firm with an app - was an example of a “decentralised system.” More than that - it was a model for how blockchain could succeed.

                                                    I think they’d never thought about the concept of distributed systems of any sort ever before in their lives.

                                                    “It’s like blockchain, because anyone can sign up to be an Uber driver!”
                                                    “Uh … anyone can sign up to be a minicab driver.”

                                                    or the very concept of “open source” only being possible with “blockchain”.

                                                    1. 4

                                                      The weird thing is that I know intelligent, technical people that advocate for this. If asked for specifics, some variant of “we still have to figure out the specifics” is used.

                                                      Well, chances are that you never will…

                                                    2. 4

                                                      The hype cycle became self fulfilling. I got a look at the internal roadmap for one of the pieces of legacy software at the big enterprise I work at - crusty old barely touched 90s technology that’s critical for parts management and ordering.

                                                      2020 plans? Traceability of parts on the blockchain.

                                                      1. 1

                                                        Traceability, correct me if I’m wrong, was one of the actual things a distributed append-only ledger was good at. The way I see it, it’s a good decision with regards to what tech to use, at least until someone puts the wrong data in.

                                                    3. 4

                                                      As well as that non-tech explanation talk, I have the longer and more techy version to an infosec group. (My mission to get across to them: “please don’t get into blockchains”)

                                                      1. 4

                                                        You’re sending the wrong message. Instead, tell them to come up with something useful, pitch a blockchain version, build the useful thing first with the money, open source it, and then build the “better” version with blockchain. We’ll steadily get more useful stuff out of blockchain investments.

                                                      2. 4

                                                        I’d like to refer to this article about Bitcoin from 2011, before all the mass hysteria began: https://paulbohm.com/articles/bitcoins-value-is-decentralization/

                                                        To elaborate: Bitcoin isn’t just a currency but an elegant universal solution to the Byzantine Generals’ Problem, one of the core problems of reaching consensus in Distributed Systems. Until recently it was thought to not be practically solvable at all, much less on a global scale. Irrespective of its currency aspects, many experts believe Bitcoin is brilliant in that it technically made possible what was previously thought impossible.

                                                        /edit quote

                                                        1. 4

                                                          Herd behavior. It’s usually irrational except for the scheming people fueling and benefiting from it.

                                                          Blockchain looks like herd behavior. Similarly, most of it has a tiny group of people that will get rich if enough buy in. That’s similar to how companies like Goldman create, pop, and profit from bubbles in the market.

                                                          1. 3

                                                            irrational exuberance meets unjustifi-ed/able faith in technology.

                                                            if you bought into a blockchain, you want to hype it up because that’s how you get paid. If you didn’t buy into it, well you got bored of trying to reason with people a long time ago.

                                                            It’s probably the most interesting social phenomenon of recent years.

                                                            1. 2

                                                              It sounds basically like a pyramid scheme when you put it like that…

                                                            2. 2

                                                              The flip side of this is that some companies are actually trying to look for the blockchain-based “killer app”, if such an app ever exists. I did develop a few blockchain based proof of concepts, which didn’t go anywhere, but there wasn’t any attempt to trick anyone. It’s just about experimenting with a new technology and see what can be done with it.

                                                            1. 47

                                                              Nothing big, but for me it’s special because it contains a very minor bug-patch I submitted, the first to any larger project. I might have had managed to submit another one, but I sadly didn’t have the time.

                                                              1. 7

                                                                Very cool! It’s always nice to see a contribution you made get incorporated.

                                                                1. 3

                                                                  Awesome! That’s a good feeling.

                                                                  1. 2

                                                                    Congratulations! What was it?

                                                                    1. 3

                                                                      If you had an old version of Enchant installed, like the one found in the debian repos, you were notified that it wasn’t supported. But if you changed back, it still wouldn’t work, and now every spellchecker would be outdated. Turns out ispell’s code is quite wierd, and it requires reverting the global state of a versions used, to properly warn or not warn the user.

                                                                      Here’s the link, if you’re interested: http://lists.gnu.org/archive/html/bug-gnu-emacs/2019-01/msg00216.html

                                                                      As you can see, it’s really only

                                                                      +              ispell-really-enchant nil
                                                                      1. 4

                                                                        I like this on many levels. I can relate because I recently made a one-line contribution to NixOs, I was proud of. And I really dig that free software allows you to fix these small things that bother you.

                                                                  1. 1

                                                                    I think that this looks quite nice. I am annoyed by chat options that are not truly multi-device. I do like that the client is open-source.

                                                                    Why can’t old chats be synced to new devices, though? You could sync them via other devices, couldn’t you?

                                                                    1. 1

                                                                      Non-ephemeral chats are synced to new devices as described in the FAQ:

                                                                      Non-ephemeral messages persist until the user explicitly deletes them and are E2E synced to new devices. This produces a Slack-like experience, only encrypted! So when you add someone to a team, or add a new device for yourself, the messages are unlocked.

                                                                      1. 1

                                                                        But why only non-ephemeral ones? The article mentioned forward security but it makes no real sense to me. You could use new forward secure keys for the new communication…

                                                                        1. 2

                                                                          I thought that don’t-sync-to-new-devices was a feature. I thought the ephemeral option was for those messages that you want to send but not keep. Messages that don’t have value in the future (or do have liability in the future).

                                                                          1. 1

                                                                            ah, alright. that does make sense. For me, a new trusted device is a relatively arbitrary boundary to bounce ephemeral messages on, though.

                                                                    1. 5

                                                                      Author here. Feel free to ask any questions.

                                                                      carnix did not work for my personal projects and after failing to fix it, I created crate2nix.

                                                                      For me, it is also a personal goal for this year to publish software and/or blog articles. Despite of or because of being an experienced professional software developer, this has been difficult for me: I always think that I should be able to do better. So, publishing this in an early but useful state is already a medium-sized triumph for me :)

                                                                      1. 1

                                                                        Nice work!

                                                                        • The README states that crate2nix only works on Linux. But after replacing nixos-unstable in the shell.nix of crate2nix and replacing nixos in the generated default.nix file, it seems to work fine in macOS.

                                                                        • It doesn’t seem to work correctly in a directory that is a Cargo workspace.

                                                                        Keep up the good work!

                                                                        1. 2

                                                                          Thanks a lot!

                                                                          1. platform support: nice to know! for the generated files, it still filters all dependencies restricted to a target config to Linux. if you don’t have Linux specific targets, that’s fine, of course. I did this because some obscure fuchsia, windows libs broke my build.

                                                                          2. true: I should mention it in the restrictions. it should also be easy to do better.

                                                                          feel very free to file bugs for dependencies that break the tool.

                                                                        2. 1

                                                                          Any thoughts on using https://github.com/google/cargo-raze and Bazel inside Nix?

                                                                          1. 1

                                                                            I haven’t tried cargo-raze but I looked at the code for inspiration. I decided to use tera because of that.

                                                                            I use sandboxed builds. If bazel uses its own caches, I don’t know how that should work. Do you have an idea?

                                                                            For me, it is important and what I like about nix that I just run nix build or nixops deploy and I do not have to install any other dependencies.

                                                                            1. 1

                                                                              Oh, I forgot to mention that the other way around looks quite fancy:


                                                                              Using nix to install some binaries/dependencies from blaze.

                                                                              That said, I am not sure if there is a proper ecosystem around blaze? E.g. deployment tools integration or similar?

                                                                              1. 1

                                                                                I think it would be a sandbox in a sandbox, which should work fine. The Bazel build would benefit users on Windows (without MinGW)

                                                                                Bazel has a nixpkg IIRC, so it shouldn’t be too difficult to get started.

                                                                                Bazel sandbox would also give you a few additional features:

                                                                                1. Remote caching across a network
                                                                                2. Remote execution on a build cluster

                                                                                These can accelerate the build process.

                                                                                I haven’t tried Rust + Bazel + Nix, so was interested if you had!

                                                                                1. 1

                                                                                  The sandboxing problem that I had in mind was no network connectivity (except in-built nix fetchers). That would block the features that you mentioned, correct? also how to access even a local cache and update it?

                                                                                  I haven’t really set it up for myself but remote builders look easy to setup. Not sure how hard it is to generalize that to a bigger cluster.

                                                                                  Remote caching should also be possible, e.g. with cachix.

                                                                                  Maybe bazel does it better.

                                                                          1. 2

                                                                            Nice work! And kuddos for the very clean codebase.

                                                                            Out of curiosity, did you try reaching pmeunier to report your bug? I guess he would be happy to know which use cases of yours failed with his tool :).

                                                                            1. 2

                                                                              Thank you! Yes, I did report bugs and also tried to fix them. There are quite some open bugs: carnix. I don’t blame him, probably just not enough bandwidth.

                                                                              That said, I am very willing to work together with anyone on a cool/canonical solution for rust/nix that also works for me.

                                                                            1. 8

                                                                              Thanks for sharing this! I think it’s so crazy it may loop around to being cool somehow. I’m already thinking of how I can write an LDPL compiler in LDPL. ;-)

                                                                              What does L.D. stand for?

                                                                              1. 8

                                                                                Thanks to you! Hahaha bootstrapping LDPL in LDPL is something I would like to do someday, if you do it please show it to me!

                                                                                LDPL stands for Lartu’s Definitive Programming Language. I’m Lartu and, apparently, this is my definitive language (?

                                                                                1. 6

                                                                                  Little Dinsaur Programming Language

                                                                                  Obviously. ;)

                                                                                1. 4

                                                                                  I wrote this post with some trepidation. It seemed, even as I wrote it, that it was a bit pretentious. It put my in mind of my favorite Lyndon Johnson quote:

                                                                                  “Making a speech on economics is a lot like pissing down your leg. It seems hot to you, but it never does to anyone else.” - Lyndon Johnson

                                                                                  1. 2

                                                                                    It was a nice read. I like hearing about what people thought worked and what not. As part of a selection bias of mine, I always like if someone says that quality is essential ;)

                                                                                    I didn’t find it pretentious even though it is obviously not science.

                                                                                    I was confused about the “Some things that didn’t seem to be missed” headline. These were things that you seem to got away without? So you did these in your company at some point, then stopped, and it seemed ok?

                                                                                    1. 1


                                                                                      “Some things that didn’t seem to be missed” means that about not needing those things; generally, we either tried them once (expensively) but stopping seemed fine, or we never did them. Of course, I can’t prove something from a counterfactual. Maybe things would have been wonderful if things had been otherwise (I don’t think so).

                                                                                    2. 2

                                                                                      Going to throw another voice in the “enjoyable read” column.

                                                                                      I don’t work at an algorithms startup, but it’s interesting to compare my experience at a large, enterprise, non-software company. Testing, build only what you need, good teams are diverse, etc. are all widely applicable lessons.

                                                                                      1. 1

                                                                                        I liked the article too (hence submitting it) – BUT I would like to know some other examples of “algorithms” startups!

                                                                                        It sounds like you had licensing revenue prior to the acquisition? If that’s the case, then why classify it as an “algorithms” startup? Maybe Intel just wanted the revenue, or they thought that some existing Intel customers would also want to be customers of Hyperscan.

                                                                                        I’ve known of several “technical acquihires” over the years, e.g. PeakStream was acquired by Google. But it seems like you’re saying the motivation for Intel was different here, although you didn’t say exactly what that was. I don’t think PeakStream was an “algorithms” startup although I could be wrong.

                                                                                        Another thing I could think of is that Intel wanted to promote Hyperscan as an x86 technology and de-emphasize other architectures. It would make sense for them to say that x86 is the best platform for doing high speed software regex scanning.

                                                                                        Anyway, my point is, since I think such startups are pretty rare, and as you allude to they may not make more money than other startups – it would be useful to know from a business perspective exactly WHY Intel acquired Hyperscan!

                                                                                        Since this link turned out to be popular, I should probably submit this video as well:

                                                                                        Cliff Click - Lessons from a Big Data Machine Learning Startup

                                                                                          1. 1

                                                                                            (a bit late to this party)

                                                                                            I can’t speak with any detail as to why Intel acquired us; our vision and theirs were quite compatible (think DPDK as the other, bigger, strand of this).

                                                                                            We weren’t just a technical acquihire, though.

                                                                                          2. 0

                                                                                            I liked it a lot. Some things resonated and it was much more substantive and thoughtful than the usual bullshit that gets posted in this space and clutters up the front page of HackerNews-y sites.

                                                                                          1. 2

                                                                                            I feel strange but I still have not seen one good use case for block chain. I also consider them unsuitable for money. Give the people with most computing resources (or memory or whatever) the biggest say, just seems silly and a waste of sad resources.

                                                                                            you can use conventional cryptography to require a subset of multiple predetermined parties to undersign a transaction. you can also design a way to change the allowed parties.

                                                                                            1. 3

                                                                                              this is a tough question and I cannot give you a good answer.

                                                                                              But: let him take a short take home project. I disagree that it isn’t useful. You are specifically searching for someone who knows library internals. I am always surprised how many “experienced senior devs” can’t code.

                                                                                              I would also ask him how he’d solve some real challenge that you currently have. It is very insightful already. Does he understands your concerns, the technology? Can he adapt to pragmatic “startup” mode? Can he sell his approach to you? is he pleasant to talk to? how does he handle disagreement?

                                                                                              1. 2

                                                                                                I feel weird about this. Usually, I agree with Julia Reda, but in this case she (and many others) seems hyperbolic.

                                                                                                France’s and Germany’s compromise on Article 13 still calls for nearly everything we post or share online to require prior permission by “censorship machines”, algorithms that are fundamentally unable to distinguish between copyright infringement and legal works such as parody and critique.

                                                                                                I believe there will be an industry of snake oil censorship machine services which will rubber stamp uploads. Some additional costs but not really harmful to anybody.

                                                                                                It would change the web from a place where we can express ourselves (with some moderation applied after-the-fact on platforms) into one where big corporate rightholders are the gatekeepers of what can and can’t be published in the first place. It would allow these rightholders to bully any commercial site or app that includes a posting function.

                                                                                                So it will be more notes like Youtubes “Not available in your country”. I too find these annoying, but I believe the long term effect would actually be more diversity since there will be more locally reproduced/derived stuff.

                                                                                                European innovation on the web would be discouraged by the new costs and legal risks for startups – even if they only apply when platforms turn 3 years old, or achieve some success. Foreign sites and apps who can’t afford armies of lawyers would be incentivised to just geoblock all EU-based users to be on the safe side.

                                                                                                Startups outsource their emails to mailgun, their payments to paypal, and they will outsource upload filtering to some other company. That other company will promote its “state of the art filter AI”, so the startup has undertaken “best efforts” to comply.

                                                                                                I don’t find Article 13 worth the ruckus.

                                                                                                Maybe it will even encourage people to self-host more?

                                                                                                1. 3

                                                                                                  Costing more hurts the poor, that’s generally the downside. It doesn’t hurt wealthy people.

                                                                                                  1. 1

                                                                                                    Every site (at least if it wants to operate more than three years) that allows freedom of expression in the form of videos, images, text (?) must run these through a filter. Developing such technology is difficult, so they need to integrate with other services - basically distributing their users content to another service provider. A privacy nightmare. Also, it is very easy to overlook for small businesses and even with 3rd party providers cumbersome and it cuts into the profits. it will be relatively extensive -lots of data, complex technology.

                                                                                                    Who will profit? Mostly big content distributors that upload the reference material.

                                                                                                    it is not good for 99.999% of EU citizens, it should not be law.

                                                                                                    The incentive to filter too much rather than too few uploads is also worrying.

                                                                                                  1. 3

                                                                                                    Thank you for posting this.

                                                                                                    I struggle with really the same problems as the author in the article, just that I do not even have side clients.

                                                                                                    1. 1

                                                                                                      Nice overall summary. I cannot refrain from commenting, though, that calling build times “fast” is very relative. They are fast when you consider that they include an up-to-date check of your compiler. In practice, if I rebase my WIP on head (which happens multiple times a day), I have to wait minutes for the new build again. Even if it is for a unit test. Incremental changes are also not blazingly fast but there is usually a delay of ~10s, even for a simple unit test change.

                                                                                                      1. 4

                                                                                                        Great to see all these offers of help! It would be interesting if you could sum up the “findings” if they lead to success.

                                                                                                        All the best!

                                                                                                        1. 1

                                                                                                          Good point! I’ll do my best :)