4 ms·

> "As such, the only people who can criticize it are people who know it back to front. Anyone else will be told that they're not using it properly." ...they sa

by swores 3y ago

> "As such, the only people who can criticize it are people who know it back to front. Anyone else will be told that they're not using it properly." ...they said, in a thread full of people criticising different aspects of Git without proving their git-expert credentials nor being accused of being the problem themselves. I'm sure that as with pretty much any widely used thing there are both people who criticise it unfairly because they don't know how to use it for what they're trying to do, and also fans who over-defend it blaming users for not knowing every single little detail and sometimes blaming the user for a problem with Git. But it doesn't seem from what I've seen generally that it's a problem for anyone to criticise Git's flaws, just that there often isn't an answer to "well, what better alternative is there?".

pydry 3y ago
I always preferred mercurial to git. I held out a long time using it but it became clear over time that the benefits of using it were outweighed by the network effects that accrued to git simply because everybody was using it. HN tends to be a bit more open and less conservative than the average dev team. The thing about horrible UXes is that you get used to them. Then once you know it back to front that becomes an impediment to switching. There's an entire generation of developers now who have grown up never having known anything other than git.
- sanderjd 3y ago
  Yeah, mercurial is better than git, but not that much better. It's not so hard to learn both well, and be happy when you have a chance to use mercurial, while remaining content when you're using git instead.
  - pydry 3y ago
    Not that much better is true, but every time I see tech that is worse win because it had better marketing it makes me sad and a little angry. It was quite irritating to invest time not only in figuring out which was better initially (only to discover that this didn't matter), but to invest time learning the better one and then to lose all that investment in memorizing commands/keystrokes/concepts. It's true that most of them map so it's way easier than picking it up from scratch, but it's still a hefty chunk of effort and the annoyance I felt because I felt like I shouldn't have to do this made it harder. Mongo makes me rage for the same reason (but way worse). I know I could learn about its equivalents of indexes and foreign keys and materialized views or whatever but I honestly really just want it to fuck off and die and get replaced by postgres in every single situation where it is used. It is a genuinely shittier technology that grew popular on the strength of marketing (image) rather than quality and that is why I'm forced to learn it.
    - sanderjd 3y ago
      I don't think "better marketing" is the main thing going on. I think the main thing is network effects. For git specifically, I think having a giant project right out of the gate gave its initial "network" of people who knew how to use it such a huge head start that it was always going to be difficult for anything else to catch up, at least in open source, where network effects matter a lot. I do think the story with MongoDB in particular has a lot to do with marketing, but IMO the broader story is that objects (/ "documents") are actually a more natural fit for modeling the storage of application state in oltp databases than are relational databases (though relational databases are certainly unmatched for analytical use cases). I'd say that the popularity of MongoDB despite the relative weakness of its implementation of that insight has been more annoyingly detrimental to the object/document store approach than to the relational DB approach. That is, the backlash to "MongoDB doesn't work very well" has been "just use postgresql" rather than "we need a better document database implementation". Coincidentally, just yesterday I was looking into pg's object store capabilities in order to suggest "use pg as a hybrid relational / document store" as a potential compromise solution to get to consensus in a relational vs. document-store discussion. But I found it pretty lacking, frankly. It's nice that jsonb exists, but its capabilities seem quite limited. For instance, it seems I can't use json-schema to define the schema of a jsonb column? (I did conclude that I need to do more research before rejecting this out of hand, but my initial research was not as promising as I had hoped.)
- thatfunkymunki 3y ago
  Using mercurial/sapling at work is really nice
marcosdumay 3y ago
To be fair, most of the criticism upthread embeds the criticizer credentials just by the fact that those problems are very hard to notice. The thing that you can't easily criticize is that the UI isn't very clear and gives no confidence that what you are doing is actually correct. -- But I imagine at this point, it's safe :) Other VCS out there do have better UIs, with concepts are are more clearly told apart (or not confusingly separated, like tags from commits). But none is so much better that it's worth abandoning everything an copying them.

by swores 3y ago

pydry 3y ago

I always preferred mercurial to git. I held out a long time using it but it became clear over time that the benefits of using it were outweighed by the network effects that accrued to git simply because everybody was using it. HN tends to be a bit more open and less conservative than the average dev team. The thing about horrible UXes is that you get used to them. Then once you know it back to front that becomes an impediment to switching. There's an entire generation of developers now who have grown up never having known anything other than git.

sanderjd 3y ago
Yeah, mercurial is better than git, but not that much better. It's not so hard to learn both well, and be happy when you have a chance to use mercurial, while remaining content when you're using git instead.
- pydry 3y ago
  Not that much better is true, but every time I see tech that is worse win because it had better marketing it makes me sad and a little angry. It was quite irritating to invest time not only in figuring out which was better initially (only to discover that this didn't matter), but to invest time learning the better one and then to lose all that investment in memorizing commands/keystrokes/concepts. It's true that most of them map so it's way easier than picking it up from scratch, but it's still a hefty chunk of effort and the annoyance I felt because I felt like I shouldn't have to do this made it harder. Mongo makes me rage for the same reason (but way worse). I know I could learn about its equivalents of indexes and foreign keys and materialized views or whatever but I honestly really just want it to fuck off and die and get replaced by postgres in every single situation where it is used. It is a genuinely shittier technology that grew popular on the strength of marketing (image) rather than quality and that is why I'm forced to learn it.
  - sanderjd 3y ago
    I don't think "better marketing" is the main thing going on. I think the main thing is network effects. For git specifically, I think having a giant project right out of the gate gave its initial "network" of people who knew how to use it such a huge head start that it was always going to be difficult for anything else to catch up, at least in open source, where network effects matter a lot. I do think the story with MongoDB in particular has a lot to do with marketing, but IMO the broader story is that objects (/ "documents") are actually a more natural fit for modeling the storage of application state in oltp databases than are relational databases (though relational databases are certainly unmatched for analytical use cases). I'd say that the popularity of MongoDB despite the relative weakness of its implementation of that insight has been more annoyingly detrimental to the object/document store approach than to the relational DB approach. That is, the backlash to "MongoDB doesn't work very well" has been "just use postgresql" rather than "we need a better document database implementation". Coincidentally, just yesterday I was looking into pg's object store capabilities in order to suggest "use pg as a hybrid relational / document store" as a potential compromise solution to get to consensus in a relational vs. document-store discussion. But I found it pretty lacking, frankly. It's nice that jsonb exists, but its capabilities seem quite limited. For instance, it seems I can't use json-schema to define the schema of a jsonb column? (I did conclude that I need to do more research before rejecting this out of hand, but my initial research was not as promising as I had hoped.)
thatfunkymunki 3y ago
Using mercurial/sapling at work is really nice

marcosdumay 3y ago

To be fair, most of the criticism upthread embeds the criticizer credentials just by the fact that those problems are very hard to notice. The thing that you can't easily criticize is that the UI isn't very clear and gives no confidence that what you are doing is actually correct. -- But I imagine at this point, it's safe :) Other VCS out there do have better UIs, with concepts are are more clearly told apart (or not confusingly separated, like tags from commits). But none is so much better that it's worth abandoning everything an copying them.