1. 3

    GitHub is changing. It is important to understand that GitHub is moving away from being a Git Repository hosting company and towards a company that provides an entire ecosystem for software development.

    Hasn’t this always been the case?

    1. 5

      No, if you look back to when Git was first becoming popular (around 2008) the alternatives to hosting your own Git repository were very cumbersome. Using pull requests instead of sending patches was part of the draw, but the main thing was “be able to use Git without putting up with (for instance) the terrible user interface of Rubyforge.

      1. 6

        But a pull request isn’t part of Git, so I think my postulate still holds true.

        1. 6

          What I said was that pull requests were a small part of the draw, and the main thing was being able to host a git repository without dealing with apache or sourceforge.

          1. 1

            Is it possible to get actual numbers from some kind of VCS server log from 11 years ago?

            Did you know Fossil is 12 years old? http://fossil-scm.org/home/timeline?c=a28c83647dfa805f I just found out.

            1. 1

              I’m having a hard time seeing any connection between what you said and what I said. Wrong thread, maybe?

              1. 1

                i get your lack of sight on account of my lack of clarity so here’s some of that:

                when Git was first becoming popular (around 2008)

                … as a rhetorical point, boils down to a dispute between you and zg regarding these like long-range ecosystemic benefits (and the pull request thing is kind of an aside - you are in agreement more than youre in disagreement, imho, and causality is not inferrable about why git and github pulled ahead, is it? it’s pretty contingent)

                is it possible to get actual numbers

                this refers to numbers about popularity

                otherwise talking about some farfagnugen ecosystem-level obscurities is kind of pointless

                i mean zg kind of just said rhetorically that he doesn’t agree with the fossil guy and you kind of just said that one time in history one thing happened once, and so i figured that having maybe some actual rigorous data would allow us to come to some kind of conclusion, but I know that it’s not very important or interesting, but i was just curious, actually, and i feel like there’s a slim chance that some literal data on vcs usage might exist and that that would solve a lot of these “does the ecosystem come before the theoretical innovation in VCS design or the chicken before the egg or what?” types of questions. since they take place in an ahistorical vacuum otherwise. doy.

      2. 1

        Ya pretty much. I think the author missed the point of Github. It was never really about Git more than to the extent that Git appeared to be in the lead at the time and perhaps some preference by the founders.

        The value proposition is everything around supporting the Git workflow.

        1. 2

          A few things:

          1. Fossil exists in contradiction to the value proposition of “everything supporting git,” to solve problems that aren’t yet solved…

          2. Fossil is NOT git, in the same sense that, once upon a time, GNU was supposed to be NOT Unix…

          3. Literally, GitHub invited the guy AS the Chief Point-Misser in a special critical capacity.

          4. Everything around supporting the git workflow is a value proposition – only to the business supporting “everything around the git workflow! …

          4.1 (continuing) … – but that’s a proposition about the ecosystem NOT to the conceptual framework of what it means to “do VCS stuff.”

          I explained this to epilys, but also wanted to point out to you, that the author probably “missed the point” of GitHub intentionally, whereas you missed precisely that point…

          1. 1

            If you say so.

            1. 0

              aren’t you saying that GitHub matters but VCS does not?

              aren’t you saying that Git is irrelevant and the whole thing should just be called “Hub?”

              when you say “it was never really about Git… etc., etc.,” what do you mean by “it,” if not GitHub?

              aren’t you just saying “value proposition” in the hopes that everybody forgets that GitHub is a “value-proposing business”… running on a vcs called GIT?

          2. 1

            I disagree. I’ve been a Github user since 2009ish and I used it 90% for “hosting a git repository” - that was in addition to hosting my own git repos via ssh/gitolite, so also some mirroring.

            When my company paid for github, it was to have a git repo. And pull requests, but nothing else. And I simply don’t believe I’m the outlier here. Sure, webhooks were nice but that’s the extent of any added benefit there.

          3. 1

            #include jolly-sarcasm-compiler.h

            I don’t know! But let me look in a BOOK or a TECHNICAL GUIDE at the very least - oh here’s one…

            https://lobste.rs/s/v4jcnr/technical_guide_version_control_system#c_bolhkj

            When you say “always” do you mean “since we moved away from mainframes?”

          1. 5

            I don’t understand the focus on “idiomatic” code. Unidiomatic code is not incorrect code.

            1. 2

              Unidiomatic code is likely to violate the Principle of Least Surprise. In turn, it introduces a gaping vector for bugs. Devs will assume the unidiomatic code works like the idiomatic code and has the same semantics.

              That’s not to say that devs are okay to not understand the code - but when you’re moving fast and breaking things, the additional cognitive load of something that is unidiomatic is a burden.

              1. 3

                Author here, I disagree. Unidiomatic code is a code smell, and needs to be corrected - especially if it has consequences on code which depends on it.

                1. 3

                  I think it’s a little more complicated.

                  There is Flask as an example given. Most flask projects I know are small and MVP - the kind where you quickly need a web endpoint for a library in python more than solving a problem per se. If your important library was in another language, you wouldn’t choose Flask (it’s awesome, but not the best web framework in the world without further discussion). So suddenly your perfectly well and idiomatic python code (in a small project) is not idiomatic anymore - no one cares. Why would you rewrite a perfectly fine Python 3.3 project just because everything has to be async in 3.7 (I didn’t look up the numbers, you get my point).

                  And unless there’s a new swiss army knife of nice and easy web applications, people will probably continue to use Flask, and that’s a good thing.

                  1. 1

                    Agreed. If all new code that a team writes starts using the new idiomatic approach, the unidiomatic code is now a piece of tech debt that needs to either be paid, or will forever result in extra cognitive load, however small or large it may be.

                    And it will happen again, with more and more idioms, over time. This kind of divergence takes a toll. The barrier to entry for new developers becomes a bit higher each time.

                    As someone who dealt with an 18 year old codebase with a lot of this - and also as someone who contributed to that mess - it’s exhausting.

                1. 1

                  I’ve been playing with Pulumi and getting back into the habit of building small things. So much of my programming lately has been Serious Business high volume processing systems or giant deployments that I’ve lost the fun part of building things.

                  I’m building a little dictionary web app first. Very basic stuff - mostly to play with new tech and try coming at ideas from new angles.

                  1. 6

                    Side projects, if done in the way that demonstrates a mostly realistic deployment teach you a lot about the “shadow work” of developing software. Writing the code is only part of the work. Getting it tested, packaged, deployed, and monitored is the other 50% at least.

                    Note - it may sound like I’m talking only about web services but those other “tasks” apply to desktop software as well. There’s a lot of peripheral work to go from “programming” to “software engineering”.

                    1. 1

                      Agreed

                    1. 2

                      Last desktop I bought was an Alienware I found on sale. At the time, it was the height of Bitcoin/shitcoin mining and video cards cost crazy bucks. The Alienware had an Nvidia 1080Ti in it for a much cheaper price than I could get as a standalone part so I jumped on it.

                      It’s been a good machine. I updated the main drive to a much faster NVMe SSD and bumped the RAM from 16GB to 64GB. It runs Windows 10 Pro and then I run a bunch of Linux VM’s off of it to do things. Also gets used occasionally for gaming. Overall pretty happy with it. It’s been a reliable PC and I would probably do it again just because I’m tired of building my own PC at this point.

                      1. 1

                        this is exactly why I’m confused, graphic cards costs almost as much as an off the shelf PC! or in some cases more expensive

                      1. 2

                        A neat observation though I’d liked to understand why. I’m not very strong on how modern CPUs work so things like branch prediction are a little bit of a mystery to me in practice.

                        1. 4

                          Branch predictors unfortunately are a black box. They’re an implementation detail subject to change. AMD went as far as calling theirs a “neural net” (which is probably a perceptron).

                          My guess is that the problem overall can be treated similarly to cache pressure: if you add an easily-cacheable memory access, even when it is cheap by itself, it will push something else out of the cache and make some other access more expensive.

                          Branch predictors have a finite-size hashmap of locations they track, so if you add more branches, the predictor will have to stop tracking some other branches. Another possibility is that the predictor evaluates behavior of multiple branches together as a group, and adding an unusual branch there confuses it.

                        1. 3

                          I’ve used Rusoto for some small accessory project, and found it to mostly work pretty well, but it feels a bit immature, like a few aspects of it could stand to see some more use and adjustments based on usage patterns of heavy AWS users.

                          1. 1

                            I think a lot of the “immature” feel comes from it seemingly being generated?

                            I think the most irritating thing about it is that it’s continually breaking the API. Or at least it was through the 0.2x.y to 0.3x.y versions. We only update our project every 6 months or so because there’s the sunk cost of updating our code to the new API surface which adds seemingly little value.

                          1. 1

                            We have hugely elastic workloads. Though - that doesn’t really strictly need containers, so much as Kubernetes was a relatively popular tech when our elastic workload was spun up. Docker is fine, but it’s really more about Kubernetes.

                            I didn’t have any weight in the decision - it was before my time. Given my own insight, I probably wouldn’t have chosen the same tech stack.

                            That said - not sure what I would pick. The solution we have works well enough. No real need to fix something that is working well enough as an architecture. Our real problems are poorly monitored components and noisy operational alerts.

                            1. 2

                              Well the biggest problem is there aren’t great complete “solutions” for creating repeatable deployments that aren’t using containers.

                              You can get a long way with a proper Salt deployment for at least machine setup and configuration. I don’t have a huge amount of experience there but folks I work with are beginning to do this with software that simply cannot be containerized.

                              1. 6

                                Well the biggest problem is there aren’t great complete “solutions” for creating repeatable deployments that aren’t using containers.

                                There most certainly are.

                                1. 1

                                  Neato. Thanks for the info n

                                2. 1

                                  Interesting. Do you know of “non-great” solutions?

                                  Background is I am currently developing a lightweight CI solution without docker (because I found that either they are big like Jenkins/Gitlab or they are built to use docker). So I am wondering if it would make sense to develop this into the direction of deployments or create a sibling lightweight program for deployments.

                                  1. 1

                                    Honestly, not much that isn’t tied to huge monolithic systems.

                                    I’m not a huge fan of Docker and Kubernetes but I recognize their value in codifying deployment into code. I don’t deploy many services as a hobby so I haven’t sorted our the none-container solution.

                                    At work we are heavily Kubernetes and Docker so I work within that framework. It has warts but it works well enough for an environment that runs ~4k containers within K8.

                                    1. 1

                                      We’ve been using a combination of Terraform (initial setup) plus Nix/NixOS for our containerless deployments. There is also an autoupdater running on each machine that monitors the CI for new derivations and does an update if there is, with rollback in case of a problem.

                                      1. 1

                                        Ansible? I find it perfectly acceptable for small to medium sized deployments. Can do orchestration too, although of course specialized tools like Terraform are better at that.

                                    1. 9

                                      Except that, sadly, the tooling is pretty weak.

                                      I like the language but I don’t like the experience of developing with it. I’ve grown soft after a couple of years of Rust development.

                                      1. 6

                                        I don’t know where Rust thinks it’s going, though. I can’t even update to the latest version of Bitwarden_rs because it requires a rust-nightly compiler which won’t build on FreeBSD because it dies with an invalid memory reference

                                        error: process didn’t exit successfully: /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/bootstrap/debug/rustc -vV (signal: 11, SIGSEGV: invalid memory reference)

                                        1. 5

                                          That’s Bitwarden_rs’s fault for using nightly, imo.

                                          Looks like this is bug has already been reported with bitwarden-rs though: https://github.com/dani-garcia/bitwarden_rs/issues/593

                                          1. 3

                                            Every non-trivial rust program I’ve tried to use so far requires a nightly compiler. This ecosystem is just a trash fire.

                                            1. 8

                                              I’ve got an 80k+ LOC Rust codebase I work with at Rust that doesn’t use nightly. In fact, we’ve never needed nightly… The program runs on production workloads just fine.

                                              1. 12

                                                I’m using Rust professionally and I don’t even have a nightly compiler installed on my computer. Almost all Rust large programs I see don’t require nightly compilers. Any that do tend to be OS kernels, with exception of a few web apps like this project that use Rocket, a web framework (with many good alternatives, I might add, not to disparage Rocket) that requires syntax extensions and loudly states it requires nightly Rust (and is planning to target stable Rust next release apparently). People who use nightly are generally already writing something experimental which is explicitly not production-quality, or they’re writing something that’s working towards being ready for an upcoming feature (which allows the ecosystem to develop well in response to ecosystem changes, vs waiting months or years for trickle down as is common in other languages), and they’re targeting what is explicitly an alpha-quality compiler to do so.

                                                1. 3

                                                  People who use nightly are […] and they’re targeting what is explicitly an alpha-quality compiler to do so.

                                                  Or they just want to write benchmarks ;)

                                                  1. 7

                                                    criterion.rs is a better harness and works on stable Rust. I’ve been slowly migrating all my crate benchmarks to it. The only advantage of the built-in harness (other than compile times) is the convenient #[bench] annotation. But criterion will get that too, once custom test framework harnesses are stabilized. See: https://bheisler.github.io/post/criterion-rs-0-3/

                                                    1. 6

                                                      …and don’t want to use excellent third party tools that function on stable, like Criterion. ;)

                                                      I admit, the fact that Criterion works great on stable and the built in cargo bench doesn’t IS pretty dismal.

                                          1. 2

                                            If you can find it, Scientific Forth by JV Noble (same author as the article) is a great book on doing practical work in Forth.

                                              1. 1

                                                Looks like it. I have a nearly new physical copy that I bought from a friend when he retired.

                                            1. 3

                                              The couple of times I’ve written Scala for any sizable chunk of code, I came away underwhelmed. When I was in college, it was interesting because I knew OOP and wanted to learn FP. After using it for actual work, I’ve decided I’d instead write Java or Clojure.

                                              1. 2

                                                I’ve been picking up Common Lisp again. I have some work I’d like to do around web services and parsing logs that i feel like CL would match to nicely.

                                                Slowly learning that when I tried to learn it when I was 19, I definitely did not grok it’s power the way I do now. My day to day work is in Rust (>70k LOC codebase) and that’s helped open up my ideas. CL has mapped nicely to that work.

                                                1. 2

                                                  I’ve been countering the myth, too. I just think this person did a better job by using a lot of market-grabbing examples that won in this way.

                                                  1. 3

                                                    Agree vehemently. Most of my experience with people arguing about perf is them misquoting Knuth (”Optimization is the root of all evil in programming.”).

                                                    In reality, the process for building software should be:

                                                    • make it correct
                                                    • make it simple
                                                    • make it fast

                                                    Preferably follow that order but you should Perform every step.

                                                    1. 3

                                                      “Premature optimization is the root of all evil” is such a misunderstood quote. The full context really highlights what it’s about:

                                                      Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

                                                      The noncritical parts section is important: we shouldn’t spend time (initially) making fast the parts of the program that are seldom called, but we should spend the time necessary to make the core functionality fast. The small efficiencies bit is also important: we can let small efficiencies go by, but we probably shouldn’t let big inefficiencies go by.

                                                      1. 2

                                                        I get a lot of goodwill at my current job by doing that third step for our user-facing software. Most of what I do is trivial profiling and optimizations. A lot of goodwill.

                                                        1. 1

                                                          I’ll add the Richard Gabriel principle to get it 90% of the way to correct… works well enough… before correct. Maybe that, simple, and fast before correct.

                                                          1. 2

                                                            Ya - ”correct” is a pretty overloaded word. Sometimes you can simplify, removing unnecessary bits which allows you to get to ”correct” faster.

                                                      1. 71

                                                        Here’s a script to migrate your repos to hg.sr.ht:

                                                        https://hg.sr.ht/~sircmpwn/invertbucket

                                                        1. 4

                                                          I like competition in general. Sometime I love watching it happen, though. :)

                                                          1. 6

                                                            hey @SirCmpwn thanks a ton for that script. Just imported 19 repos (both git and hg) into sr.ht. Some of those repos were 9 years old. : )

                                                            1. 3

                                                              Great :)

                                                            2. 1

                                                              I went ahead and got a subscription for Source Hut even if I may only use it as a mirror for now.

                                                              I think diversity is good and would like to play more with it in the future :)

                                                              1. 0

                                                                I’m trying to do this migration and i’m gettin some errors related to JQ, “parse error: Invalid string: control characters from U+0000 through U+001F must be escaped at line 2, column 34”

                                                                where the bug track or whatever i can report this to you for? :)

                                                                1. 2

                                                                  Can you pull down the latest script and try again? I haven’t set up a bug tracker for this script.

                                                              1. 56

                                                                Fortunately, it’s also the best of currently available major browsers, so it’s not exactly a hardship.

                                                                1. 22

                                                                  Not on macOS. Sure, it has a whole lot of great features, but it’s just slow. It feels slow, looks slow, and macOS keeps telling me that Firefox is using an excessive amount of power compared to other browsers.

                                                                  I guess it’s too much to ask for, for Firefox to feel like a good, native macOS app, like Safari, but the fact of the matter is that that is why I don’t use it as my main browser.

                                                                  1. 19

                                                                    I use it on Mac OS X and it doesn’t feel slow to me at all. And it’s not using an excessive amount of power that I can tell. Perhaps it’s the version of Firefox being used?

                                                                    1. 14

                                                                      I’ve been sticking to Safari on MacOS because I’ve read that it really does make a difference to battery life (and I’m on a tiny Macbook so, you know, CPU cycles aren’t exactly plentiful). This thread just prompted me to check this for myself.

                                                                      I opened a typical work mix of 10 tabs in both Safari 12.1 and Firefox 66.0.3 on MacOS 10.14.4: google calendar + drive, an open gdocs file, two jira tabs, this lobsters thread (well, it is lunchtime…) and the rest github. Time for some anec-data! :-)

                                                                      After leaving both browsers to sit there for 10 mins while I made lunch (neither in the foreground, but both visible and showing a github page as the active tab), these are the numbers I eyeballed from Activity Monitor over about a 30 second period:

                                                                      Firefox:

                                                                      • Energy Impact: moving between 3.3 and 15.6, mostly about 4
                                                                      • CPU: various processes using 0.3, 0.4, 0.5 up to one process using 1.4% CPU

                                                                      Safari:

                                                                      • Energy Impact: moving between 0.1 and 1.3, mostly around 0.5
                                                                      • CPU: more processes than Firefox, but most using consistently 0.0 or 0.1% CPU

                                                                      Firefox isn’t terrible but Safari seems really good at frequently getting itself down to a near-zero CPU usage state. I’ll be sticking with Safari, but if I was on a desktop mac instead I think I’d choose differently.

                                                                      As an aside, Activity Monitor’s docs just say “a relative measure of the current energy consumption of the app (lower is better)”. Does anyone know what the “Energy Impact” column is actually measuring?

                                                                      1. 5

                                                                        I have had the same experience with Firefox/Chrome vs Safari.

                                                                        I use Chrome for work because we’re a google shop and I tend to use Firefox any time my MacBook is docked.

                                                                        But I’m traveling so much, I generally just use Safari these days.

                                                                      2. 9

                                                                        I use it on Mac OS X and it doesn’t feel slow to me at all.

                                                                        If you can’t feel and see the difference in the experience between, say, Firefox and Safari, I don’t know what to tell you.

                                                                        And it’s not using an excessive amount of power that I can tell. Perhaps it’s the version of Firefox being used?

                                                                        Have you tried checking in the battery menubar-thing? There’s an “Using Significant Energy” list, and Firefox is always on it on my machine if it’s running. And that is both Firefox as well as Firefox Nightly, and it is so for all versions since a long time. My two installs are updated per today, and it’s the same experience.

                                                                        1. 1

                                                                          If you can’t feel and see the difference in the experience between, say, Firefox and Safari, I don’t know what to tell you.

                                                                          There are plenty of people who can’t hear the difference between $300 and $2000 headphones. Yes, there are audiophile snobs who’re affronted by the mere idea of using anything but the most exquisitely constructed cans. But those people are a vanishingly small minority of headphone users. The rest of us are perfectly happy with bog standard headphones.

                                                                          Apple likely had to descend through numerous circles of hell while hand-optimizing Safari for the single platform that it needs to run on. Will Firefox get there? Unlikely. Will most users even notice the difference? Most certainly not.

                                                                          1. 6

                                                                            They will when their battery life is abysmal and they start hearing that it’s because of Firefox.

                                                                            I really want to see Firefox get more adoption, but there are a lot of techies with influence who will keep away because of this, myself included. It’s not a convenience thing - I just can’t get to mains power enough as it is in my job, so more drain is a major problem.

                                                                            1. 1

                                                                              They will when their battery life is abysmal and they start hearing that it’s because of Firefox.

                                                                              The problem is that the feedback cycle isn’t even long enough for them to hear about this. The cause and effect are almost immediate depending on your display resolution settings with bug 1404042.

                                                                              1. 3

                                                                                This is what happens when you fight the platform.

                                                                                1. 2

                                                                                  This is what happens when the platform is hostile to outsiders.

                                                                                  1. 8

                                                                                    See, I don’t see it that way. I see it as Mozilla deciding on an architecture for their software that renders that software definitely suboptimal on the Mac. It’s just a bad fit. I’m not claiming that Mozilla should have done things differently – they are welcome to allocate their resources as they see fit, and the Mac is most definitely a minority platform. There are many applications that run on the Macintosh that are not produced by Apple that don’t have these problems.

                                                                                    iOS is a different story, one where hostility to outsiders is a more reasonable reading of Apple’s stance.

                                                                            2. 2

                                                                              Now that I’m at work, I’m seeing what hjst is showing. This doesn’t bother me that much because I use the laptop at work more like a desktop (I keep it plugged in). But yes, I can see how Firefox might be a bit problematic to use on the Mac.

                                                                            3. 1

                                                                              I’ll have to check the laptop at work. At home I have a desktop Mac (okay, a Mac mini).

                                                                            4. 4

                                                                              There are known issues which are taking a long time to fix. Best example is if you change the display resolution on a retina Mac. You can almost see the battery icon drain away on my machine.

                                                                              1. 3

                                                                                I find it depends a lot on what FF is doing - usual browsing is fine, but certain apps like Google Docs or anything involving the webcam make it go crazy.

                                                                                1. 20

                                                                                  Google sites, unsurprisingly if disappointingly, don’t work as well in Firefox as they do in Chrome. But that’s really on Google, not Mozilla.

                                                                                  1. 15

                                                                                    They used to actively break them - e.g. GMail would deliberately feed Firefox Android a barely-functional version of the site. https://bugzilla.mozilla.org/show_bug.cgi?id=668275 (The excuse was that Firefox didn’t implement some Google-specific CSS property, that had a version in the spec anyway.) They’ve stopped doing that - but Google’s actions go well beyond passively not-supporting Firefox.

                                                                              2. 5

                                                                                For me, it feels faster than Chrome on MacOS, but the reason I don’t use it is weird mouse scroll behavior (with Apple mouse). It differs too much from Chrome’s behavior. I don’t know how to debug it, how to compare, what is right behavior (I suspect Chrome’s scrolling is non-standard and it dampens acceleration, while Firefox use standard system scrolling). It just feels very frustrating, but in subtle way: I become nervous after reading lots of pages (not right after the first page). I tried various mouse-related about:config settings but none of them had any effect (and it’s hard to evaluate results because differences are very subtle).

                                                                                Maybe the answer is to use standard mouse with clicky scroll wheel, but I hate clicky scroll wheels. “Continuous” scrolling is one of the best input device improvements of recent times (however it would be better if it was real wheel/trackball instead of touch surface).

                                                                                1. 1

                                                                                  Have you tried Nightly yet? I believe there are some great improvements made recently for this. It isn’t all fixed, but it has improved.

                                                                                  1. 3

                                                                                    I’m on Nightly right now, and it hasn’t improved for me at least.

                                                                                  2. -1

                                                                                    I think macOS disadvantages apps that compete with Apple products. That’s unfortunate though.

                                                                                    1. 7

                                                                                      Any evidence for this statement?

                                                                                      1. 9

                                                                                        Do you have any proof?

                                                                                        Anecdotally I use a lot of third-party apps that are a lot better than Apples contemporaries.

                                                                                        I just think the truth is that Firefox’ hasn’t spent enough time on optimizing to each platform, and on macOS where feel and look is a huge deal, they simply fall through.

                                                                                        1. 1

                                                                                          The reports that Firefox has issues on macOS and Apple’s behaviour with iOS, for starters.

                                                                                          1. 7

                                                                                            Often the simplest solution is the correct one, meaning that it’s more likely that Firefox just hasn’t optimized for macOS properly. If you look at the bug reports on the bug tracker, this seems to be the case.

                                                                                            Also if your theory were to be correct, why is other non-apple browser like chromium not having these issues? Could it perhaps be that they have in fact optimized for macOS, or do you propose that apple is artifically advantaging them?

                                                                                            1. 13

                                                                                              pcwalton hints at twitter that gains that e.g. Safari and Webkit have is through the usage of private API in macOS. You could probably use those API as well from Firefox, at the cost of doing tons of research on your own, while Webkit can just use them. (further down the thread, he hints at actually trying to bind to them)

                                                                                              https://twitter.com/pcwalton/status/1068933432275681280

                                                                                              1. 3

                                                                                                That’s very interesting, and it’s probably a factor. However these are problems that Firefox have, not all third-party browsers. No Chromium based browser have these issues, at least in my experience. Maybe it’s through privat API that you can optimise a browser the most on macOS, but it doesn’t change the fact that Firefox is under-optimised on macOS, which is why it performs as it does.

                                                                                                1. 8

                                                                                                  Point being: Chromium inherits optimisations from apples work which Mozilla has to work hard to develop in a fashion working with their architecture. Yes, there’s something to be said about organisational priorities, but also about not being able to throw everyone at that problem.

                                                                                                  I’m really looking forward to webrender fixing a lot of those problems.

                                                                                                  1. 1

                                                                                                    And it’s a sad fact, because I’d love to use Firefox instead of Safari.

                                                                                                    1. 7

                                                                                                      Sure, from a users perspective, all of that doesn’t matter.

                                                                                                      Just wanted to say that this is hard and an uphill battle, not that people don’t care.

                                                                                                      The Firefox team is well aware of those two contexts.

                                                                                              2. 0

                                                                                                It’s certainly possible. But at the very least Apple has little incentive to have Firefox work well on macOS. Chrom{e|ium} is so widely used, that Apple would hurt themselves if it didn’t work well on macOS.

                                                                                                I’d be a bit surprised if Mozilla is really falling down on optimising Firefox on macOS. It’s not as if Mozilla is a one man operation with little money. But perhaps they decided to invest resources elsewhere.

                                                                                          2. 1

                                                                                            That’s true in cases where apps want you to pay for features (like YouTube not offering Picture-in-Picture since it’s a paid feature and Apple wants money for it to happen) but not true in the case of Firefox. Unfortunately, Firefox’s JavaScript engine is just slower and sucks up more CPU when compared to others.

                                                                                        2. 7

                                                                                          Yeah, I’ve switched between Firefox and Chrome every year or two since Chrome came out. I’ve been back on Firefox for about 2 years now and I don’t see myself going back to Chrome anytime soon. It’s just better.

                                                                                          1. 3

                                                                                            Vertical tabs or bust.

                                                                                          1. 2

                                                                                            Mostly still trying to get my footing as a Dev Lead. Couple months ago, I got moved officially into a Dev Lead role and that’s been interesting - trying to determine costing and coordinate a team is a new and fun ball game I’ve not played yet.

                                                                                            Besides that, writing a lot of Rust which isn’t new.

                                                                                            1. 4

                                                                                              Feel like I’d rather just sit quietly with a notebook and think about code than work with this janky-at-best setup.

                                                                                              To each their own though.

                                                                                              1. 30

                                                                                                I enjoyed the author’s previous series of articles on C++, but I found this one pretty vacuous. I think my only advice to readers of this article would be to make up your own mind about which languages to learn and use, or find some other source to help you make up your mind. You very well might wind up agreeing with the OP:

                                                                                                Programmers spend a lot of time fighting the borrow checker and other language rules in order to placate the compiler that their code really is safe.

                                                                                                But it is not true for a lot of people writing Rust, myself included. Don’t take the above as a fact that must be true. Cognitive overheads come in many shapes and sizes, and not all of them are equal for all people.

                                                                                                A better version of this article might have went out and collected evidence, such as examples of actual work done or experience reports or a real comparison of something. It would have been a lot more work, but it wouldn’t have been vacuous and might have actually helped someone answer the question posed by the OP.

                                                                                                Both Go and Rust decided to special case their map implementations.

                                                                                                Rust did not special case its “map implementation.” Rust, the language, doesn’t have a map.

                                                                                                1. 16

                                                                                                  Hi burntsushi - sorry you did not like it. I spent months before this article asking Rust developers about their experiences where I concentrated on people actually shipping code. I found a lot of frustration among the production programmers, less so among the people who enjoy challenging puzzles. They mostly like the constraints and in fact find it rewarding to fit their code within them. I did not write this sentence without making sure it at least reflected the experience of a lot of people.

                                                                                                  1. 20

                                                                                                    I would expect an article on the experience reports of production users to have quite a bit of nuance, but your article is mostly written in a binary style without much room for nuance at all. This does not reflect my understanding of reality at all—not just with Rust but with anything. So it’s kind of hard for me to trust that your characterizations are actually useful.

                                                                                                    I realize we’re probably at an impasse here and there’s nothing to be done. Personally, I think the style of article you were trying to write is incredibly hard to do so successfully. But there are some pretty glaring errors here, of which lack of nuance and actual evidence are the biggest ones. There’s a lot of certainty expressed in this article on your behalf, which makes me extremely skeptical by nature.

                                                                                                    (FWIW, I like Rust. I ship Rust code in production, at both my job and in open source. And I am not a huge fan of puzzles, much to the frustration of my wife, who loves them.)

                                                                                                    1. 4

                                                                                                      I just wanted to say I thought your article was excellent and well reasoned. A lot of people here seem to find your points controversial but as someone who programs C++ for food, Go for fun and Rust out of interest I thought your assessment was fair.

                                                                                                      Lobsters (and Hacker News) seem to be very favourable to Rust at the moment and that’s fine. Rust has a lot to offer. However my experience has been similar to yours: the Rust community can sometimes be tiresome and Rust itself can involve a lot of “wrestling with the compiler” as Jonathan Turner himself said. Rust also provides some amazing memory safety features which I think are a great contribution so there are pluses and minuses.

                                                                                                      Language design is all about trade-offs and I think it’s up to us all to decide what we value in a language. The “one language fits all” evangelists seem to be ignoring that every language has strong points and weak points. There’s no one true language and there never can be since each of the hundreds of language design decisions involved in designing a language sacrifices one benefit in favour of another. It’s all about the trade-offs, and that’s why each language has its place in the world.

                                                                                                      1. 10

                                                                                                        I found the article unreasonable because I disagree on two facts: that you can write safe C (and C++), and that you can’t write Rust with fun. Interpreted reasonably (so for example, excluding formally verified C in seL4, etc.), it seems to me people are demonstrably incapable of writing safe C (and C++), and people are demonstrably capable of writing Rust with fun. I am curious about your opinion of these two statements.

                                                                                                        1. 8

                                                                                                          I think you’re making a straw man argument here: he never said you can’t have fun with Rust. By changing his statement into an absolute you’ve changed the meaning. What he said was “Rust is not a particularly fun language to use (unless you like puzzles).” That’s obviously a subjective statement of his personal experience so it’s not something you can falsify. And he did say up front “I am very biased towards C++” so it’s not like he was pretending to be impartial or express anything other than his opinion here.

                                                                                                          Your other point “people are demonstrably incapable writing safe C” is similarly plagued by absolute phrasing. People have demonstrably used unsafe constructs in Rust and created memory safety bugs so if we’re living in a world of such absolute statements then you’d have to admit that the exact same statement applies to Rust.

                                                                                                          A much more moderate reality is that Rust helps somewhat with one particular class of bugs - which is great. It doesn’t entirely fix the problem because unsafe access is still needed for some things. C++ from C++11 onwards also solves quite a lot (but not all) of the same memory safety issues as long as you choose to avoid the unsafe constructs, just like in Rust.

                                                                                                          An alternative statement of “people can choose to write safe Rust by avoiding unsafe constructs” is probably matched these days with “people can choose to write safe C++17 by avoiding unsafe constructs”… And that’s pretty much what any decent C++ shop is doing these days.

                                                                                                          1. 5

                                                                                                            somewhat with one particular class of bugs

                                                                                                            It helps with several types of bugs that often lead to crashes or code injections in C. We call the collective result of addressing them “memory safety.” The extra ability to prevent classes of temporal errors… easy-to-create, hard-to-find errors in other languages… without a GC was major development. Saying “one class” makes it seem like Rust is knocking out one type of bug instead of piles of them that regularly hit C programs written by experienced coders.

                                                                                                            An alternative statement of “people can choose to write safe Rust by avoiding unsafe constructs” is probably matched these days with “people can choose to write safe C++17 by avoiding unsafe constructs”

                                                                                                            Maybe. I’m not familiar with C++17 enough to know. I know C++ was built on top of unsafe language with Rust designed ground-up to be safe-as-possible by default. I caution people to look very carefully for ways to do C++17 unsafely before thinking it’s equivalent to what safe Rust is doing.

                                                                                                    2. 13

                                                                                                      I agree wholeheartedly. Not sure who the target survey group was for Rust but I’d be interested to better understand the questions posed.

                                                                                                      Having written a pretty large amount of Rust that now runs in production on some pretty big systems, I don’t find I’m “fighting” the compiler. You might fight it a bit at the beginning in the sense that you’re learning a new language and a new way of thinking. This is much like learning to use Haskell. It isn’t a good or bad thing, it’s simply a different thing.

                                                                                                      For context for the author - I’ve got 10 years of professional C++ experience at a large software engineering company. Unless you have a considerable amount of legacy C++ to integrate with or an esoteric platform to support, I really don’t see a reason to start a new project in C++. The number of times Rust has saved my bacon in catching a subtle cross-thread variable sharing issue or enforcing some strong requirements around the borrow checker have saved me many hours of debugging.

                                                                                                      1. 0

                                                                                                        I really don’t see a reason to start a new project in C++.

                                                                                                        Here’s one: there’s simply not enough lines of Rust code running in production to convince me to write a big project in it right now. v1.0 was released 3 or 4 years ago; C++ in 1983 or something. I believe you when you tell me Rust solves most memory-safety issues, but there’s a lot more to a language than that. Rust has a lot to prove (and I truly hope that it will, one day).

                                                                                                        1. 2

                                                                                                          I got convinced when Rust in Firefox shipped. My use case is Windows GUI application, and if Firefox is okay with Rust, so is my use case. I agree I too would be uncertain if I am doing, say, embedded development.

                                                                                                          1. 2

                                                                                                            That’s fair. To flip that, there’s more than enough lines of C++ running in production and plenty I’ve had to debug that convinces me to never write another line again.

                                                                                                            People have different levels of comfort for sure. I’m just done with C++.

                                                                                                      1. 16

                                                                                                        Having spent the last 6 months working Rust, I’d disagree with his conclusion around Rust being prideful about pushing the borrow checker.

                                                                                                        The language is explicit in how you should use it - the rules are different than someone coming from C++ or C# might expect. It is to be expected that you fight the compiler - it’s a different way of thinking. That doesn’t mean Rust is right but it also doesn’t mean it’s wrong. It’s an opinion.

                                                                                                        This is similar to new users of Haskell fighting purity. Just because Haskell is pure doesn’t mean it’s right or wrong - it’s a design choice that you have to learn to work with.

                                                                                                        1. 1

                                                                                                          I think we have to admit that, for most people, the just get it to compile->runtime error->printf debugging loop is preferable. Even if only because it feels more productive.

                                                                                                          1. 8

                                                                                                            There is quite a large class of bugs that Rust purports to fix in which you only get a runtime error if you’re lucky. At least, when compared to C or C++.

                                                                                                            1. 0

                                                                                                              You’re right. It’s closer to a (wait for the world to explode->printf debugging->wait again) loop. This goes along with the metaphor of building software as construction. There’s a whole group of people who just want to duct tape that leak under the sink. They aren’t building a house or even a shed, as much as they are temporary tenants. You know you won’t be living in the house forever, so it’s not worth it to actually fix the problem.

                                                                                                              1. 2

                                                                                                                I do think most source codes live too short to care, but shouldn’t systems be built to last? I think Rust is a better systems programming language than C or C++ in that sense.

                                                                                                                1. 3

                                                                                                                  I do think most source codes live too short to care

                                                                                                                  Even then, Wirth’s languages showed you could get fast compiles, be safe by default, have clean module system, and support concurrency built-in. C the language is still worse if one aims to quickly throw together code that doesn’t crash or get hacked as often.

                                                                                                                2. 1

                                                                                                                  I’d contend that maybe those folks shouldn’t be building systems :). Until you have to deal with servicing a huge number of client machines, the guarantees don’t really set in as to how much they help.

                                                                                                              2. 2

                                                                                                                I’d disagree. That feels considerably less productive for systems programming. In fact, it’s infuriating. I mostly work in client-side software developed on a large-to-huge scale. Runtime failures are the last thing I want to deal with - it means I have to update upwards of 500k clients.

                                                                                                                While it might be acceptable to deal with compile->runtime error->printf debug on the server side. It’s hardly a good solution on client side – even if it was how we dealt with it for many years.

                                                                                                                1. 1

                                                                                                                  Yes, I agree that certain tasks require different tools. I was trying to specifically point out that generalization is for most people. E.g. quick data analysis jobs, internal web UI, etc. Obviously dynamic or interpreted languages are better for such tasks, than something like C. Personally I see the future of C being for microcontroller projects or toy ISAs, where you care about ease of implementation, and support for better defined languages take over primary systems. That may take another half-century at this rate, though.

                                                                                                                2. 1

                                                                                                                  Well, there are those who feel that compile/type errors hold back their unbounded creativity, but that doesn’t mean those analyses are bad.