3 ms·

I suspect you are just hating. The fact that you immediately glom onto the dependency management issue which EVERYONE KNOWS AND KEN AND ROB ARE REALLY SORRY YAL

I suspect you are just hating. The fact that you immediately glom onto the dependency management issue which EVERYONE KNOWS AND KEN AND ROB ARE REALLY SORRY YALL and also try to cut gofmt and govet off at the pass, which come on, let's be real, the fact that something exists that might remotely resemble those concepts is an extremely fucking far cry from them being standard community practices which if you don't see the value of that then you never dealt with other people's C code... indicates that you know in your heart of hearts exactly how great Go's tooling is. go run, go test, go build, boom! so simple. Oh and might I mention the race detector? Fucking incredible, C never dreamed of something like that. There are plenty of good third-party options available for dependency management (nice double standard btw since you apparently have no problem with third-party stuff for fmt/vet/lint concerns) and there is also this https://golang.org/cmd/go/#hdr-Vendor_Directories https://golang.org/cmd/go/#hdr-Vendor_Directories so a better world is coming don't you fret.

pcwalton 11y ago
> Oh and might I mention the race detector? Fucking incredible, C never dreamed of something like that. go race is pretty much a port of Thread Sanitizer, which was a C tool. Before that, there was Helgrind, also a C tool. All of these tools have a long list of forerunners in academia, largely for Java (Eraser, FastTrack, etc.)
- goldbrick 11y ago
  go race is Thread Sanitizer, in fact, but see again my point about being part of the community best practice vs. a third-party tool you may or may not have heard of. Eraser and FastTrack are un-googleable, if you have any links they would be appreciated.
cyphar 11y ago
I wrote Go code all the time, and I don't /hate/ it. But it would be a mistake to call Go's tooling "incredible". The race detector is /sometimes/ useful, but it doesn't do any "real" analysis (you have to be very close to the race window in order to trigger the race detector to complain, which is quite difficult for more obscure race conditions based on random variables). The Linux kernel (which as we all know is written in C) has lots of far more sophisticated detection of lock contention and other such things at runtime. But I think you need static analysis if you actually want to figure out where races might exist in your code. Vendoring makes life hard for people who have to package software. Traditionally, you have build dependencies which are the libraries your software uses. In Go (because nobody follows semantic versioning when changing the API of their libraries, and the Go tooling doesn't allow you to specify versions of a package -- WHICH IS ACTUALLY CRITICAL) you just have to dump all of your dependencies into the same place as your source and be done with it. I don't see why people see vendoring as the solution. Defining version dependencies in your source is the solution if you want to go with "our source code defines what we need to pull in". Don't get me started on the static linking issue. Oh, and build dependencies have to be packaged as source code (packaging them in their compiled form is quite hard to do).

pcwalton 11y ago

> Oh and might I mention the race detector? Fucking incredible, C never dreamed of something like that. go race is pretty much a port of Thread Sanitizer, which was a C tool. Before that, there was Helgrind, also a C tool. All of these tools have a long list of forerunners in academia, largely for Java (Eraser, FastTrack, etc.)

goldbrick 11y ago
go race is Thread Sanitizer, in fact, but see again my point about being part of the community best practice vs. a third-party tool you may or may not have heard of. Eraser and FastTrack are un-googleable, if you have any links they would be appreciated.

cyphar 11y ago

I wrote Go code all the time, and I don't /hate/ it. But it would be a mistake to call Go's tooling "incredible". The race detector is /sometimes/ useful, but it doesn't do any "real" analysis (you have to be very close to the race window in order to trigger the race detector to complain, which is quite difficult for more obscure race conditions based on random variables). The Linux kernel (which as we all know is written in C) has lots of far more sophisticated detection of lock contention and other such things at runtime. But I think you need static analysis if you actually want to figure out where races might exist in your code. Vendoring makes life hard for people who have to package software. Traditionally, you have build dependencies which are the libraries your software uses. In Go (because nobody follows semantic versioning when changing the API of their libraries, and the Go tooling doesn't allow you to specify versions of a package -- WHICH IS ACTUALLY CRITICAL) you just have to dump all of your dependencies into the same place as your source and be done with it. I don't see why people see vendoring as the solution. Defining version dependencies in your source is the solution if you want to go with "our source code defines what we need to pull in". Don't get me started on the static linking issue. Oh, and build dependencies have to be packaged as source code (packaging them in their compiled form is quite hard to do).