44 ms·
Rust comes to mind. Almost all projects fetch dependencies and build the same way (cargo), with very similar looking project structures and entry point. The com
by kenhwang 8y ago
Rust comes to mind. Almost all projects fetch dependencies and build the same way (cargo), with very similar looking project structures and entry point. The community has rallied around a set of libraries that's used by everyone.
I couldn't care less about formatting differences between repos. Ignoring superficial formatting difference, Ruby's community also has one package manager (bundler) and build tool (rake) with a widely followed naming convention and directory structure and community consensus set of libraries.
Both the above languages I can build a codebase I've never seen before and have it running within minutes even without README.
Go feels like the wild wild west. Everyone has their own directory structure, with different ways of fetching dependencies (modules vs dep), building (seems to have consolidated around go build vs make), with everything hand rolled or whatever NIH selection criteria they used for their libraries.
- bpizzi 8y ago> ways of fetching dependencies (modules vs dep) Yes, an 'official' package manager have clearly not been a target for the core team for a (way too) long time, whereas Rust has envisioned that 'community' part from the beginning. > I couldn't care less about formatting differences between repos. Whereas, to me, an official, no-question-asked tool like 'gofmt' is godsend. It really depends on what you're building and in which context. > , building (seems to have consolidated around go build vs make) Not sure here, 'go build' is clearly the idiomatic building way from almost day one. > Both the above languages I can build a codebase I've never seen before and have it running within minutes even without README. That was rather not (enough?) straightforward under %GOPATH% era, indeed. Today, with Go modules, its a one liner 'git pull; go build', granted you have Go 1.11 available in %PATH% and that the codebase already have a go.mod file (if not, a 'go mod init <pkgname>' should fix it).