1. 0

    I’m very happy with vgo after spending years frustrated with buggy, partially-broken third party tools: first glide (no way to upgrade just one package, randomly fails operations) then dep (100+ comment issue on not supporting private repos).

    This comment from HN sums up my feelings on this post:

    Go does not exist to raise the profiles of Sam Boyer and Peter Bourgon. Sam wanted to be a Big Man On Campus in the Go community and had to learn the hard way what the D in BDFL means. The state of dep is the same as it was before - an optional tool you might use or might not.

    Lots of mentions in Peter’s post about things the “dep committee” may or may not have agreed with. Isn’t this the same appeal to authority he is throwing at Russ? When did the “dep committee” become the gatekeepers of Go dependency discussions and solutions? Looks like a self-elected shadow government, except it didn’t have a “commit bit”. Someone should have burst their balloon earlier, that is the only fault here. Russ, you are at fault for leading these people on.

    Go is better off with Russ’s module work and I personally don’t care if Sam and Peter are disgruntled.

    1. 14

      This is an extremely bad faith interpretation of events. Your words have an actual negative effect on people who have tried for a very long time to do the best they could to improve a bad situation.

      1. 9

        had to learn the hard way what the D in BDFL means

        Except Go is not (or at least doesn’t market itself as) BDFL-led. The core team has been talking about building and empowering the community for years (at least since Gophercon 2015, with Russ’ talk).

        When did the “dep committee” become the gatekeepers of Go dependency discussions and solutions?

        They were put in place by / with the blessing of the Go core team, so some authority on the subject was certainly implied.

        Go is better off with Russ’s module work

        You can certainly prefer Russ’s technical solution, that’s only part of the thing being discussed (and I think it’s fair to say it’s not the heart of the matter).

        The rest of your quotes are just mean.

        1. -4

          People don’t seem to realize that Go is not driven by the community, it’s driven by Google. It’s clear to me that Google doesn’t trust its programmers to use any advanced features, the code is formatted the same (again, don’t trust the programmer), everything is kept in one single repo and there is no versioning [1]. In my opinion, Google only released Go to convince a ton of programmers it’s the New Hotness (TM), get everybody using it so they can cut down on training costs and disappointed engineers looking for resume-worthy tech to work on [2].

          So, any proposal for Go that violates Google’s work flow will be rejected [3]. Any proposal that is neutral or even helps Google, will probably be accepted. As far as I’m concerned, Go is a Google-proprietary language to solves problems Google has. The fact that it is available for others to use is intentional on Googles part, but in no way is it “communitty driven.”

          [1] Because if you change the signature of a function, it is up to you to change all the call sites at the same time. Because the code is all formatted the same way, there does exist tooling to do this. At Google. Probably no where else.

          [2] “What do you mean we got to use this proprietary crap language? I can’t put this on my resume! My skills will stagnate here! I hate you, Google!”

          [3] Stonewalled. Politely told no.. But ultimately, it will be rejected.

          1. 4

            To be fair, don’t trust the programmer, is a pretty good rule to follow when you design a language or API. Not because programmers are bad or incompetent but because they are human and thus predisposed to make mistakes over time.

        2. 5

          hrm, I actually want to push back against this quite strongly. any BDFL making decisions in the absence of community input will quickly find themselves the BDFL of a project that has no users, or at least one that often makes poor technical choices. Also, framing this disagreement as a personal one where prestige and reputation are at stake rather than as a technical one is a characterization that nobody other than the involved parties can make, certainly not people uninvolved in the project at all. In particular, making character judgements about people you don’t know based on technical blog posts is something I expect from the orange website, but I’d like to think the community here is a bit better.

          and as far as that technical disagreement goes, I’ve read through rsc’s rationale and I’m not any more convinced than I was in the beginning that jettisoning a well known package management path (SAT-solver) in favor of a bespoke solution is the correct decision. It is definitely the Golang thing to do, but I don’t know if it’s the best. Time will tell.

        1. 9

          It’s a bit sad he’s taking Rust mostly as a stepping stone to sell his thing. For example, he’s not showing any examples of code that actually has that problem. But, he’s definitely right.

          That being said, I find the following comment from Manish worth cross-posting: https://www.reddit.com/r/rust/comments/7sq8xl/unsafe_zig_is_safer_than_unsafe_rust/dt75ny6/

          I mean, unsafe C++ is also safer than unsafe rust (all zig is unsafe zig, all c++ is unsafe c++)

          Generally c++ does try to make it tedious to do really footgunny things. It’s hard to compare because UB is UB and nasal demons come out regardless, but ime the scarier kinds can be harder to trigger in c++ in many cases. Plus Rust has noalias. But this is very anecdotal, others may disagree.

          1. 4

            I don’t see why it is sad, it seems quite intelligent for him to adopt strategies that reach his target audience. What would really be sad is if he did all that work making zig and nobody gave it a shot because there was no reasonable way to get people to read about it.

            1. 4

              It’s generally not a good strategy to take simple shots at others. We’re as excited about zig as anyone else, but this sets up for an annoying and unnecessary competition.

              Framing it as “Zig gets pointer alignment right” and using Rust as an example later in the post is a much better strategy. People appreciate if you point out flaws in a not-too-annoying way. That’s for example a reason why I promote Pony at any moment I can, they really get this right.

              In any case, I definitely don’t intent on telling you how you should feel about it. I don’t like it and Rust happens to be the project I align with :).

              1. 4

                I understand what you’re saying about putting it in a positive light instead, but honestly I’m not sure I would’ve read the article if it had been “Zig gets pointer alignment right”.

                Rust has taken a similar approach, many times it has taken “shots” at C++ and Go (I say “Rust” but of course it’s about individuals) and that is fine IMO. It is both helpful for the language to get attention, and helpful for the reader to have it compared to something more widely known.

                I’m keeping an interested eye on Zig as I think it can turn into something great, that “better C” place that’s closer to C than Go and farther from C++ than Rust (that’s my impression of the language, I may be wrong as I don’t follow it that closely yet).

                1. 3

                  I don’t see it as taking a shot at Rust. At the end of the day here’s what I think will happen:

                  • Rust will improve handling of this particular problem (there’s no fundamental reason Rust can’t do it)
                  • Zig gets some attention

                  Both wins, in my book.

                  1. 7

                    I don’t see it as taking a shot at Rust.

                    The post starts with a language that’s safe-by-default with the temporal safety very rare in general. Cyclone and Clay are only predecessors coming to mind. The post then drops into unsafe Rust to focus on its weakest area: an area where you really want external tools like symbolic analysis or fuzzers running on it like with C. Then, post compares another language, Zig, with less safety in general to Rust in unsafe mode to show unsafe Rust is less safe in a specific case. Readers will find that the post pushing Zig sniping a weak area of Rust is also written by the author of Zig.

                    That is exactly how most language promoters take a cheap shot at another language getting more attention. You might have not intended it that way but many readers will perceive it that way. skade’s suggested framing here is always better for this sort of thing. Double true if you’re authoring both the post and a competing language.

                    And good luck on Zig since it’s an interesting language in the system space which I love seeing people try to improve. :)

                  2. 2

                    It’s generally not a good strategy to take simple shots at others. We’re as excited about zig as anyone else, but this sets up for an annoying and unnecessary competition.

                    It is a competition already, people can only use a finite number of programming languages. If someone is using rust on a project, they are not using zig and vice versa.

                2. 1

                  Not requiring a keyword to do unsafe operations doesn’t mean all code in a language is unsafe, it just isn’t explicitly spelled out when it is.

                  1. 6

                    Sure, but it means that any line of code is potentially unsafe.

                    1. 5

                      I like that the unsafe keyword in Rust makes it explicit. Makes it very easy to grep for unsafe behavior without additional tooling. Also frees up the mind from remember a list of unsafe operations while programming or while understanding other people’s code.

                      1. 3

                        That’s exactly it. Wirth did this in his languages like Oberon. Safe by default with unsafe modules saying so loud and clear.

                  1. 2

                    I guess someone has to link to the (legendary) Stack Overflow response about parsing HTML with regex: https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags

                    1. 2


                      Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.

                      • Jamie Zawinski
                      1. 5

                        I’ve always hated this quote (and most of its variations). As far as I can tell it boils down to “never use regular expressions”, which is bad advice.

                        1. 3

                          Indeed, I’d rather see someone use a regex where appropriate than try to re-invent a capture-group from scratch.

                          EDIT: I’ve seen some absolutely miserable text-extraction code written by juniors who hadn’t ever picked up regex because it was “icky”. A quick demonstration later the whole module could be deleted and replaced with a handful of neat little regexes, making good use of capture groups.

                          1. 1

                            I ‘grew up’ with Perl, so in that day and age, it was something that did need to be said…

                        1. 21

                          What I didn’t like about Vim was that a good number of plugins always felt like a hack…. Another popular plugin is Syntastic. I absolutely hate the way it displays the errors. It is not a smooth transition from “no error” to “error”. Not much to say here, it just looks awful, yet it is highly recommended.

                          Dedicated Vim user for about 8 years here. I feel this pain. My setup feels hacky.

                          Yet I’m not willing to lose the power of modal editing + command line integration (see my post, “Making Vim, Unix and Ruby sing harmony”, and I doubt any emulation will satisfy me.

                          Kakoune is the first editor I’ve seen that looks like it might be my future tool of choice; the author is like “I see why modal editing and Unix integration are great and I intend to do them better than Vim.” If the usability is also better, I’m sold. I’m just waiting to find the time and an easy enough onramp to start learning it.

                          1. 8

                            I second the Kakoune recommendation. It lacks plugins but is very promising. I missed CtrlP for example when I tried it.

                            1. 8

                              Vis is another option that I’ve been eyeing, along side Edit.

                              1. 1

                                micro is more nano like but it’s still a pretty good editor.

                              2. 8

                                Have you tried spacemacs out? it’s really a much better at customizing the editor than vim but still has a very well done version of vim emulation. I consider myself to be a power user of vim and spacemacs is very compelling if you don’t want the hacky feel. magit is a phenomenal package(shows just what a decent programming language inside the editor gets you) and changes the way I look at version control.

                                1. 8

                                  I tried Kakoune for a week around New Year’s. And it was surprising how deep I got into it. In the end, though, I found myself deeply incompatible with it.

                                  • In spite of being modal, Kakoune’s shortcuts started to feel like Emacs. Default chords like alt-C would require pressing three keys at once.

                                  • Kakoune’s scripting language started to feel just as hacky as Vim, albeit in different ways. More minimal, but a lot more nested-string escaping. If I was willing to put up with chords, why not just use Emacs and get a real language to script my editor with?

                                  • Critical keyboard shortcuts had no equivalent. { and } for navigating by paragraph. , was impossible to make work as I expected. X for deleting a character backwards. You can’t just hit w to skip ahead one word and then hit i to start typing. You have to hit w, then ; to reset the selection before you can start inserting. Just felt weird.

                                  • Kakoune has no window management. Instead you’re supposed to just use tmux. That felt nice and orthogonal in theory. In the spirit of Unix. But in practice it turned out to be not so nice. For example, I could open multiple windows in tmux panes, but Kakoune would always be in the directory I first started it in, rather than the directory I opened the current window at. There was no sequence of autocommands and scripting that would allow windows to have their own directories like Vim has. I think the same idea may apply to Rob Pike’s criticism of the proliferation of commandline flags in Unix: it’s easy to criticize Unix on principle, but when you get into the details it is perhaps not so bad.

                                  Perhaps I was just too programmed by Vim. I don’t know. Interesting, mind-broadening experience for sure. The lesson I was left with was something fundamental about software: we still don’t know how to unbundle the timeless essence of a piece of software (in the case of Kakoune, the object-verb grammar and multiple cursors) from the slow accretion of more arbitrary design choices like how you navigate by paragraph or the implementation of f and ;. Back in the git history of Kakoune is a sweet spot with a more compatible and elegant text editor. It may have missed some features, but it didn’t have conflicting features to a human being on Earth used to Vim.

                                  1. 2

                                    I had this exact same experience. Initially I went to emacs (and I still love bits of emacs - org-mode is outstanding) but for day to day editing I’ve transitioned to Visual Studio Code.

                                    It’s very featureful and its extension language is Javascript, which I’m finding much easier to wrap my head around.

                                    1. 1

                                      I love kakoune too, I think it’s heading in a very interesting direction. The always-on “visual mode” is great, and the use of standard UNIX tools to extend the editor makes a lot of sense. I implemented a simple “netrw”-style extension with little effort and calls to ls.

                                      One thing that bothers me though is the lack of a simple C key to replace until the end of the line, as in Vim. I use this very often, and maybe I just missed something, but it’s just not that quick and easy in kakoune, it would require a custom mapping or something, I believe.

                                    1. 1

                                      Interesting article, like many here I didn’t know about disown.

                                      To avoid the arrow keys, if you’re already a vi/vim user, it might be easier to set the bash vi option to on (set -o vi). You then have the modes as in vim, and pressing escape lets you use hjkl (so you can use k and j to move in your history), 0 to go to beginning of the line, $ for the end, move around words with w or e or b, etc. Pressing v brings your $EDITOR to edit the line.

                                      1. 10

                                        Note as prior art: Hadoop often uses an odd one-json-object-per-line format for the same reason, so you can parse it a lump at a time. i don’t see any real benefit in CSJ over that, since you could always skip the whole ‘comma separated’ bit and just make each line an array if that’s what you really want.

                                        However, i think this is missing the point: your parser should be able to deal with huge JSON documents incrementally. XML SAX parsers could. See also this blog rant: http://nick.zoic.org/etc/deserialize-alter-serialize-an-antipattern/

                                        1. 2

                                          CSJ has one glaringly obvious benefit: you don’t need to repeat the same set of keys single line. (And each line is implicitly an object, never any other kind of JSON value.) Compression can neutralise much of that difference, but not all of it.

                                          Of course that only constitutes a benefit if your data is actually tabular, rather than a sequence of objects with wildly variable shapes.

                                          1. 1

                                            I was coming to say exactly the same as your first point, Line separated json as a lot of bonus and zero malus comparing of CSJ

                                            1. 1

                                              See also Go, it has built-in support in the stdlib to parse such streams of JSON values: https://golang.org/pkg/encoding/json/#Decoder (e.g. https://play.golang.org/p/Y8MVKZVglf), and presumably other languages already have support for this too, compared to the proposed CSV-JSON. JSON values are already well-defined, so you don’t need a separator to know when one begins/ends (though whitespace is useful for humans, truenull9.12false is not super user-friendly).

                                            1. 2

                                              Quebec City, Canada