1. 2

    Maybe a dumb questions, but in semver what is the point of the third digit? A change is either backwards compatible, or it is not. To me that means only the first two digits do anything useful? What am I missing?

    It seems like the openbsd libc is versioned as major.minor for the same reason.

    1. 9

      Minor version is backwards compatible. Patch level is both forwards and backwards compatible.

      1. 2

        Thanks! I somehow didn’t know this for years until I wrote a blog post airing my ignorance.

      2. 1

        PATCH version when you make backwards-compatible bug fixes See: https://semver.org

        1. 1

          I still don’t understand what the purpose of the PATCH version is? If minor versions are backwards compatible, what is the point of adding a third version number?

          1. 3

            They want a difference between new functionality (that doesn’t break anything) and a bug fix.

            I.e. if it was only X.Y, then when you add a new function, but don’t break anything.. do you change Y or do you change X? If you change X, then you are saying I broke stuff, so clearly changing X for a new feature is a bad idea. So you change Y, but if you look at just the Y change, you don’t know if it was a bug-fix, or if it was some new function/feature they added. You have to go read the changelog/release notes, etc. to find out.

            with the 3 levels, you know if a new feature was added or if it was only a bug fix.

            Clearly just X.Y is enough. But the semver people clearly wanted that differentiation, they wanted to be able to , by looking only at the version #, know if there was a new feature added or not.

            1. 1

              To show that there was any change at all.

              Imagine you don’t use sha1’s or git, this would show that there was a new release.

              1. 1

                But why can’t you just increment the minor version in that case? a bug fix is also backwards compatible.

                1. 5

                  Imagine you have authored a library, and have released two versions of it, 1.2.0 and 1.3.0. You find out there’s a security vulnerability. What do you do?

                  You could release 1.4.0 to fix it. But, maybe you haven’t finished what you planned to be in 1.4.0 yet. Maybe that’s acceptable, maybe not.

                  Some users using 1.2.0 may want the security fix, but also do not want to upgrade to 1.3.0 yet for various reasons. Maybe they only upgrade so often. Maybe they have another library that requires 1.2.0 explicitly, through poor constraints or for some other reason.

                  In this scenario, releasing a 1.2.1 and a 1.3.1, containing the fixes for each release, is an option.

                  1. 2

                    It sort of makes sense but if minor versions were truly backwards compatible I can’t see a reason why you would ever want to hold back. Minor and patch seem to me to be the concept just one has a higher risk level.

                    1. 4

                      Perhaps a better definition is library minor version changes may expose functionality to end users you did not intend as an application author.

                      1. 2

                        I think it’s exactly a risk management decision. More change means more risk, even if it was intended to be benign.

                        1. 2

                          Without the patch version it makes it much harder to plan future versions and the features included in those versions. For example, if I define a milestone saying that 1.4.0 will have new feature X, but I have to put a bug fix release out for 1.3.0, it makes more sense that the bug fix is 1.3.1 rather than 1.4.0 so I can continue to refer to the planned version as 1.4.0 and don’t have to change everything which refers to that version.

                2. 1

                  I remember seeing a talk by Rich Hickey where he criticized the use of semantic versioning as fundamentally flawed. I don’t remember his exact arguments, but have sem ver proponents grappled effectively with them? Should the Go team be wary of adopting sem ver? Have they considered alternatives?

                  1. 3

                    I didn’t watch the talk yet, but my understanding of his argument was “never break backwards compatibility.” This is basically the same as new major versions, but instead requiring you to give a new name for a new major version. I don’t inherently disagree, but it doesn’t really seem like some grand deathblow to the idea of semver to me.

                    1. 1

                      IME, semver itself is fundamentally flawed because humans are the deciders of the new version number and we are bad at it. I don’t know how many times I’ve gotten into a discussion with someone where they didn’t want to increase the major because they thought high major’s looked bad. Maybe at some point it can be automated, but I’ve had plenty of minor version updates that were not backwards compatible, same for patch versions. Or, what’s happened to me in Rust multiple times, is the minor version of a package incremented but the new feature depends on a newer version of the compiler, so it is backwards breaking in terms of compiling. I like the idea of a versioning scheme that lets you tell the chronology of versions but I’ve found semver to work right up until it doesn’t and it’s always a pain. I advocate pinning all deps in a project.

                      1. 2

                        It’s impossible for computers to automate. For one, semver doesn’t define what “breaking” means. For two, the only way that a computer could fully understand if something is breaking or not would be to encode all behavior in the type system. Most languages aren’t equipped to do that.

                        Elm has tools to do at least a minimal kind of check here. Rust has one too, though not widely as used.

                        . I advocate pinning all deps in a project.

                        That’s what lockfiles give you, without the downsides of doing it manually.

              1. 1

                How about another bug, int*2 is an undefined overflow. That’ll certainly cause problems.

                1. 4

                  This is one area where Rust and C are different; overflow is well-defined in Rust.

                1. 0

                  I have this horrible horrible feeling that Rust is becoming the new Perl. This all reminds me of when Perl added “object orientation” and things became more confusing and hard to understand for passers by like myself.

                  1. 5

                    Every serious new language needs to be able to solve the c10k problem; we knew Rust would need async I/O sooner or later.

                    What is ugly is the proliferation of macros when a proper general-purpose solution is possible. If you look at the final example from the link, async! is fulfilling exactly the same role as the notorious try!; if the language would adopt HKT they could build a single reusable standard form of “do notation” into the language and reuse it for result, async, option, and many other things: https://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/

                    1. 6

                      It is extremely unclear that a strongly-typed do notation is possible in Rust. It’s also not clear if we’ll ever get HKT directly; GAT gives us equivalent power, but fits in with the rest of stuff more cleanly.

                      1. 3

                        What is GAT?

                        1. 2

                          generic associated types

                      2. 1

                        I think async! will eventually be made into a language feature (a couple of community members have proposals for this), it’s just that we’re experimenting on it as a proc macro, because we can. It’s way more annoying to experiment with features baked into the language.

                      3. 1

                        The only language feature added here is generators (and possibly, async/await sugar), everything else will be a library. Both things are quite common amongst languages; and shouldn’t be too confusing.

                        Everything else listed here is a library that you only deal with when you are doing async stuff. And the complexities listed are largely internal complexities; tokio should be pretty pleasant to work with.

                      1. 3

                        Rust has lots of attractive features (chiefly a great type system and a familiar syntax) that make me want to use it, but the cognitive overhead of the memory system still makes Go and other GC languages the better value proposition for the overwhelming majority of projects I take on. To some extent, this will improve with familiarity, but the gap can never close completely (Rust will always require more thinking about memory than GC languages) and I doubt it will close enough to change the calculus. Still, I applaud the intentional attitude that the community takes toward continuous improvement.

                        1. 4

                          If you don’t mind me asking, how long have you spent with it, and what did you struggle most with?

                          We have some decent stuff coming down the pipeline to ease up the learning curve, but there’s always more. I wonder how much what you’ve experienced lines up with other people’s.

                          1. 2

                            What kind of stuff is coming to ease using the language? As someone who mostly works in Python and Haskell even basic stuff in Rust still trips me up. Things like when should I be using a reference vs directly passing value in? Which data structures should I be using for different problems? Etc. There is a mental overhead that is still slowing me down, so anything to help me get past that would be great!

                            1. 1

                              Hey sorry, I missed this!

                              https://blog.rust-lang.org/2017/12/21/rust-in-2017.html is a good summary, see the “ergonomics initiative” section.

                            2. 1

                              Sorry, I missed this. I don’t keep a very good inventory of things I bump into, and part of the problem is that if I understood my frustrations well enough to articulate them, they probably wouldn’t be so frustrating to begin with. Sort of a “beginner’s paradox”. I’ve been playing with Rust in my free time on and off since about 2014, but I still don’t feel like I’ve climbed the learning curve well enough to be passably productive with Rust (I might feel differently if my bugs could kill people, mind you!).

                          1. 3

                            I’m very inexperienced and new to Rust, but the times I tried to do something I too found it painful that the good stuff is rust-nightly only.

                            1. 2

                              What things do you run into?

                              1. 2

                                One example: Clippy requires nightly. I noticed I could run clippy+nightly on my codebase that aims at stable, but it’s still odd :-)

                                Also, tokio

                                1. 4

                                  Cool, thanks!

                                  Yeah, developer tools are still on nightly. rustfmt will be on stable as of the next release, with the rls following closely, and clippy at some point.

                                  Tokio is in a weird spot; it doesn’t require nightly, but some nightly features make it more ergonomic; impl Trait is almost here!

                                  Thanks again for taking the time.

                                  1. 3

                                    Clippy is a tool, so it’s kinda been low priority. Using it doesn’t force your library to use nightly, it just means you have to locally use nightly when running clippy. But we’re working on making it stable!

                                    tokio is pretty new and experimental and some of the stuff relies on experimental new features in the compiler built for tokio (i.e. generators). It’s getting there.

                                    There will always be new shiny stuff on nightly :)

                              1. 12

                                I don’t understand what the author’s problem with Haskell is, I bet Haskell is more widely used in the industry compared to Rust (I for one am working in a Haskell-first shop). Haskell has recently also gained an impressive momentum to the point that we have a shortage of Haskell talent (despite the influx of new folks) and not Haskell jobs, which was quite the opposite just a couple of years ago.

                                1. 5

                                  Your anecdotal experience is directly countered by mine. It is nearly impossible for me to find work doing Haskell.

                                  Comparing Haskell to Rust industry usage is comparing items in the bottom % of languages. The relative numbers may be impressive but it says nothing about the likelihood of adoption.

                                  1. 3

                                    My point is, “why use Haskell as a negative example?”. Haskell is a language that rose to its position purely based on its own merits and not a multi million dollar marketing budget backed by a mega corporation, nor its similarity to a popular language. And it’s also a fairly good position. So I don’t get the author’s point.

                                    1. 4

                                      Regardless of popularity contest/whatever else, I do agree that I find these kinds of comparisons to be in bad taste.

                                      1. 3

                                        Rust would be lucky to become Haskell. It should be aspired to.

                                      2. 2

                                        BTW, since it’s relevant to the discussion, I’ll use this opportunity to plug this here… we’re hiring :) https://www.picussecurity.com/careers/backend-developer.html Remote is OK, but we’re a fast growing Turkish company so we can currently probably offer, say, southern-europe kind of a salary. But that’ll probably change soon.

                                    1. 6

                                      What am I looking at?

                                        1. 3

                                          We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons

                                          isn’t that worrisome?

                                          1. 5

                                            When it’s related to spam mitigation it’s not unusual.

                                          2. 2

                                            That’s a little worrisome. They built an auto nuker, but didn’t think about what next? Whether it’s a false positive or not, “what if it’s republished?” should be part of the checklist. What if it really were malicious? I just keep retrying until I find a version that sticks.

                                          3. 4

                                            The left-pad thing happened again.

                                            1. 2

                                              Somebody left padded the safeguards meant to prevent left padding? “no, no, we totally fixed it by adding a ‘are you sure you want to fuck everybody?’ confirmation to the delete command.”

                                              1. 1

                                                Has anyone written up the impact this time around?

                                            1. 18

                                              Semi-random side note: Jackson said on twitter that he was really annoyed with this headline: https://twitter.com/ummjackson/status/949313665139802112

                                              1. 3

                                                Thanks. It’s far better to read the original source with all its nuance than to bother with an article that cherry-picks it and presents it as news. This is especially true when the original source is nothing more than three short paragraphs.

                                              1. 12

                                                eliminating all heap allocations

                                                Rust isn’t heap allocating anything.

                                                1. 11

                                                  And C isn’t either.

                                                  I haven’t had the time to dig into the codegen, but I posted it to /r/rust; we’ll see what they say :)

                                                  EDIT:

                                                  Looks to me like the use of signed integers is inhibiting some optimizations.

                                                  https://www.reddit.com/r/rust/comments/7m99wo/outperforming_rust_with_functional_programming/drsbori/

                                                  1. 6

                                                    I doubt that, this are unmodified results (on my machine):

                                                    test bench_collatz_106239 ... bench:         467 ns/iter (+/- 18)
                                                    test bench_collatz_10971  ... bench:         367 ns/iter (+/- 12)
                                                    test bench_collatz_2223   ... bench:         229 ns/iter (+/- 7)
                                                    

                                                    And here is after replacing i64 with u64:

                                                    test bench_collatz_106239 ... bench:         509 ns/iter (+/- 4)
                                                    test bench_collatz_10971  ... bench:         388 ns/iter (+/- 3)
                                                    test bench_collatz_2223   ... bench:         267 ns/iter (+/- 10)
                                                    
                                                    1. 12

                                                      Yeah, there’s a bunch of different speculation going on in that thread.

                                                      Regardless, sometimes Rust will not be literally the fastest possible thing. That’s okay, as long as it’s close. I find these little examples interesting, regardless of who “wins”.

                                                      1. 11

                                                        I really like how the Rust community is approaching this as “how can we do better?”

                                                1. 2

                                                  I’m no C++ maven, but is memory management THAT much of a problem in C++11 and beyond? I get that you COULD write code that has you micro-managing memory, but you could pretty easily write code that doesn’t need it. C++ gives you that option.

                                                  I have very, very little experience with Common Lisp but I’ve had bad experiences with garbage collection in it and with Haskell.

                                                  Python’s big attraction was it’s syntax and module system. C++14 and later (with auto and ranged for loops for vectors and maps and custom types) has pleasant enough syntax for the simple things I do. Python’s multiprocessing is … involved … while C++ threading has gotten a little simpler. And nowadays Python’s speed becomes an issue for me very quickly.

                                                  I do miss the module system - for example, to read a YAML file I have to do much more in C++ than Python has gotten me expecting to.

                                                  However, when I experimented with Common Lisp I really did not see that much of an advantage. For an older language it has many cool concepts, but Python has made me used to that. I realize “Macros!” but that just seems like obfuscation - if I got into Macros a lot I can easily see myself confusing the future me with my code in a way that regular function or class based code would not.

                                                  Any how, I appreciate Greenspun’s law, but I do think it’s a little bit, ok, I’ll say it, pretentious.

                                                  1. 12

                                                    Any how, I appreciate Greenspun’s law, but I do think it’s a little bit, ok, I’ll say it, pretentious.

                                                    Hmm.. maybe, but let’s consider the state of the world in 1993 when the quote originated:

                                                    1. C89/90 is just a few years old.
                                                    2. C++ is 10ish years old.
                                                    3. Common Lisp is 9 years old, on the way to an ANSI standard
                                                    4. Perl has been around for 6 years (and not widely adopted yet)
                                                    5. Lua is just introduced (1993)
                                                    6. PHP, Ruby would come 2 years later in 1995
                                                    7. Python version 1 still didn’t happen (1994)
                                                    8. TCL was a popular scripting language, 5 years old.
                                                    9. Java wouldn’t be for 2 more years
                                                    10. JavaScript is 2 years away.
                                                    11. Haskell existed, but was essentially a research language.
                                                    12. The rest of the functional world, ML, SML, Caml were academic mostly

                                                    So, almost all of the (now) commonly used garbage collected languages hadn’t even been invented yet, and there’s years of the precursors to Common Lisp, and Common Lisp on the horizon – this great philosophical and amazing piece of kit, that has super special powers, first class functions, garbage collection, conditions and restart, proven uses in AI research (even though the AI winter happened), and the things that win out are the far inferior and unsafe C and C++ because of the rise of Unix?

                                                    Maybe someone with more accurate history can paint a prettier picture, but I think the observation was certainly timely, even if it’s continued usage isn’t as relatable to today’s audience.

                                                    1. 3

                                                      I’d argue that it’s usage shouldn’t be that unrelatable today. Common Lisp is still quite competitive with pretty much any modern language. Meanwhile, many languages are still playing catch up with it.

                                                      1. 1

                                                        Absolutely agree that CL is still relevant and the original argument holds. The pure fact of matter, though, is that there are many, more in vogue languages, for which the argument would be almost as effective, and therefore more broadly appliable. “… implementation of JavaScript”, or “… Ruby,” would certainly be somewhat valid as there are obviously distinct advantages that programmers of those languages understand.

                                                        To a large population, Common Lisp equates to, ancient AI “stuff”, “Lots of Infuriating, Superfluous Parens,” C style pre-preprocessor macros (of course they are misinformed), and first class functions. Surely, JavaScript is better even without those stupid macros that I don’t need anyway!

                                                        1. 1

                                                          I think the reason you end up putting CL into C is because the expressiveness gap is so huge you need to implement a language to get anywhere.

                                                          I can see the argument for CL being still really better than other languages, but modern languages nowadays solve a lot of the problems that C had. Even extremely basic things in C end up requiring macros. Meanwhile in Python I have metaclasses.

                                                      2. 10

                                                        I’m no C++ maven, but is memory management THAT much of a problem in C++11 and beyond?

                                                        As always, it’s really up to your opinion. I can say that some of us consider it enough of a problem that we built Rust. YMMV :)

                                                        1. 3

                                                          I’m no C++ maven, but is memory management THAT much of a problem in C++11 and beyond?

                                                          Some of the comments are back-and-forth between ESR and a proponent of C++17. From the few I read, it seems like there’s a generational gap between understandings of what is modern C++. (ESR says he last used C++ in 2009, on a project whose codebase started in 2003, and he calls that “modern C++” in the comment…)

                                                          1. 1

                                                            C++ is THAT much of problem in C++11 and beyond

                                                          1. 26

                                                            Another item onto the list of stupid, self-sabotaging ideas from Mozilla.

                                                            • Pocket
                                                            • Cliqz
                                                            • Looking Glass
                                                            • (Anything else I missed?)

                                                            That said, I’m still a Firefox user, because after all, I still trust the Mozilla Foundation and Community more than the makers of the other browser vendors.

                                                            1. 10

                                                              Mozilla has it’s missteps, on the other hand, they are still better than the other Browser Vendors out there and I haven’t seen a viable Firefox Fork out there that works for me. Plus it seems the Looking Glass addon was inert unless specifically enabled by the user, so I don’t see the harm tbh.

                                                              “Atleast [they are] the prettiest pile of shit.” ~ Some quote I heard somewhere

                                                              1. 3

                                                                I would add Mozilla Persona to this list, which was a great idea, but was mismanaged and shut down by Mozilla before it could do anything good.

                                                                I pretty much lost my faith in Mozilla having any idea what it is doing at that point.

                                                                1. 5

                                                                  Original Pocket introduction was mishandled, but since Mozilla owns and operates it now, integration with Firefox makes sense.

                                                                  1. 7

                                                                    is it open source now?

                                                                    1. 6

                                                                      My understanding is, it’s not yet. It’s being worked on. I have no idea what kind of work it takes, but the intention is that it will be fully open sourced.

                                                                  2. 4

                                                                    You missed ‘Quantum.’ (The one where they broke their extension API for the sake of alleged performance).

                                                                    1. 45

                                                                      That one I actually like; the performance is much better, and the memory leaks much fewer. Pre-quantum I was on the verge of switching to Chrome because of the performance gap and leaks.

                                                                      1. 11

                                                                        I agree. The browser engine is noticeably better - if only the software around it were also on the same level. Some lightweight browser like surf or midori should adopt it, instead of WebKit.

                                                                        1. 1

                                                                          WebKit is easy to adopt because WebKitGTK and QtWebKit (or whatever it’s called) are well supported and easy to use. And Chromium has CEF. (IIRC Servo is also implementing CEF.)

                                                                          I don’t think current Gecko is easily embeddable into whatever.

                                                                          Back in the day Camino on Mac OS was a Gecko browser with a custom Cocoa UI, but doing that today would be way too hard.

                                                                          1. 2

                                                                            I should clarify, I was talking about Servo. I don’t really thing there would be a point in using Gecko, since it will probably turn into a legacy project.

                                                                            1. 2

                                                                              It seems the other way to me? What they’re doing instead is slowly retrofitting pieces of Servo into Gecko piecemeal. (or at least, some kind of Rust equivalent to the C/C++/JS code being replaced) Servo would then be dead or explicitly turned into some staging ground for Gecko.

                                                                      2. 20

                                                                        I will go beyond alleging a performance improvement, I will attest to it. Surprisingly enough, the improvement includes Google properties such as Gmail and YouTube. They are both more responsive in Firefox now than Chromium or Chrome.
                                                                        On the extension side, I do not use a large number. Those which I do, however, still function.

                                                                        I freely admit that the plural of anecdote is not “data”, but I would feel remiss not to share how impressed I am with Quantum. Pocket has always annoyed me, so I certainly do not see Mozilla’s actions as unimpeachable and am only giving them credit for Quantum because I feel they deserve it.

                                                                        1. 8

                                                                          Based on this, Quantum was a balanced update where the team had do sacrifice the old extension API. Also, it’s not that they’ve removed extensions completely. (And no, I’m not talking about you Looking Glass)

                                                                        2. 8

                                                                          Quantum is great. uBlock Origin and uMatrix now work on Firefox for Android just as well as on desktop.

                                                                          1. 3

                                                                            ublock origin worked on firefox android before firefox quantum no ?

                                                                            1. 1

                                                                              IIRC it worked but the UI was somewhat different. Now uMatrix is also available, and both extensions have UI that looks practically identical to the desktop versions.

                                                                      1. 10

                                                                        I love Rust and I know this is gonna get the whole “Python is boring. STFU” crowd down on me, but I’m honestly not sure that Rust’s level of abstraction is ideal for the vast majority of devops tasks. Sure there are plenty of performance intensive cases where Rust could really shine, but I think languages like Python and Go (which I have the same abstraction issue with FWIW but it’s at least a bit higher up the stack AFAICT) may retain the advantage for a while at least until a set of very solid libraries to perform common tasks become mature and stable.

                                                                        1. 7

                                                                          I definitely agree that often, working at a higher level of abstraction can be more useful. One of the things that I love about Rust is that it doens’t have to be either/or; for example, the new Conduit tool uses Rust at its core, but with Go layered on top.

                                                                          https://www.reddit.com/r/programming/comments/7hx3lk/the_rise_of_rust_in_devops/dqut2cl/ is an interesting thread developing where some people are talking about why they would or wouldn’t choose Rust here; I think there’s many viable answers!

                                                                          1. 3

                                                                            Surely there’s some middle ground between Rust’s “we’re going to use a language designed to minimize runtime costs for a task that is inherently IO-bound” and Python/Go’s “we’re going to basically throw out types”.

                                                                            1. 2

                                                                              What about something like mypy ?

                                                                            2. 2

                                                                              Can you say more about in what ways you feel rust is too low in the stack compared to Python? One reason I like Rust a lot is I can easily make great higher level abstractions in my programs, and still retain the safety around types and borrowing. I’ve been bitten too many times with bad concurrency implemented in “simple devops scripts” to want to return to that world.

                                                                              1. 5

                                                                                I think if you’re doing concurrency then traditional very high level procedural languages like Ruby and Python are a very poor choice.

                                                                                In concurrent applications, any of the abstraction complaints I might have with Rust fade away because you MUST think about things like memory allocation and structure in the concurrent problem space.

                                                                                This is the danger in (my) speaking in generalities. In my 25 years of doing infrastructure work, I have yet to encounter a problem that truly demands a solution involving concurrency. I recognize that this is merely anecdotal evidence, but be that as it may, I prefer to work in languages that handle the details of memory allocation for me, because in every use case I’ve thus far encountered, that level of performance is Good Enough.

                                                                                That said, a couple of examples of aspects of Rust I would feel are in the way for the kind of work I mostly need to do:

                                                                                • Pointers and dererencing / destructuring
                                                                                • The ownership and borrowing memory model

                                                                                I am not a Rust expert, but I read and worked through the entire Rust book 1.0 a couple of years back, which left me with a deep abiding respect for the power of Rust. I just don’t feel that it’s suited to the kinds of work I do on a day to day basis.

                                                                                1. 1

                                                                                  In my 25 years of doing infrastructure work, I have yet to encounter a problem that truly demands a solution involving concurrency.

                                                                                  I have, though I’ve generally still used python to handle it (the multiprocessing standard library is super-handy). My use cases have been simple, though. All of them can boil down to: process a big list of things individually, but in parallel, and make sure the result gets logged. No need for memory sharing, just use a queue (or even split the list into X input files for X processes).

                                                                                  That said, I don’t think rust would be a bad language to handle those problems. In fact, python might have been a terrible one. Just wanted to say that even workloads that require concurrency often end up very simple.

                                                                            1. 15

                                                                              Part of the struggle for us adopting something like rust internally is the syntax is too complex.

                                                                              Even the “hello world” example:

                                                                              fn main() {
                                                                                  println!("hello world")
                                                                              }
                                                                              

                                                                              Involves understanding what a macro is vs. a normal function call. The cognitive overhead of the language is a huge barrier and something we’ve eschewed for golang.

                                                                              1. 20

                                                                                I hear you; we strive to not make Rust more complex than it has to be; unfortunately, the job it’s attempting to do is inherently complicated. A big focus of this year was on lowering the learning curve; it hasn’t all landed yet though.

                                                                                That said, I’d hope that this particular example isn’t the biggest barrier, it boils down to “macros have a ! at the end.” In my ~five years with Rust, I’ve written exactly two macros, and they were less than 5 lines, and I mostly copy/paste/tweak’d them. They’re so minor we are even putting them in an appendix of the book, rather than giving them their own chapter.

                                                                                That said, use the tools that work for you! Rust isn’t for everyone, and that’s 100% okay.

                                                                                1. 4

                                                                                  As I said above I think really good libraries will help a lot with this, but in a sense @bigdubs is saying what I was trying to say but more eloquently. I look forward to seeing the results of all the awesome work the Rust community is doing to ease the onboarding experience and smooth out the learning curve.

                                                                                2. 4

                                                                                  Sorry to be kinda pendantic, but it’s wrong to say that for the hello world example, rust is more complicated than other languages such as golang which you mentioned. Compare the two:

                                                                                  package main // What's a package?
                                                                                  import "fmt" // Why do I need to import something to print to the screen?
                                                                                  func main() {
                                                                                      fmt.Println("hello world") // Why do I need to prefix this with fmt? Why is Println capitalized?
                                                                                  }
                                                                                  

                                                                                  To be fair I’ve never coded in rust and absolutely love coding in go for its simplicity and functionality, but your example doesn’t make a good comparison

                                                                                  1. 2

                                                                                    you can use println in golang w/o the prefix / package name.

                                                                                    in action here: https://play.golang.org/p/y5XX4RDTW5

                                                                                    further what you’re nitting is “what is a package” which is a feature of the language you will have to explore countless times, vs. macros which as steve said are a niche feature of the rust language.

                                                                                    there is still plenty of magic with golang though. the thing that tripped me up personally at first was lower case letters on structs == package private, which is a weird isolation level to begin with but even then the only thing that governs the protection is the first letter of a name.

                                                                                    1. 1

                                                                                      As an aside, according to the golang spec, one should not rely on println. “These functions are documented for completeness but are not guaranteed to stay in the language”

                                                                                1. 10

                                                                                  I wanted to shout-out https://conduit.io/ here, but didn’t know when this was coming out relative to Conduit’s release.

                                                                                  1. 4

                                                                                    Are there other types that are always on the heap? It turns out there are!! Here they are:

                                                                                    • Vec (an array on the heap)
                                                                                    • String (a string on the heap)

                                                                                    That sounds wrong to me. Both Vec<T> and String­—as far as I know—are triples: a length (usize), a capacity (usize), and a pointer into the heap. Those three values can be stored in the stack, however the pointer will always point to a memory block in the heap.

                                                                                    1. 8

                                                                                      Yes, you’re correct here; the author is being a bit less precise than you. It’s how many people think about it most of the time, though.

                                                                                    1. 15

                                                                                      borrowed Apple’s C++ compiler backend

                                                                                      I don’t think it’s fair to refer to LLVM that way. Certainly, Apple has taken a large role in shepherding llvm, clang and the rest of the items in llvm-project. Sure, Apple hired Lattner from University of Illinois and llvm really blossomed around then. But llvm started out independent from Apple and IMO remains so.

                                                                                      They built a convenient package ecosystem, allowing the out-of-the-box capabilities of Rust to grow while the core language and standard library remained small.

                                                                                      IMO this is the sleeper hit for Rust. I suppose Swift and Go also have analogous features? But being able to satisfy the no-GC requirements (or preferences) of C/C++ developers along with simplified build/dependency resolution is really awesome.

                                                                                      1. 3

                                                                                        I suppose Swift and Go also have analogous features?

                                                                                        In some senses, there’s CocoaPods for Swift, but I’m not sure how first-class it is. It does have a lot of packages though!

                                                                                        Go is a bit different here, but if the dep project works out, will have a similar model. My understanding is that it’s looking good.

                                                                                        1. 3

                                                                                          dep is just the “blessed” tool for locking dependency versions — raw go get is convenient enough on its own, and many similar tools have existed before.

                                                                                          CocoaPods is kinda old. The new cool Swift tool is Carthage, which is registry-less like the Go ecosystem.

                                                                                          1. 3

                                                                                            There’s also Swift Package Manager, which seems awfully official, bundled with the compiler at all, but not widely used?

                                                                                      1. 14

                                                                                        Does anybody have some ideas on why we as software developers are so likely to shirk our responsibility in the things we create?

                                                                                        Is it a capitalist thing where being paid to do something is all the justification needed, and everything else is “on them” (the people paying you for your work, the people who use the tool/system, the users who choose to interact with the system)?

                                                                                        Is it because our industry is young and so dominated by young people that there isn’t a long term perspective on the impact we have? How often do people ask each other or themselves, “how will I feel about this when I’m looking back over my life and what I’ve brought into the world?”

                                                                                        Is it the nihilistic view that “if we don’t do it, somebody else will, so it might as well be us?”

                                                                                        Is it just the simple fact that doing the right thing (what is in the interest of the people who our software will affect) is harder, takes more work, more discipline, and is not what we’re rewarded for (directly by superiors, or systemically)?

                                                                                        Is it that we all have so little faith in our industry as a whole that we’ve all shrugged and said “fuck it, I’m not going to be the only one who gives a shit”?

                                                                                        Is it the way that user’s are often talked down to and looked down on that effectively minimizes their view, perspectives, and interests?

                                                                                        Do you think it comes from other places?

                                                                                        Is our industry more or less prone to this? We do seem to be a particularly unconcerned and irresponsible group, but there are clearly more egregious examples (finance, pharmaceuticals, the fashion industry, and others). Not that it’s an excuse that others do even worse in some regards.

                                                                                        It’s a hard topic, and I can be prone to cynicism, but I don’t see Silicon Valley moving in the opposite direction any time soon. That said, everything creates its own resistance, and I have seen small trends of choosing sincerity and giving and shit over cynicism and disregard.

                                                                                        Thoughts or perspectives?

                                                                                        1. 4

                                                                                          Economic forces are definitely a large part of it. Software designed in a world where “usage = value” will end up with UIs that are as difficult to use as possible without actually driving away users. We have gotten so far from a consumer exchanging money for a good or product and the incentives in the modern tech sector are wildly misaligned.

                                                                                          There is also a relative lack of organized forces opposing the actions taken by tech. Think about all of the environmental groups who are trying to prevent pipelines being built, and contrast that with what there is opposing the creation of buggy, user hostile software. A few tech people sounding the alarm is a long way from marching in the streets, being chained to trees, lobbying lawmakers, etc.

                                                                                          Some of this might be the addressed in the future through government regulations (similarly to how other industries have been subjected to environmental or safety regulation), but at the same time, it is difficult to imagine a concise way to make crappy software illegal. And without a lot of public outcry, of course, it is unlikely that anything will be done.

                                                                                          1. 4

                                                                                            It’s not a direct answer, but for more musings on these types of questions: https://en.wikipedia.org/wiki/The_Californian_Ideology (you can find the text pretty easily online)

                                                                                          1. 34

                                                                                            It is fast :)

                                                                                            (Note the imaginary Mozilla Hat I’m wearing though :-). Actual hat yet to be approved)

                                                                                            1. 5

                                                                                              Congratulations, and to all your colleagues, too! Quantum has just landed on my phone, and the speed improvement is remarkable. (I thought at first it might be a placebo effect, but it turns out all these Rust components are in the Android build, too. I never knew, I thought all this joy was just for desktop. That’s something Mozilla might want to trumpet more loudly?)

                                                                                              By the bye, if you or a colleague are thinking of writing about the social side of project Quantum, I for one would be well interested. AFAIK projects this successful generally involve some rather successful teambuilding and vision-sharing and project-managing, too, and I always enjoy reading about that sort of thing.

                                                                                              1. 4

                                                                                                Much of the android stuff doesn’t land until 58; I bet we’ll make more noise about it then.

                                                                                            1. 6

                                                                                              I’ve been using semantic versioning for my own projects now for a few years, and in my experience with it, it’s great (if used correctly as tscs37 mentions) for libraries (or modules) but less so for applications.

                                                                                              My gripe with semantic versioning is that it allows pre-release and build metadata as part of the version string. I think this is wrong as it’s ill-defined and complicates dependency tracking (I’m also not a fan of pre-releases—why prolong the release? It won’t get much additional testing because of a general reluctance of using pre-releases). Just use X.Y.Z.

                                                                                              Also, for an extended meditation on backwards compatibility, read The Old New Thing, which explains the lengths that Microsoft goes to to maintain backwards compatibility (and the problems that can cause).

                                                                                              1. 4

                                                                                                Build metadata SHOULD be ignored when determining version precedence.

                                                                                                Pre-release versions have a lower precedence than the associated normal version.

                                                                                                So, only the pre-release versions do, and most implementations I know of only support using a pre-release version if you explicitly ask for it.

                                                                                                1. 1

                                                                                                  I’m also not a fan of pre-releases—why prolong the release? It won’t get much additional testing because of a general reluctance of using pre-releases).

                                                                                                  Our customers extensively test our release candidates. Linux kernel release candidates are also pretty thoroughly tested. And no, I don’t think there is a reasonable alternative to RCs.

                                                                                                1. 5

                                                                                                  Of the projects listed, I’m particularly confused by the popularity of Hugo. What was wrong with Jekyll? I know everybody loves a static generator, but is “because go” an interesting differentiator in this space?

                                                                                                  1. 4

                                                                                                    Hugo’s a ton faster than Jekyll (like, fractions of a second v. seconds faster), works on Windows (as others have noted), and integrates directly with a pile of Go web servers, including Caddy. (I in turn use Caddy because it shipped HTTP/2 and one-line ACME support way before anything else did that, and it has a very, very simple configuration format that’s much harder to mess up than Apache or nginx. ) Hugo’s also stupidly easy to migrate to from Jekyll, making it easy to try out, which is why I jumped to it so easily. Further, because Hugo’s so popular, it’s getting ecosystem effects, where some CDNs actually just natively support Hugo-defined sites sanely. That’s not a feature of Hugo per se, but that kind of thing is also why I and many others used WordPress for a long time despite preferring either MovableType or something bespoke: it’s much easier to go with the dominant technologies.

                                                                                                    So, some “it’s faster and easy to verify that,” some “it’s got an ecosystem now,” some “it works on Ruby-hostile operating systems”.

                                                                                                    1. 1

                                                                                                      Does Jekyll do a full rebuild of the site every time? What about Hugo?

                                                                                                      I wrote a Makefile for the Oil blog [1] to support incremental builds, and I thought it might have been overkill at first. But even with a few dozen posts, incremental builds speed things up drastically, and they help the writing workflow. And now I have more than a few dozen posts!

                                                                                                      If you have incremental builds, I don’t imagine that the difference between Ruby and Python is significant. If you don’t, then I imagine it’s probably significant. You can “brute force” it with Go’s speed.

                                                                                                      I also have “incremental deploy” with rsync. Makefiles + rsync FTW! :)

                                                                                                      (My site doesn’t use any kind of framework – it’s a Makefile, shell scripts, a few hundred lines of Python, and Markdown.)

                                                                                                      [1] http://www.oilshell.org/blog/

                                                                                                      1. 2

                                                                                                        Hugo not only does incremental builds, but also knows the dependency chain for templates, allowing it to only regenerate what was changed in surprisingly complex scenarios. I think Jekyll actually also does something similar, but I have a hunch it’s not as intelligent—or else, the critical path may lie in an odd place compared to Hugo. I’m not sure.

                                                                                                    2. 3

                                                                                                      I don’t fancy Go at all, but picked Hugo for Contributor Covenant for these reasons:

                                                                                                      • Easy for non-devs to install (a self-contained binary, all deps static linked.)
                                                                                                      • Multilingual out-of-the-box.
                                                                                                      • And yes, fast.
                                                                                                      1. 3

                                                                                                        When I tried Jekyll I found it really hard to do anything too different from a blog. And it doesn’t work on Windows.

                                                                                                        1. 1

                                                                                                          It’s a pain in the ass on Windows for several reasons, but it does work.

                                                                                                          The docs are bad for non-blog things but it mostly boils down to “don’t use _posts and just make your own folders.”

                                                                                                        2. 1

                                                                                                          I have tried a couple of static site generators. Especially also Jekyll. I cannot pinpoint it, but Hugo felt a lot more straight forward to use for me.

                                                                                                          However that’s highly subjective and may be related to trying Hugo very late. Also I’d be cautious on saying that the chosen language has much to do with.

                                                                                                          I get why you are surprised though, because I was myself. A lot of the time Go projects just work. The opposite is true for many kinds of Go libraries though. One is kind of advised stick to stdlib (and /x/foo) and not even go for libraries which appear to be widely used. At least I constantly stumble across strange APIs, really rough edges and antipattern usage a lot there. I think many of the libraries outside of Go are made by people who come from some other language and try to copy what’s commonly used there, while ignoring or trying to bend the Go language. However, that is rather common for young and hyped languages. I am sure this will change over time. After all it hasn’t been eight years for most of its users. :)