Threads for Blintk

  1. 23

    I think size of the program, and the team maintaining it, is an important factor in the static vs dynamic discussion.

    I’m in the “I don’t make type errors, and if I do, I can shake them out with a few tests” camp for as long as I can comprehend what’s going on in the codebase.

    But when the code grows to the point I can no longer remember where everything is, e.g. I can’t find all callers of a function, dynamism starts to become a burden. When I need to change a field of a struct, I have to find all uses of the field, because every missed one is a bug that’s going to show up later. At some point that becomes hard to grep for, and even impossible to account for in reflection-like code. It can degrade to a bug whack-a-mole, promote more and more defensive programming patterns, and eventually fear of change.

    I’ve had good experiences with gradually-typed languages. They stretch this “size limit” of a program a lot, while still allowing use of duck typing where it helps, without bringing complexity of generic type systems.

    1. 9

      “Dynamic typing falls apart with large team/large codebase” is one of those cliché arguments that doesn’t really contribute usefully, though.

      Also your presentation of it has multiple issues:

      • Large team/large codebase projects fail all the time regardless of typing discipline. Static typing doesn’t appear to have a better track record of success there.
      • Tooling for dynamically-typed languages has come a long way in the decades since this argument was first raised. You can just get an IDE and tell it to track down and rename references for you. And if your complaint is that it’s harder/impossible to do through “reflection-like code”, well, people can write metaprogram-y reflection stuff in statically-typed languages too.
      • Ultimately, if your codebase has lots of functions or methods that are called from huge numbers of disparate places, to such a degree that you can’t safely work with it without an IDE doing full static analysis to track them all for you, that’s a code smell in any language, in any typing discipline.
      1. 15

        Static languages can verify all metaprogramming is type correct. IDE heuristics can not. In Rust you can write a macro and the compiler will expand and type check it. That kind of stuff is impossible in dynamic languages.

        1. 7

          Static languages can verify all metaprogramming is type correct.

          This is probably going to get off-topic into arguing about the exact definition of “statically-typed”, but: I think that if you venture outside of languages like Rust (which seem to deliberately limit metaprogramming features precisely to be able to provide guarantees about the subset they expose), you’lll find that several languages’ guarantees about ahead-of-time correctness checks start being relaxed when using metaprogramming, runtime code loading, and other “dynamic-style” features. Java, for example, cannot actually make guarantees as strong as you seem to want, and for this among other reasons the JVM itself is sometimes referred to as the world’s most advanced dynamically-typed language runtime.

          There also are plenty of things that seem simple but that you basically can’t do correctly in statically-typed languages without completely giving up on the type system. Truly generic JSON parsers, for example. Sure, you can parse JSON in a statically-typed language, but you either have to tightly couple your program to the specific structures you’ve planned in advance to handle (and throw runtime errors if you receive anything else), or parse into values of such ultra-generic “JSON object” types that the compiler and type system no longer are any help to you, and you’re effectively writing dynamically-typed code.

          1.  

            for this among other reasons the JVM itself is sometimes referred to as the world’s most advanced dynamically-typed language runtime

            Aren’t runtimes always “dynamically typed”? What does it mean for a runtime to be “statically typed”?

            or parse into values of such ultra-generic “JSON object” types that the compiler and type system no longer are any help to you, and you’re effectively writing dynamically-typed code.

            It sounds like you’re arguing that the worst case for static type systems is equivalent to the best case for dynamic type systems, which doesn’t seem like a ringing endorsement for dynamic type systems. That said, I don’t even think this is true for this JSON-parsing example, because you could conceive of a generic JSON parser that has different unmarshaling strategies (strict, permissive, etc). Further, as static type systems are adopted more widely, this sort of poorly-structured data becomes rarer.

            1.  

              Aren’t runtimes always “dynamically typed”?

              Some more so than others. Rust, for all its complexity as a language, is mostly shoving that complexity onto the compiler in hopes of keeping the runtime relatively simple and fast, because the runtime doesn’t have to do quite as much work when it trusts that there are classes of things the compiler simply prevents in advance (the runtime still does some work, of course, just not as much, which is the point).

              But a language like Java, with runtime code loading and code injection, runtime reflection and introspection, runtime creation of a wide variety of things, etc. etc. does not get to trust the compiler as much and has to spend some runtime cycles on type-checking to ensure no rules are being broken (and it’s not terribly hard to deliberately write Java programs that will crash with runtime type errors, if you want to).

              That said, I don’t even think this is true for this JSON-parsing example, because you could conceive of a generic JSON parser that has different unmarshaling strategies (strict, permissive, etc).

              If you want truly generic parsing, you’re stuck doing things that the compiler can’t really help you with. I’ve seen even people who are quite adept at Haskell give up and effectively build a little subset of the program where everything is of a single JSON type, which is close enough to being dynamically typed as makes no difference.

              Further, as static type systems are adopted more widely, this sort of poorly-structured data becomes rarer.

              My experience of having done backend web development across multiple decades is that poorly-structured data isn’t going away anytime soon, and any strategy which relies on wishing poorly-structured data out of existence is going to fail.

              1.  

                Aren’t runtimes always “dynamically typed”?

                If you eschew these needlessly binary categories of static vs dynamic and see everything on a scale of dynamism then I think you’ll agree that runtimes are scattered across that spectrum. Many even shift around on that spectrum over time. For example, if you look at the history of JSR 292 for adding invokedynamic to the JVM you’ll find a lot of cases where the JVM used to be a lot less dynamically typed than it is today.

              2.  

                There’s no reason you can’t parse a set of known JSON fields into static members and throw the rest into an ultra-generic JSON object.

                1.  

                  Those are the options I said are available, yes.

                2.  

                  Dynlangs are definitely better for data that isn’t structured as well.

                  C#’s dynamic keyword feels like a perfect fit for this situation without having to give up static typing everywhere else. Hejlsberg is ahead of the curve, per usual.

              3.  

                Fail is too harsh. Unless you’re writing some rocket navigation system, a project is not going to outright fail because of software defects. Run-time type errors merely add to other bugs that you will need to fix, and I argue that bugs caused by runtime type errors are less of a problem in small programs.

                I don’t know of any robust tooling for refactoring large JavaScript projects. Of course most languages have some type-system escape hatches, but I expect languages like JS to use hard-to-analyze type-erasing constructs much more often.

                I disagree that having callers beyond your comprehension is automatically a code smell. It’s a natural state of things for libraries, for example. Ideally libraries should have a stable API and never change it, but it’s not always that easy, especially for internal libraries and reusable core pieces of large projects that may need to evolve with the project.

                It’s not just about IDEs. Compilation will also track down all type errors for you, regardless of where and when these errors happen. When working with teams, it may be someone else working on some other component. In this case the types are a way to communicate and coordinate with others.

                You can make a mess in any language, but how easy is to make a mess varies between languages. Languages that prevent more errors will resist the mess for longer.

                1.  

                  I expect languages like JS to use hard-to-analyze type-erasing constructs much more often.

                  Why do you expect this?

                  I disagree that having callers beyond your comprehension is automatically a code smell.

                  Even if it’s an internal library, why don’t other internal codebases have a single clear integration point with it? And why does everything else need to have lots of knowledge of the library’s structure? This definitely is a code smell to me – the Law of Demeter, at least, is being violated somewhere, and probably other design principles too.

                  Languages that prevent more errors will resist the mess for longer.

                  This is veering off into another clichéd and well-trod argument (“static typing catches/prevents more bugs”). I’ll just point out that while proponents of static typing often seem to take it as a self-evident truth, actually demonstrating its truth empirically has turned out to be, at the very least, extremely difficult. Which is to say: nobody’s managed it, despite it being such an “obvious” fact, and everybody who’s tried has run into methodological problems, or failed to prove any sort of meaningful effect size, or both.

                  1.  

                    Why do you expect this?

                    Because the flexibility is a benefit of dynamic languages. If you try to write code as-if it was strongly statically typed, you’re missing out on the convenience of writing these things “informally”, and you’re not getting compiler help to consistently stick to the rigid form.

                    why don’t other internal codebases have a single clear integration point with it?

                    The comprehension problems I’m talking about that appear in large programs also have a curse of being hard to explain succinctly in a comment like this. This is very context-dependent, and for every small example it’s easy to say the problem is obvious, and a fix is easy. But in larger programs these problems are harder to spot, and changes required may be bigger. Maybe the code is a mess, maybe the tech debt was justified or maybe not. Maybe there are backwards-compat constraints, interoperability with something that you can’t change, legacy codebase nobody has time to refactor. Maybe a domain-specific problem that really needs to be handled in lots of places. Maybe code is weirdly-shaped for performance reasons.

                    The closest analogy I can think of is “Where’s Waldo?” game. If I show you a small Waldo picture, you’ll say the game is super easy, and obviously he’s right here. But the same problem in a large poster format is hard.

                    1.  

                      Because the flexibility is a benefit of dynamic languages. If you try to write code as-if it was strongly statically typed, you’re missing out on the convenience of writing these things “informally”, and you’re not getting compiler help to consistently stick to the rigid form.

                      I see most typing errors as self-inflicted wounds at this point. Don’t have time or patience for things that can be prevented by the compiler happening at runtime.

                      Dynlangs + webdev together is my kryptonite. If I had to do that all day I’d probably start looking for a new career. Just can’t deal with it.

                      1.  

                        Because the flexibility is a benefit of dynamic languages. If you try to write code as-if it was strongly statically typed, you’re missing out on the convenience of writing these things “informally”, and you’re not getting compiler help to consistently stick to the rigid form.

                        You are once again assuming that statically-typed languages catch/prevent more errors, which I’ve already pointed out is a perilous assumption that nobody’s actually managed to prove rigorously (and not for lack of trying).

                        Also, the explanation you give still doesn’t really make sense. Go look at some typical Python code, for example – Python’s metaprogramming features are rarely used and their use tends to be discouraged, and easily >99% of all real-world Python code is just straightforward with no fancy dynamic tricks. People don’t choose dynamic typing because they intend to do those dynamic tricks all the time. They choose dynamic typing (in part) because having that tool in the toolbox, for the cases when you need it or it’s the quickest/most straightforward way to accomplish a task, is incredibly useful.

                        The comprehension problems I’m talking about that appear in large programs also have a curse of being hard to explain succinctly in a comment like this

                        Please assume that I’ve worked on large codebases maintained by many programmers, because I have.

                        And I’ve seen how they tend to grow into balls of spaghetti with strands of coupling running everywhere. Static typing certainly doesn’t prevent that, and I stand by my assertion that it’s a code smell when something is being called from so many disparate places that you struggle to keep track of them, because it is a code smell. And there are plenty of patterns for preventing it, none of which have to do with typing discipline, and which are well-known and well-understood (most commonly, wrapping an internal interface around a library and requiring all other consumers in the codebase to go through the wrapper, so that the consuming codebase controls the interface it sees and has onlyu a single point to update if the library changes).

                  2.  

                    Large team/large codebase projects fail all the time regardless of typing discipline. Static typing doesn’t appear to have a better track record of success there.

                    Yes, projects can fail for lots of reasons; no one is claiming that static typing will make a shitty idea commercially successful, for example :) But I do think static types help a lot within their narrow scope–keeping code maintainable, reducing bugs, preserving development velocity, etc. Of course, there’s no good empirical research on this, so we’re just going off of our collective experiences. 🤷‍♂️

                  3. 12

                    I always laugh when I see ruby code where the start of the method is a bunch of “raise unless foo.is_a? String”. The poor mans type checking all over the place really highlights how unsuitable these dynamic languages are for real world use.

                    1. 6

                      To be fair, any use of is_a? in ruby is a code smell

                      1. 10

                        Sure, it’s also a pattern I have seen in every Ruby codebase I have ever worked with because the desire to know what types you are actually working with is somewhat important for code that works correctly.

                        1. 5

                          Yeah, the need for ruby devs is much larger than the supply of good ones or even ones good enough to train the others. I’ve seen whole large ruby codebases obviously written by Java and C++ devs who never got ruby mentoring. I expect this is an industry wide problem in many stacks

                      2.  

                        You seem to just be trolling, but I’ll play along, I guess.

                        I’ve seen a bit of Ruby, and a lot of Python and JavaScript, and I’ve never seen this except for code written by people who were coming from statically-typed languages and thought that was how everyone does dynamic typing. They usually get straightened out pretty quickly.

                        Can you point to some examples of popular Ruby codebases which are written this way? Or any verifiable evidence for your claim that dynamic languages are “unsuitable… for real world use”?

                        1. 5

                          I’m not trolling at all. I’ve been a Rails dev for the last 7 years and seen the same thing at every company. I don’t work on any open source code so I can’t point you at anything.

                          I quite like Rails but I’m of the opinion that the lack of static type checking is a serious deficiency. Updating Rails itself is an absolute nightmare task where even the official upgrade guide admits the only way to proceed is to have unit tests on every single part of the codebase because there is no way you can properly verify you have seen everything that needs to change. I’ve spent a large chunk of time spanning this whole year working towards updating from Rails 5.1 to 5.2. No one else dared attempt it before I joined because it’s so extremely risky.

                          I love a lot of things about Rails and the everything included design but I don’t see a single benefit to lacking types. Personally I see TypeScript as taking over this space once the frameworks become a little more mature.

                          1.  

                            You made a very specific assertion about how people write Ruby (lots of manual type-checking assertions). You should be able to back up that assertion with pointers to the public repositories of popular projects written in that style.

                            1. 7

                              I remembered hearing from my then-partner that Rails itself uses a lot of is_a?, and that seems true.

                               if status.is_a?(Hash)
                                      raise ArgumentError, etc...
                              
                              1.  

                                This is pretty misleading – a quick glance at some of the examples seems like many of them aren’t really checking argument types, and when they are, they’re often cases where a method accepts any of multiple types, and there’s branching logic to handle the different options.

                                Which is something you’d also see in a statically-typed language with sum types.

                                The proposition that this is a common idiom used solely as a replacement for static checking is thus stil unproved.

                              2.  

                                ill concur with GP: this is a fairly common pattern to see in ruby codebases.

                                however, to be fair, it’sa pattern most often introduced after attending a talk by a static typing weenie…

                          2.  

                            Do you also laugh when you see “assert(x > 0);” in typed languages?

                            1.  

                              I would, but it would be a sad laugh because I’m using a type system that can’t express a non-zero integer.

                              1.  

                                I would love to see broader adaptation of refinement types that let you statically guarantee properties like integer values being bound between specific values.

                            2.  

                              I’m in the Type everything if it’s even kinda big camp now. There are too many things I need to think about during the day to remember the state and usage of every variable of every program I’ve ever written, used or inspected. Typings are rails for my logic. Typings are documentation. Types help my IDE help me. I will take every single shortcut I can when the timespan I or anyone else could be interacting with the code is longer than 10 minutes.

                              Retracing steps is just so tedious and frustrating when you had it all in your head before. It just sucks. I just wanna build stuff, not fill my head with crap my computer can do.

                              /rant

                              1.  

                                I’m in the “I don’t make type errors, and if I do, I can shake them out with a few tests” camp for as long as I can comprehend what’s going on in the codebase.

                                This is generally true for me, but writing tests or debugging stack traces makes for a slow iteration loop. A type error from a compiler usually contains better, more direct information so resolving these type errors is a lot faster. To the extent that I (a 15 year Pythonista) eventually began to prototype in Go.

                                That said, the biggest advantage for me for a static type checker is that it penalizes a lot of the crappy dynamic code (even the stuff that is technically correct but impossible to maintain/extend over time). A static type system serves as “rails” for less scrupulous team members. Of course, a lot of these less-scrupulous developers perceive this friction as a problem with static type systems rather than a problem with the way they hacked together their code, but I think Mypy and TypeScript have persuaded many of these developers over time to the extent that static types are much less controversial in most dynamic language communities.

                                Another big advantage is that your type documentation is always correct and precise (whereas docs in a dynamically typed language often go stale or simply describe something as “a file-like object” [does that mean it just has a read() method, or does it also need write(), close(), seek(), truncate(), etc?]). Further, because the type docs are precise, you can have thinks like https://pkg.go.dev complete with links to related types, even if those types are declared in another package, and you get all of this for free.

                              1. 66

                                I read this and felt weird about it initially but couldn’t quite put my finger on it. From my experience, using Rust has lead to faster developer velocity (even for CRUD apps) simply because the strong type system allows you to encode invariants to be checked at compile time, and the tooling and libraries are amazing. This article seems to be about a project that was being developed right around async/await release, which was a rough time for using libraries. Most of the sharp edges are gone now, but I don’t doubt that the state of the ecosystem at that point affected this person’s experience.

                                However, I do think there is a situation where this advice holds true (even for someone as heavily biased as I am), which is for a very specific kind of startup: a hyper-growth startup with 100%+ YoY engineer hiring. The issue with Rust is not that its slower to develop in, I don’t think that is true, its that in order to develop quickly in Rust you have to program in Rust. And frankly, most new developers to Rust have no idea how to program in Rust because so many languages do not feature strong type systems. And the problem is that if your influx of new developers who need to learn Rust is too large, you won’t be able to properly onboard them. Trying to write Java using Rust is horrible (I’ve worked with a number of colleagues who I’ve had to gently steer away from OO design patterns that they were used to, simply because they make for really difficult Rust code, and are largely obsoleted by the type system).

                                It isn’t even lifetimes or borrowing that are necessarily tricky, in my experience issues with lifetimes are fairly rare for people and they almost always immediately seek out an experienced Rust dev for guidance (you only need a handful to deal with all questions on Lifetimes; my current team only has me and its been a non-issue). The bigger problems are around how to structure code. Type-driven development is not something most people have experience with, so they tend to stick to really simple Structs and Enums, to their detriment.

                                For instance, I commonly see new Rust developers doing something like this:

                                fn double_or_multiply(x: i32, y: Option<i32>, double: bool) -> Result<i32> {
                                    if double {
                                        if y.is_some() {
                                            return Err("Y should not be set");
                                        }
                                        x * 2
                                    } else {
                                        if y.is_none() {
                                             return Err("Y should be set");
                                        }
                                        x * y.unwrap()
                                    }
                                }
                                

                                Yes, I know its a completely contrived example, but I’m sure you’re familiar with that kind of pattern in code. The issue is that this is using the shallow aspects of Rust’s type system – you end up paying for all of Rust but only reaping the benefits of 10% of it. Compare that to what you could do by leveraging the type system fully:

                                enum OpKind {
                                   Double(x),
                                   Multiply(x, y),
                                }
                                
                                fn double_or_multiply(input: OpKind) -> i32 {
                                    match input {
                                         Double(x) => x * 2,
                                         Multiply(x, y) => x * y,
                                    }
                                }
                                

                                Note how the error has disappeared as there is no way to call this function improperly. That means fewer tests to write, less code to maintain, and APIs that can’t be used improperly. One of the most interesting questions I get commonly when I promote this style of code is “how do I test that it fails then?”; its always fun to explain that it can’t fail[1] and there is no need to write a test for the failure. The developer efficiency benefits from this style of thinking everywhere is massive and more than pays for the cost of using Rust.

                                But developers from other languages take time to get to this point, and it does take time and effort from experienced Rust developers to get everyone on the same page. Too many new people and I can see more and more code leaking in as the first example, which means you get minimal benefits of Rust with all the cost.

                                I can’t argue with this person’s experience, as much as I love Rust and think it has features that make it an incredibly productive language, but I think the core issue is that the majority of developers do not have experience with strong type-system thinking. As more languages start adding types I’m hopeful this problem becomes less prevalent, because the productivity differences between developers who understand type-driven development vs. those who don’t is large (in languages with strong type-systems).

                                [1] Technically it can panic, which I do explain, but for the majority of cases that is a non-issue. Generally if there is a panic-situation that you think you might have to handle you use a different method/function which returns a Result and bubble that up. Panics are largely unhandled (and for good reason; they aren’t exceptions and should be considered major bugs).

                                1. 10

                                  FWIW Matt Welsh is a very experienced programmer and former computer science professor at Harvard:

                                  https://en.wikipedia.org/wiki/Matt_Welsh_(computer_scientist)

                                  (I know of him from his research on SEDA, an influential web server architecture, as well as having a good blog.)

                                  So this comments strikes me as a bit out in left field … I don’t doubt it’s your experience, but it doesn’t seem relevant to the article

                                  1. 8

                                    I’m not familiar with who Matt Welsh is, but I found his post to be well written and accurate to his experience. My comment was simply a reflection of my own experience, which I think differs.

                                    I don’t see how my comment isn’t relevant to the article, but I am open to feedback if there is something specific you felt made my comment out of left field!

                                    1. 7

                                      Not GP, and I hope this doesn’t come off as too negative, but your comment is pretty dismissive of the idea that Matt Welsh could have substantive issues with the design of Rust. You seem to imply that the problems he ran into stem from a lack of experience:

                                      I think the core issue is that the majority of developers do not have experience with strong type-system thinking.

                                      Your example about double_or_multiply is great, but IMO it’s a pretty elementary example for most readers here, as well as Matt Welsh.

                                      The general vibe is like this: someone complains that a particular proof in graduate-level mathematics is hard to read, and then you respond with a tutorial on pre-calculus. I like your comment, and it is relevant, but it doesn’t feel like it responds to the article, or takes the author seriously.

                                      1. 4

                                        Thanks for the explanation, I do appreciate it. I hoped to not make my comment be dismissive of the article, and more as a refinement of which aspect it was talking about. I think the fundamental issue is that I completely disagree with Matt Welsh that programming in Rust lowers developer efficiency, and so my comment was exploring a reason for why he may feel that way.

                                        The example was simple, and more just for having something to ground my argument in (ie. Rust makes you faster because you write less code overall), as well as having something for developers who are unfamiliar with type-driven development to see. I didn’t mean to imply it as Matt Welsh doesn’t know that, but more that type-driven development is a completely different style of programming, and onboarding devs to a new language is easy but to a new style is hard.

                                        Clearly my point wasn’t made as clear as I had hoped, and thank you for pointing out where it felt like I was off-base. I do think it’s important to disagree, and I’ve never been one to defer to another just because of their accomplishments or prestige.

                                        I’m thinking it might make sense for me to write my own post on my thoughts on developing quickly in Rust, and hopefully I can take these ideas and your feedback and make something that pushes the conversation forward on what makes a productive language without coming across as dismissive of others experience :)

                                        1. 1

                                          You:

                                          …a hyper-growth startup with 100%+ YoY engineer hiring… in order to develop quickly in Rust you have to program in Rust. And frankly, most new developers to Rust have no idea how to program in Rust because so many languages do not feature strong type systems. And the problem is that if your influx of new developers who need to learn Rust is too large, you won’t be able to properly onboard them.

                                          Matt:

                                          We hired a ton of people during my time at this company, but only about two or three of the 60+ people that joined the engineering team had previous experience with Rust.

                                          This was in two years, which he claims was 10x growth in headcount, so from ~6 people to 60 in two years, with only 3 people who knew Rust. Basically, well above your 100% YoY hiring threshold for being able to onboard Rust engineers.

                                          You:

                                          I completely disagree with Matt Welsh that programming in Rust lowers developer efficiency

                                          I don’t think you do disagree with him :)

                                          My interpretation of his claim is that in a rapidly growing organisation that needs to ship product rapidly, and where you don’t have a lot of Rust expertise already, Rust may not be a good fit. What you are claiming is that given enough experience with Rust, it can accelerate your day to day development. But that to do so you need to give developers sufficient time to onboard to Rust such that they can become familiar and efficient with it (which of course is true for any language, but Rust onboarding likely takes a lot longer than, say, Go, or Python, or C#).

                                          Both of these claims can be true because they are discussing different aspects of software engineering at different scales.

                                          Related, I’d be interested in hearing what your experience has been on how long it takes to onboard a complete Rust novice, to the point they are at close to 100% productivity.

                                          1. 2

                                            My interpretation of his claim is that in a rapidly growing organisation that needs to ship product rapidly, and where you don’t have a lot of Rust expertise already, Rust may not be a good fit.

                                            You’re right, I do agree with this claim. My understanding of Matt’s article is that he argues this is a function of Rust as a language, whereas I argue this is a function of a general lack of understanding of type-driven programming.

                                            It is effectively semantics, but important semantics, because I don’t think the solution is to avoid using Rust/Haskell/OCaml/etc except in niche situations, it should be to educate developers in type-driven development. But of course that is a much bigger problem, and not easy, so I can see where one might think I’m just arguing a point entirely separate from what the article is talking about.

                                            I think you’re right, the point I am making is mostly tangential, and I could have made that more clear. Thanks for explaining your view!

                                            Related, I’d be interested in hearing what your experience has been on how long it takes to onboard a complete Rust novice, to the point they are at close to 100% productivity.

                                            I’ll take the easy way out and say it depends :P but it is hard to put an exact number on it simply because I don’t have a ton of data to really say. Rust is still fairly niche, even at companies using it (ie. Rust for core services, but most devs work on services in other langs talking to the Rust core), and usually devs wanting to work on the Rust stuff already know Rust to an extent. My current team is getting ~6 or 7 devs without Rust experience next quarter (who have no idea they’ll be working in Rust) so hopefully I’ll have much better data soon! (Absurd bureaucratic policies maybe have good side effects)

                                            From my limited experience onboarding people with no Rust experience, I’ve seen devs without type-driven design experience pick up a productive level in two to three months (including new-grads), but take a lot longer to get to being comfortable with using the type system to its full power (maybe a year to get mostly comfortable, but still have gaps). However, they’ve largely been passionate and qualified devs I’ve worked with (even the ones that were new-grads), so I think my opinion is biased here.

                                            I’d guess that a developer with strong type system experience can pick up a near 100% productivity in a few weeks, but I have yet to onboard a dev with this background who doesn’t already know Rust, so this is largely from my own experience learning Rust and talking to others.

                                            I really wish I had experience with a hyper growth startup using Rust, and seeing first-hand the failure modes onboarding that many people to Rust. But I agree with Matt’s assessment that it’s the wrong language for that situation given the average software developer’s experience, and I have my doubts about the efficacy of hyper growth startups in the first place.

                                  2. 8

                                    On a related note, I’m very curious to see what happens with the recent Twitter situation. If Twitter manages to thrive, I think many companies are going to take notice and cut back on developers. The easy pay-day for software engineers could be at an end, and fewer developers will have to handle larger and larger systems. In that case, I’d imagine building things which are robust will outweigh building things quickly. If you have 10% the number of engineers you want to minimize the amount of incident response you are doing (1 out of 100 devs dealing with oncall every week is very different from 1 out of 10 devs dealing with oncall every week in terms of productivity; now the buggy systems have a 10% hit on productivity rather than 1%).

                                    I’m both worried (large scale cutbacks to mimic Twitter would not be fun) but also somewhat optimistic that it would lead to more reliable systems overall. Counter-intuitively, I think Rust/Haskell/Ocaml and friends would thrive in that world, as choosing a language for quick onboarding of hundreds of devs is no longer a constraint.

                                    1. 19

                                      I draw the exact opposite conclusion:

                                      Tighter pursestrings mean less resources allocated to engineers screwing around playing with new languages and overengineering solutions to stave off boredom.

                                      There will probably be cases where a business truly uses Rust or something else to differentiate itself technically in performance or reliability, but the majority of folks will go with cheaper tooling with easier-to-replace developers.

                                      1. 11

                                        I agree. People will go where the libraries are. If you have 1/10 the number of people you aren’t going to spend your time reimplementing the AWS SDK. You are going to stick to the beaten path.

                                        1. 2

                                          I’m sure you meant that as more of a general example than a specific one, but: https://aws.amazon.com/about-aws/whats-new/2021/12/aws-sdk-rust-developer-preview/

                                          1. 1

                                            Yeah, I meant it generically. More niche languages are missing a lot of libraries. If you have fewer people you probably want to spend less time reinventing the wheel.

                                            I know for any one language people will probably come out of the wood work and say “I don’t run into any issues.” but it’s more about perception in the large.

                                        2. 2

                                          You make a really good point, and I’ve been mulling on it. My logic was based on the idea that if the software industry suddenly shrank to 10% of its size, the engineers maintaining buggy systems would burn out, while those maintaining robust systems would not. Sort of a forced evolution-by-burnout.

                                          But I think you’re right, tighter purse strings means less experimentation, so the tried-and-true would benefit. So who knows! Hopefully it’s not something we will ever learn the answer to :)

                                          1. 2

                                            The department I run, after over 50% casualty rate this year, has made it a major focus to consolidate, simplify, and emphasize better-documented and smaller systems specifically to handle this. :)

                                            I hope it works out, but these are going to be interesting times whatever happens. I just personally wish engineers in tech as a culture hadn’t overplayed their hand.

                                        3. 5

                                          I can probably set your mind at ease about Twitter (but not the other tech companies having layoffs, nor the new management there who is utterly clueless). Since at least 2009, Twitter’s implicit/unspoken policy was that engineers are cheaper than machines. In other words, it’s more cost-effective to hire a team to optimize the bejeezus out of some service or another, if they can end up cutting server load by 10%. If their policy was based on any real financial data (I have no idea), good dev and devops people will continue to be in high demand, if only to reduce overall machine costs.

                                        4. 3

                                          Any recommend way to learn about that from your experience (except than being lucky enough to have an experienced Rust programmer to help you out)?

                                          Maybe something like exercise.org?

                                          1. 4

                                            I’m a fan of trial-by-fire, and if you really want to understand type-driven development then learning and using Haskell is what I’d recommend. Rust is a weird language because it seems really novel, but it really only has the ownership model as unique (and even then, Ada + spark had it first). Everything else is just the best bits borrowed from other languages.

                                            Haskell’s type system is more powerful, and the docs for libraries heavily lean into the types-as-documentation. I’m not good enough at Haskell to write production software in it, but getting to that “aha!” moment with the language has paid dividends in using Rust effectively.

                                            1. 3

                                              Rust is a weird language because it seems really novel, but it really only has the ownership model as unique (and even then, Ada + spark had it first

                                              Ada/SPARK did not have Rust’s affine types ownership model.

                                            2. 4

                                              Just wanted to mention that it is actually https://exercism.org for others’ sake. Didn’t want to let that go unnoticed as it is a wonderful platform for learning!

                                              1. 2

                                                Elm! If you want a beginner-friendly way to epiphany, work through the Elm tutorial. That was my first, visceral, experience of the joy of sum types / zero runtime errors / a compiler that always has my back.

                                                Why via Elm? Because it’s a small and simple language that is user-friendly in every fibre of its being. This leaves you with lots of brain cycles to play with sum types.

                                                • Friendly error messages that always give you hints on what to do next. (Elms error messages were so spectacularly good, and that goodness was so novel, that for a while there was a whole buzz in all sorts of language communities saying “our error messages should be more like Elm’s”. Rust may be the most prominent success.)
                                                • You’re building a web page, something you can see and interact with.
                                                • Reliable refactoring, if your refactor is incomplete the compiler will tell you.
                                              2. 2

                                                fn double_or_multiply(x: i32, y: Option, double: bool)

                                                my 2c: I know it’s a contrived example, but even outside of rust it’s generally (not always) a bad idea (e.g. it’s a code smell) to have a function that does different thing based on a boolean.

                                                Also, a good linter/code review should help with the kind of issue you’re pointing to.

                                                1. 2

                                                  In hopes it’s instructive, your code samples are an instance of parse don’t validate where you push all your error checking logic to one place in the code.

                                                  1. 3

                                                    Yes it is :) I’m a huge fan of that article, though I’ve found it can sometimes be difficult for someone who isn’t familiar with strong types already. Thank you for sharing the link, I think it’s a great resource for anyone interested in reading more!

                                                  2. 1

                                                    I’m new to Rust, could you provide an example of calling your second function? I’ve only just passed the enum chapter of the book and that is the exact chapter that made me excited about working with Rust.

                                                    1. 7

                                                      Of course! You would call it like so:

                                                      double_or_multiply(OpKind::Double(33));
                                                      
                                                      double_or_multiply(OpKind::Multiply(33, 22));
                                                      

                                                      Its good to hear your excitement from enums in Rust, as I think they are an under-appreciated aspect of the language. Combining structs + enums is super powerful for removing invalid inputs, especially nesting them into each other. The way I think about designing any API is: how can I structure the input the user supplies such that they can’t pass in something incorrect?

                                                      I wish I could find a source for how to design APIs, as there is some place out there which lists the different levels of quality of an API:

                                                      • low: the obvious way to use the API is incorrect, hard to use correctly
                                                      • medium: can be used incorrectly or correctly
                                                      • high: the obvious way to use the API is correct, hard to use incorrectly
                                                      • best: no way to incorrectly use the API, easy to use correctly
                                                      1. 6

                                                        You may be thinking of Rusty Russell’s API design levels.

                                                        1. 1

                                                          Yes! That was exactly what I was looking for, thank you!

                                                      2. 3
                                                        double_or_multiply(Double(2)) // = 2*x = 4
                                                        // Or
                                                        double_or_multiply(Multiply(3,7)) // = 3 * 7 = 21
                                                        
                                                      3. 1

                                                        Can you explain how it could panic?

                                                        1. 2

                                                          Multiplication overflow, which actually would only happen in debug mode (or release with overflow checks enabled). So in practice it likely couldn’t panic (usually nobody turns on overflow checks) (see below)

                                                          1. 6

                                                            It’s not that uncommon. Overflow checks are generally off because of perceived bad performance, but companies interested in correctness favor a crash over wrapping. Example: Google Android…

                                                            https://source.android.com/docs/setup/build/rust/building-rust-modules/overview

                                                            Overflow checking is on by default in Android for Rust, which requires overflow operations to be explicit.

                                                            1. 2

                                                              I stand corrected! I’m curious what the performance impact is, especially in hot loops. Though I imagine LLVM trickery eliminates a lot of overflow checks even with them enabled

                                                              1. 2

                                                                I remember numbers flying around on Twitter, most of what I hear is that it is in neglectible ranges. Particularly that if it becomes a problem, there‘s API for actually doing wrapping ops.

                                                                Sadly, as often, I can‘t find a structured document that outlines this, even after a bit of searching. Sorry, I‘d love if I had more.

                                                            2. 1

                                                              So, it’s specific for this example, if the enum was over structs with different types and the function did something else, it wouldn’t necessarily panic, right?

                                                              Is there a way to make this design panic-proof?

                                                              1. 5

                                                                Yes, the panicking is specific to the example. And you can make it panic-proof if none of the function calls within can panic. IIRC its still an open design problem of how to mark functions as “no panic” in rust so the compiler checks it [1][2]. There are some libraries to do some amount of panic-proofing at compile-time[3] but I haven’t used them. I thought there was a larger RFC ticket for the no-panic attribute but I can’t find it right now.

                                                                [1] https://github.com/rust-lang/project-error-handling/issues/49 [2] https://github.com/rust-embedded/wg/issues/551 [3] https://crates.io/crates/no-panic

                                                        1. 4

                                                          Every single time I read stuff like this I always end up with the question of “How?”. I played around with ida when I was younger and could never get into it. I’m always impressed.

                                                          1. 3

                                                            Lot of practice and knowing the general area. Marcan has been working on porting to different architectures and drivers a few times before. His streams are interesting if you’re into that kind of thing https://youtube.com/c/marcan42

                                                          1. 7

                                                            This is honestly the only thing that’s been holding me back from making anything in rust. Now that it’s going into GCC there’s probably going to be a spec and hopefully slower and more stabler development. I don’t know what’s going to come after rust but I can’t find much of a reason to not jump ship from C++ anymore.

                                                            1. 33

                                                              I doubt a new GCC frontend will be the reason a spec emerges. I would expect a spec to result from the needs of the safety and certification industry (and there already are efforts in that direction: https://ferrous-systems.com/blog/ferrocene-language-specification/ ) instead.

                                                              1. 15

                                                                Thanks for highlighting that. We’re well on track to hit the committed release date (we’re in final polish, mainly making sure that the writing can be contributed to).

                                                              2. 6

                                                                hopefully slower and more stabler development

                                                                As per usual, slower and more stable development can be experienced but using the version of rust in your OS instead of whatever bleeding edge version upstream is shipping…

                                                                1. 1

                                                                  Unless one of your dependencies starts using new features as soon as possible.

                                                                  1. 4

                                                                    Which is the exact same problem even when using GCC Rust, so it’s not really a relevant argument.

                                                                    1. 4

                                                                      Stick with old version of dependency?

                                                                      1. 21

                                                                        Let’s be honest, Rust uses evergreen policy, the ecosystem and tooling follows it, and fighting it is needless pain.

                                                                        I still recommend to update the compiler regularly. HOWEVER, you don’t have to read the release notes. Just ignore whatever they say, and continue writing the code the way you used to. Rust keeps backwards compatibility.

                                                                        Also, I’d like to highlight that release cadence has very little to do with speed of language evolution or its stability. Rust features still take years to develop, and they’re just released on the next occasion. This says nothing about the number and scale of changes being developed.

                                                                        It’s like complaint that a pizza cut into 16 slices has too many calories, and you’d prefer it cut into 4 slices instead.

                                                                        1. 2

                                                                          The time it takes to stabilize a feature doesn’t really matter though if there are many many features in the pipeline at all times.

                                                                          1. 10

                                                                            Yup, that’s what I’m saying. Number of features in the pipeline is unrelated to release frequency. Rust could have a new stable release every day, and it wouldn’t give it more or less features.

                                                                        2. 3

                                                                          Do that, and now you’re responsible for doing security back-ports of every dependency. That’s potentially a lot more expensive than tracking newer releases.

                                                                          1. 13

                                                                            So then don’t do that and track the newer releases. Life is a series of tradeoffs, pick some.

                                                                            It just seems like a weird sense of entitlement at work here: “I don’t want to use the latest version of the compiler, and I don’t want to use older versions of dependencies because I don’t want to do any work to keep those dependencies secure. Instead I want the entire world to adopt my pace, regardless of what they’d prefer.”

                                                                            1. 1

                                                                              The problem with that view is that it devalues the whole ecosystem. You have two choices:

                                                                              • Pay a cost to keep updating your code because it breaks with newer compilers.
                                                                              • Pay a cost to back-port security fixes because the new version of your dependencies have moved to an incompatible version of the language.

                                                                              If these are the only choices then you have to pick one, but there’s always an implicit third choice:

                                                                              • Pick an ecosystem that values long-term stability.

                                                                              To give a couple of examples from projects that I’ve worked on:

                                                                              FreeBSD maintains very strong binary compatibility guarantees for C code. Kernel modules are expected to work with newer kernels within the same major revision and folks have to add padding to structures if they’re going to want to add fields later on. Userspace libraries in the base system all use symbol versioning, so functions can be deprecated, replaced with compat versions, and then hidden for linking by new programs. The C and C++ standards have both put a lot of effort into backwards compatibility. C++11 did have some syntactic breaks but they were fairly easy to mechanically fix (the main one was introducing user-defined string literals, which meant that you needed to insert spaces between string literals and macros in old code) but generally I can compile 10-20-year old code with the latest libraries and expect it to work. I can still compile C89 code with a C11 compiler. C23 will break C89 code that relies on some K&R features that were deprecated in 1989.

                                                                              Moving away from systems code and towards applications, GNUstep uses Objective-C, which uses late binding by default and (for the last 15 years or so) even extends this to instance variables (fields) in objects, so you don’t even have an ABI break if a library adds a field to a class that you subclass. Apple has been a bit more aggressive about deprecating things in their OpenStep implementation (Cocoa), but there are quite a few projects still around that started in 1988 as NeXTSTEP apps and have gradually evolved to be modern macOS / iOS apps, with a multi-year window to fix the use of features that were removed or redesigned in newer versions of Cocoa. You can still compile a program with XCode today that will run linked against a version of the Cocoa frameworks in an OS release several years old.

                                                                              The entitlement that you mention cuts both ways. If an ecosystem is saying ‘whatever you do, it’s going to be expensive, please come and contribute to the value of this ecosystem by releasing software in it!’ then my reaction will be ‘no thanks, I’ll keep contributing to places that value long-term stability because I want to spend my time adding new features, not playing catch up’.

                                                                              LLVM has the same rapid-code-churn view of the world as Rust and it costs the ecosystem a lot. There are a huge number of interesting features that were implemented on forks and weren’t able to be upstreamed because the codebase has churned so much underneath it that updating was too much work for the authors.

                                                                    2. 3

                                                                      Corroding codebases! this was my reason too for not switching from C++. Only last week I was thinking of dlang -betterC for my little “system programming” projects. It is now hard not to ignore rust. perhaps after one last attempt at learning ATS.

                                                                    1. 42

                                                                      I’m getting married :)

                                                                      1. 4

                                                                        Congrats!!! May you dodge the traditional post wedding covid and have much marital bliss.

                                                                        1. 3

                                                                          congrats!

                                                                          1. 3

                                                                            WOW congratulations! I hope you enjoy married life even half as much as I do :)

                                                                            1. 3

                                                                              Congratulations!! Enjoy the day and be as present as possible, it goes by so fast!

                                                                            1. 3

                                                                              This is cool. How do you have the idea to do something like this?

                                                                              1. 3

                                                                                Work stuff, understanding the backend systems at my new job and on my creative time I’m messing around with webgl and sign distance fields so I can do some cool shader stuff with letters. On a Radeon Pro 560X I’m rendering 8,820,000 instanced characters (i think) before the framerate drops below 60fps. So I have a lot of headroom to play with. https://meatdumpling.com

                                                                                1. 22

                                                                                  idk, depression or something.

                                                                                  1. 5

                                                                                    same. hope things get better for you, as meaningless as that sounds coming from an internet stranger.

                                                                                    1. 5

                                                                                      Depression high five

                                                                                      1. 4

                                                                                        Wanna go to an olive farm? Freshly pressed olive oil + salt on a baguette is a special thing.

                                                                                        1. 2

                                                                                          I’d love to, if there were one within 1000 km of me.

                                                                                      1. 12

                                                                                        Hot take: Could font designers please just agree that the only valid way to write 0 for technical fonts is with a dot in the middle? 0-with-nothing is irritatingly ambiguous with O, 0-with-a-slash is irritatingly ambiguous with Ø, and I’ve never seen the 0-with-broken-edges actually used outsize of Brazilian license plates.

                                                                                        1. 7

                                                                                          Just pulled some statistics from what people download: https://neil.computer/notes/berkeley-mono-font-variant-popularity/

                                                                                          The dotted-zero is indeed the most popular.

                                                                                          1. 7

                                                                                            I love slashed zeroes!

                                                                                            I’ve never used Ø or had to.

                                                                                            1. 17

                                                                                              What a strange coincidence.

                                                                                              1. 7

                                                                                                An Ø bit my sister once.

                                                                                                1. 5

                                                                                                  Ø bites cån be very painful!

                                                                                                  1. 3

                                                                                                    Yes but it’s not common for islands to bite.

                                                                                                    1. 2
                                                                                              2. 4

                                                                                                Nah, I like my slashed zeros. You just need properly distinguishable characters. Many font designers get it wrong.

                                                                                                1. 2

                                                                                                  Or just let you choose. There were a few things about those fonts that bothered me initially, but with customisation they became my favourites.

                                                                                                  1. 7

                                                                                                    I’m at the sad and tired point in my life where I don’t want things where every nuance is customizable, I want things where the defaults are pretty good. :P

                                                                                                  2. 1

                                                                                                    What is your opinion on writing a 0 with a backslash, like in Atkinson Hyperlegible?

                                                                                                    1. 1

                                                                                                      Never seen it before in practice! I suppose I have no objective complaints. I might worry a little about dyslexic legibility, but no practical experience with it.

                                                                                                    2. 1

                                                                                                      Yeah, I agree. my eyes are pretty bad, and I struggle to read code at even 14pt sometimes. I pretty much exclusively use Source Code Pro as my main programming font because it has the most distinctly different letters and the dot-in-the-middle 0 and NO LIGATURES.

                                                                                                    1. 8

                                                                                                      I am seriously impressed by the quality of this font. Very regular, very readable; I would put it at the same level as PragmataPro for coding.

                                                                                                      Vertical alignment is correct for arrows (<, -, >, =…). It is possible to choose among multiple styles of zero characters. I have not seen any line height issues in Emacs and in XTerm.

                                                                                                      Unicode coverage could be better, but this typeface is brand new, so I guess it will improve.

                                                                                                      1. 5

                                                                                                        Thanks for the kind words, this is how it looks on iTerm: Berkeley Mono iTerm screenshot.

                                                                                                        I will get better over time with new glyphs and features. We’re planning for a condensed version next.

                                                                                                        1. 4

                                                                                                          Honestly, you may want to try Input. You can modify it a bit to suit your tastes. I use it simply because it seems to make it very easy to distinguish between curly braces, brackets, and parentheses at very small font sizes, at least better than any others I’ve seen. there’s free licenses in addition to commercial ones so I don’t feel much guilt plugging it.

                                                                                                          Love it.

                                                                                                          https://input.djr.com/preview/?size=17&language=clike&theme=default&family=InputSans&width=200&weight=200&line-height=0.9&a=0&g=0&i=serif&l=serifs_round&zero=slash&asterisk=0&braces=0&preset=default&customize=please

                                                                                                        1. 32

                                                                                                          That logo is generic and forgettable as hell. The mo-zilla lizard was way better. People on the whole don’t have taste. I have nothing important to note just feels so commercial.

                                                                                                          1. 3

                                                                                                            In my opinion, we only get to complain about something becoming commercial if we’ve donated time or effort to the project. Commercial things survive, and absent contributions, important things should do what it takes to survive.

                                                                                                            1. 11

                                                                                                              I think people should feel free to constructively criticize regardless of whether they’ve contributed. Imposing a barrier to critique doesn’t really help.

                                                                                                              1. 1

                                                                                                                Nah, that part was voted on by the users. We screwed it up, not them. So I’m going to complain.

                                                                                                                1. 1

                                                                                                                  Unfortunately, commercial things do not necessarily survive. I am not a web developer, so I have little need for MDN. I do use a web browser every day, however, and Firefox is the last serious bulwark against a Chrome monoculture. Mozilla should stop shuffling deckchairs around and let us fund the browser.

                                                                                                                2. 3

                                                                                                                  If the logo being mediocre is all there is to complain about in it, they’ve done pretty well overall. :)

                                                                                                                  1. 1

                                                                                                                    I can get with that. it was the only thing that struck me as bad out of the entire redesign.

                                                                                                                1. 1

                                                                                                                  trying to recover from food poisoning, alternately staring at a wall and at my computer with nothing coming to mind.

                                                                                                                  1. 6

                                                                                                                    I need to learn OpenGL. Hard to say what else I’ll need, there’s little sense in making plans.

                                                                                                                    1. 1

                                                                                                                      OpenGL ES or something like OpenGL 4?

                                                                                                                      1. 1

                                                                                                                        The oldest reasonable thing that will work on Linux desktops and macOS. I need it for rather simple texture transformations, because those are incredibly slow on a CPU, but I like to have deep understanding.

                                                                                                                        1. 2

                                                                                                                          Potentially useful resource on writing shaders? https://thebookofshaders.com/

                                                                                                                          As far as my experience has gone, most of the buffer management stuff for OpenGL is pretty boilerplate (it’s just slinging buffers to the GPU and sometimes fetching results back), so most of the interesting work happens in the shaders.

                                                                                                                          1. 1

                                                                                                                            Also if you don’t need realtime rendering since it sounds like you might be doing batch processing, it could make sense to just use gpgpu features like OpenGL compute shaders or even OpenCL.

                                                                                                                          2. 2

                                                                                                                            People say that the book of shaders is good. I’ve found that going to shadertoy and tweaking some simple shaders heavily and googling built in gl mathematical functions to understand the ways I can modify the colors and point positions to be more interesting.

                                                                                                                      1. 8

                                                                                                                        I’ve been using gRPC for about the past 4 years and by far the most important thing I wish we had understood at the outset is that you can use gRPC with a variety of other encodings.

                                                                                                                        Protobuf is a mess (https://reasonablypolymorphic.com/blog/protos-are-wrong/) and you should avoid it if at all possible; you can still use gRPC without it.

                                                                                                                        1. 4

                                                                                                                          I’ve been working with Protobufs for a few years now. The author’s criticisms are valid, but I’d change the emphases. The formal “niceness” of the type system has generally not been an issue in my usage. Optionals, enums, and submessages using ints and strings are what are used for practically everything. What is more of a problem is that every field in a Protobuf definition is usually chosen to be an optional, and, I believe, an optional by default in the latest version. This is best practice to prevent deserialization failures if the field is omitted, especially if the send-side schema is a newer version that no longer requires the field. Optionals make you check for the presence, which at best is annoying and at worst encodes a brittle schema defined in code. It also makes it hard to use the type in interior code as you’re not sure which fields are filled out. The author touches on the problem of having transport and internal types; optionals pose a major problem with using Protobufs for internal types. At the crux of it, I think the problem is Protobufs is implicitly supposed to be used for senders/receivers with evolving versions of the schema, but doesn’t provide any extra features to make that process smooth. There’s been plenty of horror stories with systems crashing b/c mismatched proto expectations.

                                                                                                                          1. 2

                                                                                                                            Um; I can only say since I understood it, I see all-optional as an important feature, not bug. To me it conveys the same semantics as the “zero by default” semantics of strict fields in Go. The trick is to define your fields in a way where a zero value is a perfectly sensible and meaningful common default. Now, for some values like string names zero (empty string) might not make much sense - but then you probably need more complex validation anyway, so e.g. some validation annotations with a code generator for them (protoc-gen-validator or what was the name) might be the next useful step. And for even more advanced ones, you have to check them in code anyway, unless the expectation is that protobufs would be a formal proofs language. That said, as described in https://aip.dev/203, there are annotations like ‘REQUIRED’, though they have quite nuanced semantics, and those make quite some sense to me as such. And here I do indeed miss not seeing an automatic protoc generator for their validation - but no efully one will appear sooner or later (and I sometimes wonder would it be so hard to write myself?)

                                                                                                                          2. 2

                                                                                                                            I wish I’d known this before I left my last gig.

                                                                                                                            I also dislike protobuf, but although it’s a mess I think the one exception to “you should avoid it if at all possible” is if you’re using java on both ends. That doesn’t make it any less of a mess, but it’s mostly a mess in exactly the same way that the java type system is a mess so it ends up being beneficial.

                                                                                                                            Or at least that’s what I heard from the cloud devs doing java on the other (unfortunately only theoretical) end gPRC interface that I was working on from Rust.

                                                                                                                            1. 3

                                                                                                                              My experience comes from using it with the JVM on both ends (but Clojure rather than Java) and we still had a lot of headaches. In particular the part where you send it a nil in an integer field and it silently converts it to zero is mind-bogglingly bad. Or where you send a negative number in a field that’s defined as an unsigned int and it silently accepts it; what the hell.

                                                                                                                              1. 2

                                                                                                                                sounds like annotating deserialized stuff in kotlin as non-null, only for the deserialization system to not care about that for obvious reasons - those are the times I miss rust so much

                                                                                                                                1. 2

                                                                                                                                  Woof. I guess I was slightly more fortunate. We ended up only sending and receiving with Rust, so everything was super explicit to get things into the types needed by the generated protobuf message structs.

                                                                                                                                  So many messages with foo and foo_is_set fields though.

                                                                                                                              2. 2

                                                                                                                                Just curious if you recommend any specifically? I’ve tried once or twice to look into gRPC, but each time I was put off by protobuf.

                                                                                                                                1. 2

                                                                                                                                  We use EDN at work to communicate between Clojure services; that’s the only one I have experience with, but I’ve heard people like msgpack too.

                                                                                                                                  1. 1

                                                                                                                                    Would you link any references to using gRPC with EDN or msgpack encodings?

                                                                                                                                    1. 1

                                                                                                                                      I believe you guys have multiple good reasons so could you tell me why you don’t just use JSON with a schema validator over this? I find the inspectability, flexibility and interoperability of JSON makes it a better choice over anything else so in my attempt to not be a frog in a well could you let me know under what constraints it makes more sense to use gRPC?

                                                                                                                                      1. 2

                                                                                                                                        JSON would have been a big improvement over protobuf too, but being able to seamlessly encode UUIDs and Dates directly was more important to us than being able to support non-Clojure services.

                                                                                                                                        I’m only talking about the encoding within gRPC; whether to use gRPC vs REST is a completely different question that unfortunately was made above my pay grade. If it were up to me we would have used EDN over REST.

                                                                                                                                        1. 1

                                                                                                                                          Got it. Thank you. Maybe they have some magical wisdom I’m missing.

                                                                                                                                1. 9

                                                                                                                                  You can have very nice “easter eggs” and properly document them (but do they still deserve that name then?).

                                                                                                                                  For instance, I like the Redis command “LOLWUT”: https://redis.io/commands/lolwut

                                                                                                                                  1. 4

                                                                                                                                    Yes. Who says easter eggs should be undocumented? As long as they are documented and require a specific input that is never used in normal program operation to fire, I have nothing against them, even in “critical” projects (critical is subjective, of course).

                                                                                                                                    1. 3

                                                                                                                                      the teapot is another nice example of this.

                                                                                                                                      1. 2

                                                                                                                                        418 forever, I’m with you!

                                                                                                                                        1. 2

                                                                                                                                          I use the HTTP 418 response code in a critical project—my gopher server to inform wayward web bots they’re not talking to a web server. It’s great for that.

                                                                                                                                      2. 3

                                                                                                                                        LOLWUT wants to be a reminder that there is more in programming than just putting some code together in order to create something useful.

                                                                                                                                        I love this sentiment.

                                                                                                                                      1. 2

                                                                                                                                        $WORK: payment integrations

                                                                                                                                        $HOME: webworkers and offscreen canvases.

                                                                                                                                        1. 2

                                                                                                                                          $WORK: Getting our stack off of MongoDB permanently, one step at a time.

                                                                                                                                          $HOME:

                                                                                                                                          • 2 weeks after posting here that my laptop was barely hanging on, the battery just….stopped being recognized entirely. Ended up pulling the trigger on an M1 Macbook Air and that arrives tomorrow, so playing with that will constitute most of my week.
                                                                                                                                          • Playing around with modeling some custom enclosures for a couple electronics builds
                                                                                                                                          • Playing around with our dogs
                                                                                                                                          1. 2

                                                                                                                                            where’s your stack headed, db-wise?

                                                                                                                                            1. 2

                                                                                                                                              Nice and normal MySQL haha. The Mongo was leftover and horrible from back when the company was founded 7y ago and it was not managed properly, plus our data is headed far more in the relational direction now.

                                                                                                                                              1. 1

                                                                                                                                                And, mind to share why you’re moving off?

                                                                                                                                                1. 1

                                                                                                                                                  See other comment :)

                                                                                                                                            1. 3

                                                                                                                                              I’m wondering if he would be willing to try this technique out to get around compilation times in addition to using final on the derived objects in order to get around the virtual method slowdown. I’ve been using it and it seems ok…I think?

                                                                                                                                              https://stackoverflow.com/a/41292751/2088672

                                                                                                                                              1. 3

                                                                                                                                                I’m sorry, but how the heck are you able to program walking at 6 miles per hour? I can barely manage 1.3 mph

                                                                                                                                                1. 104

                                                                                                                                                  I’m not a big fan of pure black backgrounds, it feels a bit too « high contrast mode » instead of « dark mode ». I think a very dark gray would feel better to the eye. n=1 though, that’s just a personal feeling.

                                                                                                                                                  Thanks for the theme, it’s still great!

                                                                                                                                                  1. 29

                                                                                                                                                    Agreed, background-color: #222 is better than #000.

                                                                                                                                                    1. 15

                                                                                                                                                      I’ll just put my +1 here. The pure black background with white text isn’t much better than the opposite to me (bright room, regular old monitor). I’ve been using a userstyle called “Neo Dark Lobsters” that overall ain’t perfect, but is background: #222, and I’ll probably continue to use it.

                                                                                                                                                      On my OLED phone, pure black probably looks great, but that’s the last place I’d use lobste.rs, personally.

                                                                                                                                                      1. 18

                                                                                                                                                        Well, while we’re bikeshedding: I do like true black (especially because I have machines with OLED displays, but it’s also a nice non-decision, the best kind of design decision), but the white foreground here is a bit too intense for my taste. I’m no designer, but I think it’s pretty standard to use significantly lower contrast foregrounds for light on dark to reduce the intensity. It’s a bit too eye-burney otherwise.

                                                                                                                                                        1. 7

                                                                                                                                                          You have put your finger on something I’ve seen a few times in this thread: The contrast between the black background and the lightest body text is too high. Some users’ wishes to lighten the background are about that, and others’ are about making the site look like other dark mode windows which do not use pure black, and therefore look at home on the same screen at the same time. (Both are valid.)

                                                                                                                                                          1. 10

                                                                                                                                                            For me pure white and pure black is accessibility nightmare: that high contrast triggers my dyslexia and text starts to jump around, which starts inducing migraine.

                                                                                                                                                            As I default to dark themes systemwide and I couldn’t find way to override detected theme, this site is basically unusable for me right now. Usually in these cases I just close the tab and never come back, for this site I decided type this comment before doing that. Maybe some style change happens, manual override is implemented or maybe I care enough to setup user stylesheet.. but otherwise my visits will stop

                                                                                                                                                            1. 1

                                                                                                                                                              No need to be so radical, you still have several options. Not sure what browser you’re using, but Stylus is available for Chrome/FF:

                                                                                                                                                              https://addons.mozilla.org/en-US/firefox/addon/styl-us/

                                                                                                                                                              It allows to override the stylesheet for any website with just a few clicks (and few CSS declarations ;))

                                                                                                                                                              1. 9

                                                                                                                                                                I don’t mind the comment. There’s a difference between being radical because of a preference and having an earnest need. Access shouldn’t require certain people to go out of their way on a per-website basis.

                                                                                                                                                                1. 6

                                                                                                                                                                  It’s not radical, it’s an accessibility problem.

                                                                                                                                                          2. 8

                                                                                                                                                            That’s great, thank you.

                                                                                                                                                            I wonder if I am an outlier in using the site on my phone at night frequently. Alternatively, maybe we could keep the black background only for the mobile style, where it’s more common to have an OLED screen and no other light sources in your environment.

                                                                                                                                                            1. 2

                                                                                                                                                              I don’t use my phone much, especially not for reading long-form content, so I wouldn’t be surprised if I was the outlier. That sounds like a reasonable solution, but it’s not going to affect me (since I can keep using a userstyle), so I won’t push either way. I will +1 the lower-contrast comments that others have posted, if it remains #000 though - the blue links are intense.

                                                                                                                                                              1. 1

                                                                                                                                                                The blue link color brightness is a point that not many have made. I think the reason I didn’t expect it is that I usually use Night Shift on my devices, which makes blue light less harsh at night. Do you think we should aim to solve this problem regardless of whether users apply nighttime color adjustment? Another way to ask this question: What do you think about dark mode blue links in the daytime?

                                                                                                                                                                1. 2

                                                                                                                                                                  Sorry if I’m misunderstanding, but to clarify, my above comment is in a bright room; I try to avoid looking at screens in dim light/darkness. The blue links just look kind of dark, and intensely blue. Just a wee reduction in saturation or something makes it easier to read.

                                                                                                                                                                  Thanks for your work on this btw. I looked into contributing something a while back, but was put off after it looked like the previous attempt stalled out from disagreement. I’d take this over the bright white any day (and it turns out this really is nice on my phone, dark blue links withstanding). The css variables also make it relatively easy for anyone here to make their own tweaks with a userstyle.

                                                                                                                                                                  I feel like I’ve taken up enough space complaining here, so I’ll leave a couple nitpicks then take my leave: the author name colour is a little dark (similar to links, it’s dark blue on black), and the byline could do with a brightness bump to make it more readable, especially when next to bright white comment text.

                                                                                                                                                                  1. 1

                                                                                                                                                                    I appreciate the clarification and other details :)

                                                                                                                                                              2. 1

                                                                                                                                                                My laptop is OLED and I’d still appreciate #000 there

                                                                                                                                                                1. 1

                                                                                                                                                                  +1 to separate mobile style.

                                                                                                                                                              3. 4

                                                                                                                                                                I strongly agree.

                                                                                                                                                                I can’t put my finger on why, but I find very dark gray easier.

                                                                                                                                                                1. 1

                                                                                                                                                                  #222 is way better! thank you

                                                                                                                                                                2. 14

                                                                                                                                                                  I strongly disagree, and this black background looks and feels great to me! No one can ever seem to agree on the exact shade or hue of grey in their dark themes, so if you have the general UI setting enabled, you end up with a mishmash of neutral, cooler, hotter, and brighter greys that don’t look cohesive at all. But black is always black!

                                                                                                                                                                  For lower contrast, I have my text color set to #ccc in the themes I have written.

                                                                                                                                                                  1. 6

                                                                                                                                                                    Another user pointed out that pure black is pretty rare in practice, which makes this site stand out in an environment with other dark mode apps:

                                                                                                                                                                    Here’s a desktop screenshot with lobste.rs visible - notice that it’s the only black background on the screen.

                                                                                                                                                                    Does that affect your opinion like it did mine? I do see value in pure black, but suppose we treated the too-high-contrast complaint as a separate issue: Darkening the text could make the browser window seem too dim among the other apps.

                                                                                                                                                                    1. 3

                                                                                                                                                                      I prefer the black even in that scenario. The contrast makes it easier to read imo.

                                                                                                                                                                      1. 2

                                                                                                                                                                        Not all. If it gets swapped out for grey I will simply go back to my custom css, which I have used to black out most of the sites I visit, so no hard feelings.

                                                                                                                                                                    2. 8

                                                                                                                                                                      Feedback is most welcome! Would you please include the type of screen you’re using (OLED phone, TFT laptop…) and the lighting environment you’re in (dark room, daytime indoors with a window, etc.)? And do you feel differently in different contexts?

                                                                                                                                                                      I’ve got some comments about how I selected the colors in the PR, if that helps anyone think through what they would prefer.

                                                                                                                                                                      1. 4

                                                                                                                                                                        Sure! I’m on my iPhone 12 so OLED phone. I tried in with dimmed lights and in the dark, but in both cases I think I’d prefer a lighter background color.

                                                                                                                                                                      2. 7

                                                                                                                                                                        I disagree. Black is black. These off-gray variants just looks dirty and wrong to me.

                                                                                                                                                                        I love this theme.