1. 37

    Although I’m glad this article explicitly distinguishes uses of Go and Rust, I still don’t understand why people keep trying to compare these two languages. They clearly have different approaches to different goals.

    From the panel Systems Programming Languages in 2014 and Beyond:

    When we first announced Go, we called it a systems programming language, and I slightly regret that because a lot of people assumed it was an operating systems writing language. What we should have called it is a server writing language, which is what we really thought of it as.
    —Rob Pike (Go creator)

    Writing client-side applications. The polar opposite of what Go is designed for. In these applications, you have high latency needs, high security requirements, a lot of requirements that don’t come up on the server side.
    —Niko Matsakis (Rust dev)

    1. 26

      I still don’t understand why people keep trying to compare these two languages.

      I think this is very simple. For a long time people dreaded writing C++ and were looking for a(n imperative) language that compiles to native binaries. Then there were (some time apart) Go and Rust [1]. Both languages filled the ‘a more modern language that compiles to native code’-niche. People start to compare them, besides being very different languages.

      Besides that, they have overlapping niches where they excel, such as command-line tools.

      [1] Of course, there were many other alternatives, such as OCaml, Haskell, D, Ada, etc. But they never attained critical mass.

      1. 4

        I’m looking at Crystal currently, as a possible contender in this field (GC, native, fast, and expressive). Looks very promising.

        1. 2

          Of course, there were many other alternatives, such as OCaml, Haskell, D, Ada, etc. But they never attained critical mass.

          What qualifies as critical mass? The languages you cite are all self-sustaining, even if their ecosystems don’t grow at the same speed.

          1. 10

            What qualifies as critical mass?

            Obviously, there is no fixed definition. But it’s clear that a language must have an library ecosystem of a certain size, IDE support, documentation, availability of programmers, etc. before any random given company will seriously consider it for their next project.

            Whether these are well-justified reasons is another question. Whatsapp used Erlang and was a fraction employee-wise from many social network competitors and created a crazy amount of value (for the owners and shareholders).

            1. 8

              Critical mass such that people need to write blog posts clarifying “why go and not x”?

          2. 12

            Go is faster than Python.

            Rust is safer than C, and, once you get the ownership concept down, safer and easier to understand than C++.

            (This post is unapologetically in the style of Paul Graham’s ha-ha-only-serious essay “What Languages Fix” which is still a pretty good read.)

            1. 11

              Go is faster and easier to build large scale systems in than Python or Ruby.

              1. 9

                and easier to build large scale systems in

                That’s pretty subjective. Can we stick to quantitatively verified facts instead of playing “my X can beat up your X,” please?

                1. 9

                  How is “Go is easier to build large scale systems in than Python or Ruby” any more subjective than “Rust is easier to understand C++”? If anything, I’d argue that while both are subjective claims, the former is less subjective, just because static typing is widely considered an advantage when it comes to large scale systems.

                  1. 1

                    How is “Go is easier to build large scale systems in than Python or Ruby” any more subjective than “Rust is easier to understand C++”?

                    It’s not. I should have also replied to the other post, too.

                  2. 6

                    To your meta comment, I am aping the “What Languages Fix” style of language property identification, which is necessarily subjective.

                    To the point itself, I think the notion that a language designed from first principles to support the practice of software engineering in large organizations is better at doing so than dynamically-typed, interpreted, prototyping languages like Python and Ruby is about as noncontroversial as subjective claims can be. And, for the record, reliably borne out by the vast majority of experience reports.

                    1. 4

                      And, for the record, reliably borne out by the vast majority of experience reports.

                      I’ve also seen experience reports suggesting that Ruby and/or Python are the most productive. Unless you can point to a broad study, from an unbiased researcher (spoiler: does not exist), it’s an opinion.

                      BTW, static vs dynamic typing is the most hilarious “it just is, duh” response ever. That’s the pinnacle of flame war arguments on this topic.

              2. 10

                A long time ago, Rust was actually much more similar to Go. Then the Rust developers decided that they didn’t need green threads and didn’t need a garbage collector because “a memory-safe programming language with no runtime!!!111*” is way cooler than “yet another Ocaml rehash, with this one weird type system trick!!!111”.

                That and they’re both released by web companies, so web developers have inevitably heard of both.

                * no additional runtime beyond what C requires, actually

                1. 12

                  They were completely right, a memory-safe programming language with no runtime is in fact way cooler than yet another Ocaml rehash. In the specific sense that such a language genuinely didn’t exist and huge amounts of systems software were written in memory-unsafe C and C++ for lack of a better alternative.

              1. 1

                It might be faster to implement a program twice rather than write comprehensive tests.

                1. 1

                  Twice and truly diverse? Im not sure about that, esp given generative testing.

                  The one counterpoint I can think of is when the diverse rewrite uses language or technique that inherently mitigates classes of problems in original. A component written in C side by side with equal in Ada with checks on wouldn’t have same kinds of failures. Alternately, the errors would be detected earlier with more precision thanks to the Ada version.

                1. -2

                  Pretension twaddle.

                  1. 3

                    How do you figure? Which part is pretentious?

                  1. 6

                    Looking for work, which is annoying and I’m glad I’ve only had to do it every couple of years.

                    In other news, my life is beset with minor-to-large annoyances:

                    • Truck A/C blower is busted, probably due to a burned-out wiring harness. Because no job, will be looking to replace that myself–involves replacing a resistor pack, clipping and grafting a new harness, soldering said harness (probably), heatshrinking the soldering, and then putting it all back together. Not fun.
                    • I nuked my blog server Because Reasons earlier this summer, need to stand it back up. Am torn between just getting it done vs. setting up responsible playbooks or something for it.
                    • My NAS kicked out some of its drives, and I’m pretty sure I just lost a bunch of stuff. I am very unhappy about this, but will need to do a whole bunch of remediation efforts to figure out what the fuck–and I’m probably still going to lose all that data. And yes, the NAS was my backup solution, thanks for pointing that out.
                    • My stove light is burned out.
                    • A backchannel I host needs some updates, including some email work, so I’ve gotta sort that out.
                    • My happy little music box a friend helped me set up no longer works (due to NAS autoimmolating), and I need to handle that bit of sysadminning as well. Folks, seriously, the more computers in your life the less happy you’ll be.

                    I’m really just tired and depressed from getting back from summer adventures, but these things pass–hopefully.

                    1. 1

                      What kind of work?

                      1. 1

                        Remote work, preferably full time. I do full stack web development, minor preference for Elixir on the backend, strong preference for simple stacks. If it’s interesting (especially if it’s graphics/VR!) I’m happy to do non-web stuff, though I think the iteration times and cost concerns are better with web tech.

                      2. 1

                        Hate that a bunch of stuff dropped on you at once. That seems to be going around at least in my locale and network. Good luck on it. Especially job and data loss. I can relate.

                        1. 2

                          Oh noes, recently quit a job, looking for a new one atm and now I need to check my backups and SMART values, it seems….

                          1. 1

                            What kind of work are you looking for?

                            1. 1

                              “now I need to check my backups “

                              I’ll be doing that later tonight or my next big window of time. Used some of this one to hit the gym hard with a new workout. Upgraded some numbers. Pretty exhausted. I’m gonna try a berry smoothie and some black tea to see if I get any energy back for doing the maintenance tonight.

                        1. 6

                          A month ago I switched to a remote job after working at a busy and social company for three years. There are many benefits in working remotely, but by far the most important drawback is that not having other people around for most of every working day is simply incredibly lonely.

                          “Go out more” as advertised in this article seems to miss this point. Meeting people out of work hours doesn’t solve the unnatural state during the default day. If you see a chimpanzee spend most of his days in an isolated part of the forest, something is probably wrong with it. I think the same holds for humans.

                          I would say that the only really healthy approach to remote work is to rent a space with a number of other remote workers (not necessarily from the same company) that you can get to know on a personal level. Which is what I’m lucky enough to be doing now.

                          1. 21

                            Comments like this always remind me of something I read a while ago. Someone said: “Introverts think extroverts are different. Extroverts think introverts are broken.”

                            Most people I met are like you, but some of us aren’t. And I’ve been working mostly remotely with short interludes for more than a decade without ever experiencing loneliness.

                            Totally agree with you that after work socializing is a poor substitute for those who need this social contact.

                            1. 6

                              I’m the same way. I’ve never been lonely, and I’ve worked remote for almost 4 years now. If anything, I probably know my coworkers better because there’s a bit more incentive to talk on slack since we are (mostly) all remote.

                              1. 4

                                I consider myself mostly an introvert. Still, being around people, even without interacting with them, almost seems like a necessity of life. I feel that especially for introverts, who are less likely to spontaneously catch up with people outside of work, the company of people during work is quite essential.

                                Perhaps it is just a matter of getting used to a new situation, but so far it strikes me as odd that in discussions about remote work, this issue is usually brushed off with “get out more often!”.

                                1. 6

                                  I feel similarly; I have always considered myself an introvert, and after 8 years of working in offices, I was really happy to accept a remote position.

                                  After two and a half years I started paying for a permanent desk in a coworking space in the city, because sitting in my home office in the suburbs all day was driving me crazy. I’d go out for a walk every day, usually have lunch out just to be out and about more, but it was still not enough. It’s been a year since I started working in the coworking space and every now and then I’ll have a reason to stay home (waiting for a package or getting something at home fixed), and it reminds me how lonely it is.

                                  (I’m glad not everyone has this experience! But I don’t think the divide is as clean cut as extrovert/introvert.)

                                  (edit: reading @technomancy’s comment below makes me realise the part where I’m working remotely across timezones — and indeed, in an “unpopular” timezone (UTC+10/11) — probably makes the biggest difference of all. I think it’d be much different if my team was in my timezone.)

                              2. 7

                                Why aren’t you interacting with your team? I’m on slack and have multiple video calls with teammates per day. It’s actually slightly better than being in the office, because the office creates the sense that if someone is not there (but working elsewhere) they’re inaccessible.

                                1. 3

                                  I take issue with the assumption that multiple video calls a day is an appropriate level of interaction for all remote teams. It may work if you’re all working collaboratively on a small set of projects, but that definitely isn’t a given, and without the need for that level of collaboration and communication, it’d be hard to justify interrupting the work of the rest of your team to satisfy your personal social requirements.

                                  1. 2

                                    Sometimes that’s not possible. I remoted from China for about three months when I was visiting my partner out there. The team was distributed in Europe and the Americas. The language barrier and the huge timezone difference were very isolating. Definitely started to go a bit crazy spending so much time alone, and I’m definitely on the more introverted side.

                                    Now we’re in MXCD and it’s significantly better. Loads of (10+) co-working spaces within walking distance, whereas Guangzhou only had 2-3, with about an hour commute each way, and people are awake/online, so lots more slack based interaction.

                                    We also have an apartment dog, which I would recommend to anyone if you’re animal inclined. It’s really nice having a doggy friend when working from the apt, and she provides a good incentive to take regular breaks instead of powering through the day.

                                    1. 9

                                      I remoted from China for about three months when I was visiting my partner out there. The team was distributed in Europe and the Americas.

                                      Working with a team across a time zone difference is usually done remotely, but it’s a vastly different thing from working remotely with people in the same or adjacent time zones that it’s misleading to draw conclusions about one from experience in the other.

                                      1. 2

                                        There are multiple additive factors. Radical timezone differences, difficulty communicating with locals, and being physically isolated (working from a home office) all significantly contribute to a feeling of general isolation. It’s not just about being physically separate from your team.

                                        The move from Guangzhou to Mexico City highlighted for me how each of those factors contributed to that feeling of loneliness, and how, as each one of them was addressed, remote work needn’t be so isolating.

                                        My experience mirrors @kivikakk, and @thev in that I’ve found co-working spaces can help significantly. They help not just with the feeling of physical isolation, but because they tend to attract people in a similar industry, and if you are overseas, because they tend to attract a higher percentage of expats who generally have similar in-country experiences, and who may speak your native language.

                                  2. 2

                                    Speak for yourself, pal. I work for a mostly-remote company, and we’re not all basement-dwelling losers, and as far as I know nobody’s secretly dying of loneliness. Back when I was commuting to a cube farm, I wasn’t there to hang out with friends, I was there to pay the rent.

                                    1. 1

                                      My friends started a company together and they’re not all in one place so they spend their time on a Discord call together, which I always thought was kind of clever.

                                      1. 1

                                        I love spending days at home alone. I feel much more peaceful and balanced. Be careful not to generalize from your own experience.

                                      1. 0

                                        I am disappointed in the Python Software Foundation for once again leaving PyPy out in the cold. It has been a pattern for over a decade that CPython’s developers shortsightedly ignore alternative Python implementations, and now they have taken the extraordinary step of forcefully deprecating the dialect of Python used by the PyPy team.

                                        I’ve reached out to the Python Software Foundation repeatedly through official and semi-official channels, but never gotten a good clarification on the matter. PSF’s continued endorsement of a pile of C over a pile of Python is hypocritical, and now their attempt to control an ecosystem that is beyond them is ignorant; this ridiculous situation should not ever have happened, but continues to happen because of poor communication.

                                        1. 24

                                          From the linked post

                                          […] in 2008, we announced that we would sunset Python 2 in 2015, and asked people to upgrade before then. Some did, but many did not. So, in 2014, we extended that sunset till 2020

                                          (my emphasis)

                                          So the PyPy team has had between 12 and 5 years to move to Python 3, depending on how seriously they took the deprecation message. Or am I missing some internal Python wrangling here?

                                          1. 2

                                            Yeah, there’s two things you’re missing. First, PyPy’s toolchain, RPython, requires a Python 2.7 interpreter in order to bootstrap. These days, PyPy is capable of providing that bootstrap interpreter itself. Rewriting RPython would require a massive engineering effort, and there is not funding for such a venture. The latest position of the PyPy/RPython team is in a 2016 blog post:

                                            PyPy’s own position is that PyPy will support Python 2.7 forever—the RPython language in which PyPy is written is a subset of 2.7, and we have no plan to upgrade that.

                                            Second, it is well-known community folklore that GvR doesn’t really like PyPy or Jython or any other alternative to the reference interpreter. He would like for Python to be unified under a single holistic banner, and alternative interpreters present a threat. I was able to recently get him to clarify his position on the GitHub issue for the linked post:

                                            An endorsement of PyPy as an alternative to porting to Python 3 will not be coming from the PSF – we wish PyPy the best of luck with their own Python 3 transition, but we don’t think they are a good alternative to dropping Python 2 support.

                                            They would like to exterminate Python 2, and by extension, snuff out any ecosystems which aren’t porting forward to the latest and greatest PEPs offered by the CPython 3.x branches.

                                            1. 10

                                              Sounds like you want a hard fork. Why not do that?

                                              1. 0

                                                Python 3 already was a hard fork of Python 2. The two languages are clearly distinct; they are mutually incompatible in syntax and semantics. Why must the Python 3 folks now destroy the last of Python 2?

                                                1. 5

                                                  They do not “destroy the last of Python 2”, they are just saying that they have no will in maintaining it any longer. Would you blame them?

                                                  1. 0

                                                    That’s quite the opposite of what’s actually happening; they are saying that they want alternative Python 2 implementations, which are still going strong and aren’t dying anytime soon, to also go away. I do blame them, yes.

                                                    1. 9

                                                      Speaking as someone who maintains Python packages, I understand their position.

                                                      If the message were “one of many Python 2 interpreters is going to be unmaintained, but that’s no big deal and you can still get a maintained one to keep running all your Python 2 code”, well, that would mean people coming to me, and other package maintainers, and asking to have third-party packages maintained with Python 2 compatibility for as long as there’s a supported interpreter.

                                                      And I have no interest in that. Some aspects of 2/3 compatibility are not that hard, sure, but others can be a bit complex. And I’d be permanently held back from using most new features of modern Python, because those features aren’t going to be backported into a supported Python 2 interpreter (as I understand it, PyPy would never have interest in this; their desire is for Python 2.7 to remain supported but feature-frozen).

                                                      If PyPy wants to internally maintain the interpreter they use to bootstrap, I don’t care one way or another. But if PyPy wants that to also turn into broad advertisement of a supported Python 2 interpreter for general use, I hope they’d consider the effect it will have on other people.

                                                      1. 1

                                                        Sure. As somebody who maintains Python 2 codebases, I have felt the constricting effects of more and more packages no longer offering Python 2 versions, forcing folks to commit to increasingly-outdated vendored code.

                                                        PyPy has broadly advertised a general-purpose Python interpreter for sixteen years. An example release announcement from last year advertises “almost a drop-in replacement for CPython”. It’s fun to watch the effect that this already existing system has on folks; this entire thread has been folks having effects because of PyPy. PyPy exists, and that disrupts the picture of the ecosystem painted by PSF.

                                                        1. 3

                                                          I’m aware of PyPy’s existence.

                                                          There are a few things here that your comments have equivocated, and that equivocation leads to difficulty.

                                                          1. The CPython interpreters, for various versions of the Python programming language
                                                          2. The end-user deliverable interpreters of the PyPy project, for various versions of the Python programming language
                                                          3. The interpreter used by the PyPy project to bootstrap RPython
                                                          4. The abstract concept of the Python programming language, as embodied in a prose specification

                                                          Items 1 and 4 are copyrighted by the Python Software Foundation, which also owns the trademark for the Python programming language. Items 2 and 3 are under the control of the holders of PyPy’s copyright (a long list of individuals and other entities).

                                                          PyPy could, if the project chose, sunset its end-user-deliverable Python 2 interpreter on 2020-01-01, refuse to accept bugs from end users who wish to continue running software that is compatible only with Python 2, and maintain a Python 2 interpreter solely for the purpose of bootstrapping RPython.

                                                          Or, PyPy can publicly maintain an interpreter for Python 2 past 2020-01-01, including accepting bug reports from end users who wish to continue running software that is compatible only with Python 2.

                                                          You seem to strongly prefer the latter option. The only way in which your stated list of enemies (Guido, the CPython core team, the PSF) could interfere with that is by asking that the interpreter not be named “Python” (since the PSF owns the trademark). But the interpreter is already not named “Python”, so that’s moot.

                                                          But by doing so, PyPy would introduce a maintenance burden, or at least pressure to take on a maintenance burden, for other projects which wish to drop Python 2 and make use of new features only available in Python 3, since PyPy’s continued offering and support of an end-user-deliverable Python 2 interpreter would extend the life of software that is only compatible with Python 2.

                                                          This is the point I was making above, as a way of reminding you that while you’re complaining about the impact of the CPython/PSF messaging on you, you’re neglecting the impact of your messaging on others.

                                                          Also, I do wonder whether PyPy is really prepared to take on the burden of maintaining a high-profile Python 2 interpreter over potentially very long time scales, given the resource constraints which already have prevented being able to move it to bootstrap from Python 3.


                                                          I have felt the constricting effects of more and more packages no longer offering Python 2 versions, forcing folks to commit to increasingly-outdated vendored code.

                                                          The alternative is to force the maintainers to continue supporting software they don’t want to support. For my own projects, I’m supporting Python 2 until 2020-01-01, and then I’m done and will enjoy getting to finally start using features of Python 3. While I have some sympathy for people who are still immovably on Python 2, I don’t feel any obligation, nearly 12 years after Python 3 was released, to continue maintaining things for them for free.

                                                      2. -5

                                                        They will wave their totalitarian hand over the open source and free software they have released with the right for anyone to do with as they please and say “magically, we will destroy your ability to yourself do as you please with this software we don’t want anymore” and then we will all weep our crocodile tears as open source python has been cancelled.

                                                        Rest in peace, Python

                                                        Idk when - 2019

                                                        We will never forget, we will never forgive

                                                    2. 3

                                                      Because they no longer wish to volunteer their time and effort keeping your software running for you.

                                                      Want to keep python 2 alive? Step up and do it.

                                                      1. 1

                                                        I already contribute to PyPy and am hoping to switch nixpkgs to PyPy instead of CPython as the default Python 2 interpreter.

                                                        Why must PSF “sunset” our community?

                                                        1. 5

                                                          Because they don’t want to release updates for you. You just have to do it yourself now, as you had before.

                                                  2. 16

                                                    What do you propose they do then? Extend Python 2 support forever and let Python 2 slow down Python 3 development for all time?

                                                    What do you suggest they do about the real problem that it’s confusing for new programmers and users, and annoying for experienced programmers and users, that there are two Python dialects? Should Python programmers just forever have to decide between limiting themselves to writing code compatible with both Python 2 and Python 3, or writing code which a lot of users can’t run?

                                                    I get the feeling that you think they should’ve just made backwards-compatible improvements to Python 2 rather than breaking it with a major release of the language, and maybe that would’ve been better, but that’s not what they did. Therefore, I’m curious about what you would want them to do given the current situation, not what they should have done a decade ago.

                                                    1. 1

                                                      What they should do now, given the current situation, is admit that PyPy is a reasonable implementation of Python 2, and admit that CPython’s demise does not doom the rest of the Python 2 ecosystem.

                                                      New Python programmers already must contend with the fact that the PSF publishes two manuals, one for Python 2 and one for Python 3, which look extremely similar, overlap greatly, and come up simultaneously in search results.

                                                    2. 7

                                                      “First, PyPy’s toolchain, RPython, requires a Python 2.7 interpreter in order to bootstrap.”

                                                      That’s them choosing and forever staying on a specific dependency. We generally don’t force suppliers to support anyone doing that unless they’re customers paying for backward compatibility. Even then suppliers might not find it worth their time and effort.

                                                      Let’s say we address the dependency. Is it really that difficult for Python programmers to rewrite one Python program in the newer version of Python? That versus the effort to maintain and polish Python itself for just that dependency?

                                                      Seems more fair for the project that wants the dependency to be the one reworking it. Also fairer division of labor given other option is an externality.

                                                      1. 1

                                                        “Supplier” is a bad term. The PyPy team is the RPython team, and they supply their own Python 2 implementation.

                                                        Is it really that difficult for Python programmers to rewrite one Python program in the newer version of Python?

                                                        Yes. Additionally, you clearly don’t know either dialect of Python, and you clearly have not done such a port. I encourage you to do so! You will learn a lot. You will mostly learn that Python 2 to Python 3 is not automatic, not trivial, and can take months at a minimum. For RPython, I would say that it is infeasible and not worth attempting unless somebody is paying.

                                                        1. 5

                                                          ““Supplier” is a bad term. The PyPy team is the RPython team, and they supply their own Python 2 implementation.”

                                                          Your original claim was about the Python Foundation, which you said backed CPython, was sunsetting support for Python 2 after telling everyone they’d do it for a long time. They were putting all their effort into Python 3. You then said this was a problem since another team, PyPy team, had a dependency on Python 2, had no intention to change that due to one component, did their own implementation of Python 2, and would stay on it.

                                                          That means this is an externality for PyPy, costing Python Foundation, where some other group is expected to support a language and its associated ecosystem just because of their dependency choices and porting preferences. I don’t see anything wrong with the other group saying, “No, we and our foundation have moved on in what we think are better directions. Anyone wanting to support the legacy tech can feel free. It’s on them since it’s not benefiting us.” Just going by what facts you’ve given here.

                                                          “you clearly don’t know either dialect of Python”

                                                          I used one here and there a long time ago. Don’t know either currently. I’ve been reading about Python 2 maybe getting ditched for Python 3 in these forums for a long time. So, I started asking some questions.

                                                          “You will mostly learn that Python 2 to Python 3 is not automatic, not trivial, and can take months at a minimum. “

                                                          Likewise, supporting an entire language, its libraries, security fixes, etc so some other people don’t have to port code is probably manual, less trivial than one component, and will drag on for years to decades. I’ve seen lots of companies port Python to Go. A Python to different kind of Python port of one component by Python experts is probably easier than maintaining a whole implementation of Python and its libraries. Just a guess.

                                                          If PSF is doing it for PSF, then by all means maybe they should maintain a whole platform. It’s different if it’s a lot of work, an externality for someone else, and they refuse to do a smaller set of work on their end. Again, just going by what you’ve described. If the facts are different, then this analysis would be wrong.

                                                          1. 0

                                                            You are equating the support from PSF of Python 2 with the existence of any Python 2 interpreter. If, tomorrow, all CPython 2.x installations stopped working, PyPy users would nonetheless still be able to execute pip or another pure-Python package manager and download Python 2 packages from PSF-operated infrastructure. This is an example of the sort of non-CPython-specific support for the entire Python community under PSF’s control.

                                                            The PyPy team can, and will, and must, support their entire toolchain, including RPython, PyPy, and a copy of the Python parts of CPython’s standard library.

                                                            Please ensure that your facts include the corporate employers of various CPython core developers, as well as GvR’s unyielding shadowy influence. Many folks simply wanted Python 2 to become Python 3, a fantasy paid for with developer-hours.

                                                            1. 4

                                                              “The PyPy team can, and will, and must, support their entire toolchain, including RPython, PyPy, and a copy of the Python parts of CPython’s standard library.”

                                                              That’s on them is my point. If they want PSF support, they need to give them a reason that works to their liking. If not, ignore them with a marketing strategy and/or foundation of their own that supports their goals. That’s how these things work.

                                                              “Please ensure that your facts include the corporate employers of various CPython core developers, as well as GvR’s unyielding shadowy influence.”

                                                              Sure. If corporations and GvR are in control, then CPython development needs to continue to reflect what they want out of pragmatism or expect lots of failure. Anyone not liking the decisions of those corporations and GvR should fork Python totally to support their vision with their own resources with no hate or aggravation toward the others acting in their own self interests. Maybe even out-compete them with their own language extensions and/or higher-performance implementations [1] on top of better marketing strategy and funding outreach. The kinds of things developers and organizers did for older versions of Python to get them where they were.

                                                              Edit: [1] Adding that Nim and Julia are sort of doing that already even though I meant an improved version of Python. Nim has Python-like syntax with extra features and higher-performance during runtime. Its getting some Python users. Python is entrenched in scientific computing. Julia is grabbing some of those people with alternative design, focus on higher performance, and focus on easier integration with C libraries while still keeping Python ones. They’re both getting users with Julia getting a lot of them.

                                                              1. 1

                                                                This isn’t about PSF support, although if we’re going to talk about PSF support, it’s notable that the total sum investment of the PSF in PyPy is $10,000. I can guess at the salaries of the typical CPython core developer, and they’re a little better than five figures. It was only a year or two ago that PSF even opened up their grant program to allowing PyPy, Jython, or other non-CPython-based projects to apply for grant money.

                                                                This is about the words at the top of the original post. To remind:

                                                                We are volunteers who make and take care of the Python programming language. We have decided that January 1, 2020, will be the day that we sunset Python 2.

                                                                These words purport to speak for PyPy’s team and any other Python 2 team. These words claim that Python 2 will be removed from our hands next year. Can you grok this? Do you understand why it might be a bit of a problem that the group that sits on the pile of money and trademarks has unilaterally decided that entire branches of the family tree must be pruned?

                                                                Not Nim, but indeed Julia, as well as my own Monte, Hy, Quill, Lever, and likely others, all came from the realization over half a decade ago that the PSF was disowning Python 2 and would only acknowledge Python 3 as the one true Python. If we’re not going to keep the name, why keep the semantics? We could improve.

                                                                1. 2

                                                                  These words purport to speak for PyPy’s team and any other Python 2 team

                                                                  The original post was published on python.org, which has an SSL cert published by the Python Software Foundation. It’s published by the PSF and speaks for them.

                                                                  You are making weird semantic shifts between “Python the language”, “Python the implementation”, and “Python the trademark” all over the place.

                                                                  It’s clear you (and maybe the rest of PyPy) have no love for Guido van Rossum, and maybe not the PSF. But the fact is that they own the trademark to Python. Trademarks exist in part to prevent customers from confusing one product for another. That way, no-one will be confused when the code they get from the PSF (Python 3) won’t run on PyPy (Python 2).

                                                                  That said, I’m sure no-one would object to say a product called “PyPy - a version of the Python language and runtime based on Python version 2.7”.

                                                                  From what I’ve read in this thread, it seems that PyPy wants to have their cake and eat it - they want full and continued support from the PSF for Python 2, while at the same time being entirely separate from them and not have to follow the PSF in any other matter. I really don’t see why the PSF has to go along with this arrangement.

                                                      2. 5

                                                        Second, it is well-known community folklore that GvR doesn’t really like PyPy or Jython or any other alternative to the reference interpreter. He would like for Python to be unified under a single holistic banner, and alternative interpreters present a threat. I was able to recently get him to clarify his position on the GitHub issue for the linked post:

                                                        This is a sticky wicket, and it’s by no means unique to Python. Witness the difficulty non standard Ruby, Perl etc. implementations have had keeping up with the reference implementation.

                                                        In the end, a most language communities end up, as Guido/Python did, deciding to focus on one implementation and say “This is THE reference implementation of the language”.

                                                        Doing anything else requires a massive outlay of man hours that just don’t exist in communities like Python - you’d need something like the Jave TCK.

                                                        1. 7

                                                          He would like for Python to be unified under a single holistic banner, and alternative interpreters present a threat. I was able to recently get him to clarify his position on the GitHub issue for the linked post:

                                                          This is not a fair reading of what Guido actually said in that issue. He is talking about PyPy being an alternative to Python 2, and being disappointed they’re not implementing Python 3. He didn’t mention anything about Python being “unified under a single holistic banner” or PyPy being a “threat”

                                                          1. 1

                                                            It’s totally understandable that you dislike my opinion. This is a synthetic opinion of GvR’s desires that comes not just from this post, but from years of interactions with him, including a particularly memorable dinner from a PyCon in Montreal a few years ago.

                                                            PyPy is not just an alternative to Python 2; there is a Python 3 branch. Indeed, the main PyPy page offers 2.7.13, 3.5.3, and 3.6.x versions of PyPy. I can’t imagine that his disappointment is that PyPy doesn’t have Python 3 support, but more likely that PyPy exists at all and mars the otherwise-singular transition between languages.

                                                            PyPy has never, to my knowledge, cracked 5% of all Python usage. The only measurements I’ve seen have come up at 1-2%. It has always been marginalized due to the desires of CPython core developers. We sometimes like to imagine a world where Python interpreters were fast, but this is apparently not that world.

                                                            1. 6

                                                              Can you cite conversations online where CPython core developers are displaying this sentiment?

                                                              For me, peak-PyPy and excitement around alternative implementations happened in the 2008-2012 window. What I mean by this, is that everyone was excited about alternative implementations driving performance forward at a time when folks weren’t so worried about Python 3 compatibility, and Python itself was just getting into a growth curve. I’d cite Dave Beazley’s PyCon Keynote at PyCon 2012 as an example of how PyPy wasn’t sidelined to the degree you argue it is.

                                                              Fast forward a few years and folks are in the trough of disillusionment, to steal a phrase from tech analysts. There were lots of (invalid, but) broken expectations in the community. Unladen Swallow, Jython, IronPython, and PyPy (to name just a few) hadn’t taken the world by storm and we were still trying to remove the GIL without breaking C extension compatibility. There were a lot of good intentions about getting and staying compatible with the Python mainstream - but this didn’t happen, and the alternative implementations got behind. PyPy’s history of Python 3 funding has some relevant detail.

                                                              It’s great that PyPy has caught up, but there is some way to go as far as being a strategic choice for folks. Even with CPython’s pretty obvious deficiencies it’s been able to carry a community forward to a place that’s very different from 2008. PyPy can make the argument that it’s a viable and supported Python 2 that could even get better, but very few people want this, even if they have to support Python 2. Python developers for the most part want to move to Python 3 because it’s finally a compelling option. In my mind, it’d be better if PyPy adapted to the current environment and attempted to overtake CPython as the platform of choice for Python 3 instead of fighting old battles for a diminishing platform.

                                                              1. 1

                                                                Sure, you’re part of one arm of the massive galaxy of Python. However, you should know that there is another arm, where:

                                                                • C extensions are shunned; speed comes from PyPy
                                                                • Conda? Ha, no, we use real package managers, like Nix
                                                                • asyncore? asyncio? No, we use Twisted

                                                                There is a clear difference between Unladen, Pyjion, Pyston, etc. vs PyPy: PyPy is a true community project, not a corporate timewaster. If that makes it less strategic, so be it; the clear difference is that PyPy ships, and has been shipping for years. In 2008, it was already shipping, already fast, and the PyPy position was that CPython folks should keep CPython as the reference interpreter, but encourage PyPy and Jython experimentation, deprecate the C API, and encourage platform-neutral portable Python. This position of ours is over a decade old.

                                                              2. 3

                                                                “Indeed, the main PyPy page offers 2.7.13, 3.5.3, and 3.6.x versions of PyPy.”

                                                                They’ve done a lot of work. They deserve more visibility. I’ve always mentioned them to people interested in Python implementations.

                                                                “PyPy has never, to my knowledge, cracked 5% of all Python usage. The only measurements I’ve seen have come up at 1-2%. It has always been marginalized due to the desires of CPython core developers.”

                                                                The desires of a project’s developers rarely determine what massive amounts of people in the real world do. Especially across many disciplines that we see Python in. That’s marketing, what default binaries are available in package managers, what people in charge prefer, what gets the most press, word of mouth pushing each person’s favored version, etc. These things drive language adoption on large scales.

                                                                The core Python team has a good brand and product they got bundled in most Linux distro’s by default with almost anything people read about Python pointing them in that direction. That’s why most use something like that vs PyPy. The PyPy team would have to step up big time on all the non-technical things that help achieve market success. Especially working with major distro’s to bundle them instead of reference Python. I don’t know what they’ve done on any of that since I just occasionally looked at the project being impressed at the technical work they put in.

                                                                1. 2

                                                                  I need to quote a PyPy developer. They contribute quite a bit of code, but crucially rely on funding, either from community awards or from paid consulting, to make their living. Their reaction upon reading GvR’s words earlier:

                                                                  it seems like they’re trying to actively hide the fact that there is and will be a supported python 2 version

                                                                  As for distro involvement, all of the big distros (Debian, Fedora, Gentoo, OpenSUSE) have a PyPy package of some sort. It’s second-class in many distros, because the core packages of the system are written specifically for CPython.

                                                                  Many many PyCon hallway discussions have been expended over this. I know that, as an outsider, it seems like this is a matter of marketing or some other intangible/bullshit matter of business, but inside the Python ecosystem, there has grown to be a vast divide between those of us focused on speed in Python and speed beside Python. We former have always been willing to accept being second-class to some extent, but here we are asked to abide a terrible distortion of reality where Python 2 and Python 3 are equivocated in order to fulfill the prophecy and consolidate power over both languages.

                                                                  1. 1

                                                                    I am enjoying your explanations, and lament your suffering, and if I had a clue, I might also have an opinion. But I just want to point out that I think when you grabbed the word “equivocated,” you were really reaching for “equated.” The way you have it reads as tho both the languages are being “made into mistakes.”

                                                                    1. 1

                                                                      If you meant it in the sense of “hide the truth,” then that should be something being done by people. “To equivocate” cannot take a direct object. CPython partisans may equivocate about Python versions, but the versions may not be equivocated by somebody (only truth in general can “be equivocated,” and to so state is tautological to the point of ungrammaticality) nor may they themselves equivocate (unless it’s anthropomorphism, which makes sense, e.g. Python 2 equivocates about strings being Unicode or bytes).

                                                            2. 2

                                                              Thanks for taking the time to reply. I can see from the language you’re using is that this is not just a technical matter, there are deep personal disagreements at play on both sides which makes this transition so hard.

                                                              I just have two followup questions related to the future of PyPy

                                                              1. would not the the new features of Python 3 make it easier to implement an alternative Python runtime to compete with CPython?
                                                              2. if not, it sounds as if the PyPy project is the perfect team to take over maintenance of Python 2, effectively forking the language and leaving a path forward for those to do not want to update to Python 3. The lack of funding would be alleviated by the support of those people or organizations who wish to continue to use Python 2.
                                                              1. 2

                                                                To your first question: No; see for yourself. Some features are neutral, some features are harmful. When it comes to RPython, the language is already restricted compared to Python 2, because the whole program is subject to type inference. Python 3 doesn’t offer any features which support type inference. (Annotations don’t help type inference more than actual code!) Some features, like ordered dictionaries by default, were first developed in PyPy and then copied by CPython later.

                                                                There is exactly one feature worth borrowing from Python 3, f-strings, but don’t bother. Python 3 gained them around the same time that ECMAScript gained template literals. Of course, in the original languages Scheme and E where the technique was pioneered, these templating strings can be used not just as builders of values, but also as patterns which destruct values. And in E, it is possible to customize how the value is built, by writing a custom builder. However, in Python 3, f-strings cannot be used as patterns, nor can custom builders be used. I asked somebody involved in drafting that PEP why the feature wasn’t lifted in toto, and they replied that nobody else in the room of CPython core developers had understood why it would be useful.

                                                                To your second bullet point, yes, there is a possible world where PyPy jumps from less than 5% usage this year to over 50% next year for Python 2. I don’t know whether that world is going to happen, because I believe that the PSF will put in effort to prevent Python 2 ecosystems from flourishing without their permission.

                                                          2. 3

                                                            But funnily enough I expect that we’re likely to see tools to analyze codebases for safety to port to PyPy for this reason; and one-and-done solutions for adapting c-based packages to work with PyPy.

                                                            That or blog posts from the interested parties explaining why that’s so infeasible that they’re finding CPython 2.7 security.

                                                            1. 1

                                                              PyPy is a compliant implementation of Python. There are documented differences from CPython, but in general, you should be able to write pure Python and have it work with PyPy.

                                                              The main barrier to PyPy adoption is the continued existence of CPython’s C API.

                                                              1. 3

                                                                More or less all scientific and data science users of python use libraries that depend on the CPython C API.

                                                                For them, PyPy is not a useful alternative.

                                                                Besides that, as they say in the announcement, many open source projects will stop supporting python 2. They’ll do that because it is work to support python 2 and they prefer to use or be compatible with 3.

                                                                PyPy has reasonable support for python 3 and the py2.7 required for bootstrapping can be maintained or replaced - it’s not like it needs any bug or security fixes for this purpose.

                                                                1. 1

                                                                  Right. Which is why you’d want to analyse your codebase for both use of c-based libraries and the weird dumb things you would do hit those documented differences.

                                                            1. 1

                                                              This was extremely educational. I do however take issue with this:

                                                              but random access by scalar value is in the YAGNI department

                                                              Whenever I slice a string, I’m making use of scalar values. It’s really not that unusual to have a fixed width of characters at the start of a string.

                                                              1. 10

                                                                Slicing doesn’t require random access. It can be done by saving an iteration point.

                                                                Rust strings have random access only by byte offsets, but at the same time only allow UTF-8-correct slicing. You iterate over valid codepoint offsets given in bytes, and then use these offsets for correct sub-slicing.

                                                              1. 8

                                                                I would enjoy being able to filter this tag. I support addition.

                                                                1. 6

                                                                  I find it very odd to see “Python3 and Perl6” in one sentence. Python3 has succeeded despite the mismanaged transition—but it’s also far less of a dramatic change than Perl6. Not sure about Scala 3, I haven’t looked.

                                                                  1. 4

                                                                    Python 3 is doing quite well, but the other shoe - of actually ceasing to support python 2 - has not yet dropped. We’ll see what happens then.

                                                                    1. 3

                                                                      Legacy systems are the norm. The new one runs in parallel instead of replacing the old one given its many users and investment. That both are doing well is probably a good thing in light of this.

                                                                      1. 4

                                                                        Sure. Which is why python 2 ceasing to receive even security patches is going to prompt some responses.

                                                                        We’re either going to see pushes to migrate (what guido and the python dev gang expect) or some efforts to continue running those python2 codebases with security patches (maybe a switch to pypy and continued community support of that project). The latter has the potential to reshape the politics of the python community.

                                                                        1. 3

                                                                          “dev gang” sounds weird? Is that really a term that is used in the python community?

                                                                          The Ruby community has found solutions to that. There’s specialised agencies keeping old codebases secure for old Rails and Ruby versions against reasonable fees. It’s infeasible for community maintainers to support legacy.

                                                                          On the other hand, as rough as it was, the MRI team has also made sure that there’s feasible migration paths, so that you can make a reasonable decision whether to put money/effort into migration or paid maintenance.

                                                                          1. 1

                                                                            I see “python-dev” used pretty frequently in the Python community to refer to the language developers (as distinct from library developers or the wider community) — it’s a reference to this mailing list.

                                                                          2. 2

                                                                            The question is really about who’ll be providing the support. There is no question in my mind that there will be Python 2 updates following the drop dead date for support. The question is whether the Python core team will decide to push the updates, have support forked by another community, or whether vendors (ActiveState, RedHat, etc.) will be the ones driving the support. The thinking seems to be that it’ll be the latter since open source projects have much less reason to get stuck than companies. That said, I’m sure the Python core team would consider pushing an update for some critical (security) issue, if it was decided in the best interests of the community and industry. I doubt that scenario will arise though, but it’s a possibility for a well run and organized community to consider.

                                                                            Where does your understanding of Guido’s expectations come from? I’ve been present at all PyCons since 2008, except two in recent years. I’ve never seen explicit expectations like the ones you describe from Guido, or others in leadership positions. They have been pretty pragmatic with their understanding of how any Python 2 to 3 migration will happen with an understanding that eventually it’ll make sense to sunset Python 2. The wider Python and online communities however have understood or listened to little of what has been said. That extends to async, and many other developments in the language/runtime over the past decade.

                                                                    1. 20

                                                                      Sad :-( I still think Mercurial far better meets the needs of most people, and that the chief reasons for git’s popularity are that Linus Torvalds wrote it, GitHub, and that Linus Torvalds wrote it.

                                                                      That said, I did end up switching from BitBucket/mercurial to GitHub/git a few years ago, simply because it’s the more pragmatical thing to do and I was tired of paying the “mercurial penalty” in missed patches and the like. I wrote a thing about it a few ago: https://arp242.net/git-hg.html

                                                                      1. 6

                                                                        Why do you think hg is better for most people? I honestly find it vastly more complex to use.

                                                                        1. 15

                                                                          The hg cli is light years ahead of git in terms of intuitiveness.

                                                                          1. 6

                                                                            I’d say it’s years behind ;)

                                                                            1. 10

                                                                              How long have you been using Mercurial? I find most people who dislike Mercurial’s UI, are mainly coming from years of experience with Git. I disliked Mercurial at first as well, but after a few years of forced usage it clicked. Now I appreciate how simple and well composed it is and get frustrated whenever I need to look up some arcane Git flag on StackOverflow.

                                                                              In general, I’d say you need several years experience with both Git and Mercurial before you can draw a fair comparison.

                                                                              1. 3

                                                                                I used mercurial for about 2 years before using git.

                                                                                1. 3

                                                                                  Sorry if my post came across a bit accusatory (not my intent). In that case I guess to each their own :).

                                                                                2. 3

                                                                                  but after a few years of forced usage it clicked.

                                                                                  I’m pretty sure that git clicked for me in a much shorter timeframe.

                                                                                  1. 1

                                                                                    Me too, but I know many (otherwise perfectly competent engineers) 5-10 years in who still don’t get it and aren’t likely to.

                                                                                3. 9

                                                                                  I’m going to strongly disagree. I’ve used git intensively and I find Mercurial to be a well-designed delight. I’ve run across features that Mercurial supports flawlessly, with a nice UI, and Git requires a hacky filter-branch that takes hours to run and doesn’t even behave correctly.

                                                                                  IMO, a lot of the badness in projects is down to Git badness. it doesn’t scale and people feel compelled to break things down into tiny sub-projects.

                                                                                  The only reason Git is winning anything is GitHub’s support of it.

                                                                                  1. 3

                                                                                    The only reason Git is winning anything is GitHub’s support of it.

                                                                                    Why then was github ever used in the first place? Kind of a strange proposition.

                                                                                    1. 1

                                                                                      Network effect of the social network is pretty important.

                                                                                      1. 1

                                                                                        Why would there ever be a network effect in the first place if git was so bad that github was the only reason to use it. I get that the argument technically holds but it seems very unlikely.

                                                                              2. 8

                                                                                You find mercurial more complex to use than git? That’s an… unusual view, to say the least. The usual recitation of benefits goes something like this

                                                                                • Orthogonal functionality in hg mostly has orthogonal commands (compare git commit, which does a half-dozen essentially unrelated different things).
                                                                                • hg has a somewhat more uniform CLI (compare git branch -a, git remote -v, git stash list).
                                                                                • hg either lacks or hides a bunch of purportedly-inessential and potentially confusing git functionality (off the top of my head, partial commits aren’t baked into the flow a la git’s index/staging area; and rebasing and history rewriting are hidden behind an extension).

                                                                                I personally prefer git, but not because I think it’s easier or simpler; I’m more familiar with it, and I find many of those purportedly-inessential functions to be merely purportedly, not actually, inessential.

                                                                                1. 5

                                                                                  One more thing I like about mercurial that the default set of commands is enough for >90% of people, and that everything else is “hidden” in extensions. This is a very different approach than git’s “kitchen-sink” approach, which gives people 170 commands (vs. Mercurial’s 50, most of which also have much fewer options/switches than git).

                                                                                  Git very much feels like “bloatware” compared to Mercurial.

                                                                                  1. 3

                                                                                    I used git for many years, and then mercurial (at FB) ever since we switched over. The cli interface for mercurial is definitely more sensible, crecord is delightful, and overall it was fine. But I was never able to build a mental model of how mercurial actually worked. git has a terrible interface, but it’s actually really simple underneath.

                                                                                    1. 1

                                                                                      I didn’t think that underneath they were different enough to matter much. What differences do you mean? I guess there’s git’s remote tracking stuff. Generally, it seems like they differ in how to refer to and track commits and topological branches, locally and remotely. (IMHO, neither has great mechanisms for all the things I want to do.) Mercurial is slightly more complex with the manifest, git is more complex with the staging area that feels absolutely critical until you don’t have it (by using hg), at which time you wonder why anyone bothers with it. I’m a heavier hg user than git user, but that’s about all I can come up with.

                                                                                    2. 2

                                                                                      You find mercurial more complex to use than git?

                                                                                      I actually found – in a professional shop – mercurial far more complex to use. Now, the fact is that mercurials core – vanilla hg is IMHO absolutely without doubt vastly superior to git. Git keeps trying to make the porcelain less painful (including a release just a bit ago) – but I still think it is ages behind.

                                                                                      The problem is – I never used vanilla mercurial in a professional environment. Not once. It was always mercurial++ (we used $X extension and $Y extension and do it like $Z) which meant even if I knew hg, I felt painfully inexperienced because I didn’t know mq, share, attic, collapse, evolve, and more… not to mention both the bigger shops I worked with using mercurial has completely custom workflow extensions. I suspect part of this was just the ease of writing mercurial extensions, and part of it was wanting to fall into a flow they knew (mq, collapse). But, regardless of how we got there, at each place I effectively felt like I had to relearn how to use the version control system entirely.

                                                                                      As opposed to git, wherein I can just drop in and work from day one. It might be less clean, it might be more finicky and enable things like history rewriting by default. But at the end of the day, the day I start, I know how to generally function.

                                                                                      I am curious how Mercurial would have faired if instead of shipping default extensions you had to turn on – if they had just baked a little more functionality, to try to cover the 80% of what most shops wanted (not needed, I think most could have gotten by with what vanilla mercurial had) – if the shop to shop transition would have been easier.

                                                                                      1. 2

                                                                                        mq, I think, is responsible for many of the “mercurial is too complicated” complaints people have. Evolve, if it ever stabilized and ships with core hg would really enable some killer capabilities. Sadly for social and technical reasons it’s perpetually in beta.

                                                                                      2. 1

                                                                                        whoa, no index? Admittedly I didnt really use index as intended for several years, but now its an important part of my workflow.

                                                                                        1. 1

                                                                                          In Mercurial, commits are so much easier to make and manipulate (split, fold, move), that you don’t miss the index. The index in git is just a limited special cased “commit”.

                                                                                          1. 3

                                                                                            The index in git is just a limited special cased “commit”.

                                                                                            I disagree.

                                                                                            The index is a useful way to say “these lines of code are ready to go”. If you are making a big commit, it can be helpful to add changes in logical blocks to the index as you go. Then the diff is not polluted with stuff you know is already fine to commit.

                                                                                            You might say, “why not just make those changes their own commits, instead of trying to do one big commit?” That’s a valid question if you are talking about a 200 line commit or similar, but sometimes the “big” commit is only 50 lines. Instead of making a bunch of one line or few line commits, its helpful to “git add” small chunks, then commit at the end.

                                                                                            1. 0

                                                                                              You can as well amend to a commit instead of adding to the index.

                                                                                              1. 3

                                                                                                True, but all thats doing is bastardizing the commit process. If you are committing a one line change, just to rebase minutes or hours later, thats not a commit.

                                                                                                Rebase to me is for commits that were intended to be commits, but later I decided it would be better to squash or change the history. The index is for changes that are never meant to be a full commit on their own.

                                                                                                1. 1

                                                                                                  Having a distinction between draft and published phases in mercurial I think makes it easier to rewrite WIP work. There’s also a number of UI affordances for it. I don’t miss the index using mercurial. There’s also academic user interface research that shows the index is a big conceptual barrier for new users.

                                                                                                  1. 1

                                                                                                    There’s also academic user interface research that shows the index is a big conceptual barrier for new users.

                                                                                                    this isnt really a valid point in my opinion. some concepts are just difficult. if some goal can be achieved in a simpler way i am on board, but I am not a fan of removing useful features because they are hard to understand.

                                                                                                    1. 1

                                                                                                      But the point is the index is hard to understand and unnecessary.

                                                                                                      There’s no need to have a “commit process”. Just commit whatever you want and rewrite/amend it for as long as you want. As long as your commits are drafts, this is fine.

                                                                                                      Is the problem the word “commit”? Does it sound too much like commitment?

                                                                                                      There’s no need to have two separate ways to record changes, an index, and a commit, each with different degrees of commitments. This is multiplying entities beyond necessity.

                                                                                                      1. 1

                                                                                                        That’s your opinion. The index is quite useful to me. I’d rather make a proper commit once it’s ready, not hack together a bunch of one line commits after the fact.

                                                                                                        1. 2

                                                                                                          The index is a commit. Why have two separate ways of storing the same sort of thing?

                                                                                                          Also, it’s not my opinion that it’s hard to understand and unnecessary; it’s the result of usability studies:


                                                                                                          You’re also not “hacking together” anything after the fact. There’s no more hacking together after the fact whether you use git amend (hypothetically) or git add. Both of those mean, “record additional changes”.

                                                                                                          1. 0

                                                                                                            It seems you have a fundamental misunderstanding of the difference between add and commit. Commit requires a commit message.

                                                                                                            1. 1

                                                                                                              This isn’t a useful distinction. You can also create commits with empty commit messages in both git and Mercurial.

                                                                                                              With both git and Mercurial you can also amend commit messages after the fact. The index in git could well be implemented as a commit with an empty commit message that you keep amending and you wouldn’t notice the difference at all.

                                                                                                              1. 1

                                                                                                                you keep amending and you wouldn’t notice the difference at all.

                                                                                                                yeah, you would. again it seems that you either dont know git, or havent used it in some time. when you amend a commit, you are prompted to amend the message as well. another facet that doesnt exist with git add, because add doesnt involve a message.

                                                                                                                if you wish to contort git internals to suit your agenda thats fine, but git add has perfectly valid use cases.

                                                                                                                1. 0

                                                                                                                  you are prompted to amend the message as well.

                                                                                                                  This is UI clutter unrelated to the underlying concepts. You can get around that with wrappers and aliases. I spoke of a hypothetical git amend above that could be an alias that avoids prompting for a commit message.

                                                                                                                  Don’t git users like to say how the UI is incidental? That once you understand the data structures, everything else is easy? The UI seems to have locked you into believing the index is a fundamentally necessary concept, but it’s not. It’s an artifact of the UI.

                                                                                                                  1. 1

                                                                                                                    The UI seems to have locked you into believing the index is a fundamentally necessary concept, but it’s not.

                                                                                                                    Nothing has locked me into believing its a necessary concept. Its not necessary. In fact, for about 7 years I didnt use the index in any meaningful way.

                                                                                                                    I think what you are missing is that Im not compelled to use it because its the default workflow, I am compelled to use it because its useful. It helps me accomplish work more smoothly than I did previously, when I would just make a bunch of tiny commits because I didnt understand the point of the index, as you still dont.

                                                                                                                    The argument could be made to move the index into an option, like somehow make commit only the default workflow. Im not sure what that would look like with Git, but I dont think its a good idea. It would just encourage people to make a bunch of smaller commits with meaningless commit messages.

                                                                                                              2. 1

                                                                                                                You have a set of things you want to accomplish. With git, you have N+1 concepts/features/tools to work with. With hg, you have N (because you drop the index). That means you have to expand your usage of the remaining N.

                                                                                                                Specifically, since you no longer have this extra index concept, you now expand commits to cover the scenarios you need. Normally, you’d make an initial commit and then amend a piece at a time (probably with the interactive curses hunk selector, which is awesome.) If you’re unsure about some pieces, or you have multiple things going on that you’d like to end up in separate commits, you can always make a series of microcommits and then selectively collapse them later. (In practice, it’s even easier than this, because of the absorb extension. But never mind that.)

                                                                                                                Yes, those microcommits need commit messages. They don’t need to be good ones, because they’re temporary until you squash them out of existence. I usually use a one word tag to specify which of the separate final commits they belong to. (If you don’t have separate final commits, you may as well amend, in which case no messages are needed.)

                                                                                                                …or on the other hand, maybe mercurial ends up with N+1 concepts too, because phases really help in keeping things separate. As I understand it, one reason git users love the index is because it keeps rapidly changing, work in progress stuff separate from mostly set in stone commits. Phases perform the same purpose, but more flexibly, and the concepts are more orthogonal so they compose better. In my opinion.

                                                                                      3. 6

                                                                                        I never particularly liked git and find it unintuitive, too.

                                                                                        I wouldn’t consider myself a git poweruser. But whenever I had to work with alternatives I got the feeling that they’re just inferior versions of git. Yeah, maybe the usage was a bit more intuitive, but all of them seemed to lack things that I’d consider really basic (bisecting - hg has that, but e.g. svn has not - and shallow copying - not avaible in hg - are examples what I often miss).

                                                                                        1. 3

                                                                                          Mercurial was actually my first DVCS, and like you I ended up switching to git not out of a sense that it was technically better, just more pragmatic. For me, the change is more of a mixed bag, though. It is definitely the case that Mercurial’s UI is worlds better, and revsets in particular are an amazing feature that I sorely miss, but when I made the switch I found that the way git handles branches was much more intuitive to me than Mercurial’s branch/bookmark system, and that the affordances around selectively editing commit histories were very much worth the risk in terms of being able to manage the narrative of a project’s history in a way that makes it more legible to others. Ultimately, I found that git’s advantages outweighed its downsides for my use case, since learning its UI idiosyncrasies was a one-time cost and since managing branches is a much more common occurrence for me than using revsets. That said, I think this is a really unfortunate development.

                                                                                          1. 2

                                                                                            I occasionally convert people’s git repos to hg for my use. Stubborn like that.

                                                                                          1. 3

                                                                                            Those salaries are not high when compared with the amount of wealth generated by software engineers, frequently working long hours and with little holiday. Other people get rich and the software engineers take home a fairly decent salary.

                                                                                            The real question is why are software engineers in other countries paid so much worse? My suspicion is that software is used less effectively, or perhaps that really effective revenue generating businesses are less common, creating less competition for software engineers.

                                                                                            1. 2

                                                                                              Reminds me of: https://thedailywtf.com/articles/The_Complicator_0x27_s_Gloves

                                                                                              You can get a radio-based baby monitor for $20. You can get temperature-triggered fans or aircon units.

                                                                                              The use of blankets as shown in the crib means that ambient temperature does not reflect the temperature inside the bed.

                                                                                              Finally the photos in the blog post show a baby surrounded by blankets. Please don’t leave a baby unattended like that. See: https://www.healthychildren.org/English/ages-stages/baby/sleep/Pages/Preventing-SIDS.aspx

                                                                                              1. 1

                                                                                                This seems to confuse “borrow checking” with type checking. The file example is not the same as the HTTP example. The actual type-based pattern should be possible in any language with parametric types and static type checking.

                                                                                                The use of borrow for state checking is more unusual and requires that to be baked into the compiler.

                                                                                                1. 3

                                                                                                  True, the file example is using borrow checking rather than types. I think later they’re making the case that the borrow checker can enforce the typestate pattern in the case of typestate transitions causing side-effects. This would be difficult to do in a language without proper move semantics to invalidate the previous state.

                                                                                                1. 4

                                                                                                  The law on this is in flux, and varies throughout the US (federal law is not the same across the US - learn about federal circuits if this surprises you).

                                                                                                  I would love to see this theory tested. I would not want to be the one out there testing it.

                                                                                                  Donate to the ACLU.

                                                                                                  1. 2

                                                                                                    I think Pony a bit more cumbersome to use than many other languages, at least for a simple “Hello, World!” example in SDL2, but it feels surprisingly solid. https://github.com/xyproto/sdl2-examples/blob/master/pony/main.pony

                                                                                                    1. 4

                                                                                                      I will say, this is pony program that uses SDL by directly linking against external c functions! Most SDL hello world examples you’ll see in other languages use a library wrapping the external calls. I think it speaks volumes that in fact the Pony source is both readable and short, especially considering that Pony is a managed language, with support for actors. (In comparison, the C FFI in both Go and Erlang tends to be much harder)

                                                                                                      1. 1

                                                                                                        It uses SDL2 directly only because no SDL2 library were available for Pony at the time (I’m not sure if there is one available now).

                                                                                                      2. 3

                                                                                                        I just did some exercises in Pony and Rust and I definitely found Pony the more elegant and easy language; but with much worse library support

                                                                                                        1. 4

                                                                                                          We definitely have a considerably smaller community than Rust at this point. In part, I think that is:

                                                                                                          1- Rust has corporate backing and people paid to work on it 2- It’s post 1.0 and most people won’t consider using pre-1.0 stuff

                                                                                                          More people contributing to the Pony ecosystem (including libraries) is something we could really use and would happily support as best we can. We’ve had a lot of excited people start to pitch in. Most haven’t contributed to open source projects before and I think for many, the shine rather quickly rubs off. I don’t blame them, maintaining open source software is… well, it’s an “interesting hobby”.

                                                                                                          1. 1

                                                                                                            Absolutely agree. Even contributing to a few projects, I can see that I wouldn’t want to be a maintainer without being paid or “it” being my big idea.

                                                                                                            I don’t do much system level programming, so I don’t need either, really, so I’m very unlikely to step up.

                                                                                                            A bridge to rust might help though?

                                                                                                            1. 5

                                                                                                              A bridge to rust might help though?

                                                                                                              Pony can directly call into C (and therefore into Rust) and generate C headers, which Rust can consume to generate interfaces. The biggest problem for “just” using both from both sides is language semantics outside of the function call interface that the C ABI provides. Also, Rusts ABI is currently private.

                                                                                                              I don’t do much system level programming, so I don’t need either, really, so I’m very unlikely to step up.

                                                                                                              Both Rust and Pony provide safety guarantees and features way past “safe systems programming” and Rust is definitely used as a “wicked fast Python” in some circles. It’s an interesting space to work in, currently :).

                                                                                                        2. 2

                                                                                                          I really like the syntax, and the underlying ideas. I recently speed read through the tutorial, and the most daunting aspect of it (for me) was the reference capabilities part. I hope I can find a side project to play with it some more.

                                                                                                          Plus the language is named pony, which makes it instantly great. ;)

                                                                                                        1. 1

                                                                                                          Oh, its for developers. Still weird to be up here in Canada and see Americans call themselves software engineers almost willy-nilly.

                                                                                                          Edit, a lot of this is pretty common basic stuff but I can see its worth. I’ve heard a lot of people moan about meetings but it seems like my company just implicitly follows these guidelines? Hope this helps some one!

                                                                                                          1. 1

                                                                                                            Oh, its for developers. Still weird to be up here in Canada and see Americans call themselves software engineers almost willy-nilly.

                                                                                                            Does ‘software engineer’ have a different meaning in Canada vs. the US?

                                                                                                            1. 2

                                                                                                              I’m an American (former) computer programmer who lives in Canada, and it feels like Canadians are much more likely than Americans to take “software engineering” to mean “an accredited, professional engineer”, and so would be less likely to use the term in the looser, “computer programmer” American sense.

                                                                                                              1. 2

                                                                                                                I see. Totally reminds me of this story from a while back: https://www.washingtonpost.com/news/morning-mix/wp/2017/12/08/criticizing-red-light-cameras-is-not-a-punishable-offense-oregon-concedes

                                                                                                                Yea in the US, ‘engineer’ is definitely thrown around more losely, I didn’t realize other countries formalized the term more.

                                                                                                                1. 2

                                                                                                                  In Sweden, the term “civilingenjör” is a protected term reserved for those with a Masters from an institute of higher learning with a focus on technology and engineering. There are half a dozen of these in Sweden.

                                                                                                                  Note that the term is a false friend to the term “civil engineer”, which is a subset of the above. A “civilingenjör datateknik” is a Masters in Computer Science, a “civilingenjör väg och vatten” is a Masters in Civil Engineering.

                                                                                                                  However that there are no legal requirements that, for example the project lead on a major infrastructure project has to be a civilingenjör. It’s a bit like a military medal in that you have to do a certain thing to be able to call yourself that.

                                                                                                                  1. 1

                                                                                                                    reserved for those with a Masters from an institute of higher learning with a focus on technology and engineering.

                                                                                                                    Can that institution be abroad? Or at least abroad in the EU?

                                                                                                                    1. 2

                                                                                                                      That’s a really good question! I’ll have to do some research.

                                                                                                                      1. 2

                                                                                                                        I can’t edit my other response, so here’s a new one.

                                                                                                                        Based solely on the Swedish Wikipedia page https://sv.wikipedia.org/wiki/Civilingenj%C3%B6r, it’s not possible. A foreign Master of Science in Engineering should be able to be accredited in Sweden though.

                                                                                                                        Note that “engineer” is not on the list of regulated professions in Sweden: https://www.uhr.se/en/start/recognition-of-foreign-qualifications/before-you-apply/i-want-to-work-in-sweden/regulated-professions/

                                                                                                                  2. 1

                                                                                                                    Doesn’t “software engineer” have a legal meaning in Canada, pertaining to formal education?

                                                                                                                    1. 2

                                                                                                                      Certainly, “engineer” does. I am not entirely sure about “software engineer”, but I would in fact expect so.

                                                                                                                      1. 1

                                                                                                                        I mean, there’s this, so .. ?

                                                                                                                        1. 1

                                                                                                                          Oh, that’s lovely!

                                                                                                                          You’re allowed to buy a “civilingenjörsring” in Sweden (see my other post in this thread) but there’s no ceremony involved, just proving you graduated.

                                                                                                                          The ring is usually 2-tone, (mine is yellow gold with a band of white gold), but the ring for mining engineers is gold with an inner band of soft iron: https://examensring.com/product/kth-civilingenjor-2/

                                                                                                                1. 1

                                                                                                                  Of course if you spoof the WiFi layer you can inject these redirects without even injecting any js first

                                                                                                                  1. 1

                                                                                                                    The big question: why not port something else like pony or cloud haskell? Or why not add static types to something like erlang itself?

                                                                                                                    1. 14

                                                                                                                      I’m not sure what you mean about Pony or Cloud Haskell but I have some answers to why not Erlang.

                                                                                                                      Static typing Erlang is a different and considerably more difficult problem than making a compatible soundly typed language. Realistically for a typer for Erlang to get adoption it needs to be flexible enough to allow it to be applied incrementally to existing Erlang codebases, which means gradual typing. Gradual typing offers a very different set of guarantees to those that Gleam offer. By default it’s unsafe, which isn’t what I wanted.

                                                                                                                      There’s also some more human issues such as my not being part of Ericsson, so I would have little to no ability to make use or adapt the existing compile, I would have to attempt to be compatible with their compiler. If we were successful in that the add-on nature means it becomes more of a battle to get it adopted in Erlang projects, something that I would say the officially supported Dialyzer has struggled to do.

                                                                                                                      Overall I don’t believe it would be an achievable goal for me to add static types to Erlang, but making a new language is very achievable. It also gives us an opportunity to do things differently from Erlang- I love Erlang, but it certainly has some bits that I like less.

                                                                                                                      1. 10

                                                                                                                        I’m not sure what the point of Pony on BEAM would be. Pony’s reference capabilities statically prove that “unsafe things” are safe to do. BEAM wouldn’t allow you to take advantage of that. Simplest example: message passing would result in data copying. This doesn’t happen in the Pony runtime. You’d be better of using one of the languages that runs on BEAM including ones with static typing.

                                                                                                                        1. 4

                                                                                                                          Thanks for Pony and thanks for the reply!

                                                                                                                          As you might imagine I’m very interested in how Pony types actors. I skimmed the documentation but many aspects such as any supervision trees were unclear to me (likely my fault). Are there any materials on the structuring Pony applications you could recommend? Thank you :)

                                                                                                                          1. 5

                                                                                                                            There are no supervision trees at this time in Pony. How you would go about doing that is an interesting open question.

                                                                                                                            Because Pony is statically typed and you can’t have null references, the way you send a message to an actor is by holding a “tag” reference to that actor and calling behaviors on it. This has several advantages but, if you were try to do Erlang style “let it crash”, you run into difficulties.

                                                                                                                            What does it mean to “let it crash”? You can’t invalidate the references that actors hold to this actor. You could perhaps “reset” the actors in some fashion but there’s nothing built into the Pony distribution to do that, nor are the mechanics something anyone has solid ideas about.

                                                                                                                            There aren’t a lot of materials on structuring Pony applications I can recommend at this time. I’d suggest stopping by our Zulip and starting up a conversation in the beginner help stream: https://ponylang.zulipchat.com/#narrow/stream/189985-beginner-help

                                                                                                                            1. 2

                                                                                                                              Thank you

                                                                                                                      1. 3

                                                                                                                        Or just use the two libraries boost provides for the purpose https://www.boost.org/doc/libs/?view=category_state

                                                                                                                        1. 1

                                                                                                                          Why not use email as the transport layer. Already supported in git.

                                                                                                                          See https://lobste.rs/s/gyygl3/advantages_email_driven_git_workflow

                                                                                                                          1. 3

                                                                                                                            It has been considered piggybacking on email for the distribution of patches at least. It falls short when it comes to questions of code hosting, public visibility and generally encoding primitives of code collaboration (open/close state of issues, same for patches/pr). Where it could be leveraged in the future is for notifications of updates to projects one follows.