171–180 of 193 posts
I've been writing Go professionally, full-time, for the past five years. I'm a polyglot, so before Go, I loved exploring every new language I could get my hands on[0]. I still do, for fun, but Go is the one language that has kept me hooked all this time. It's not for any single feature, or for the community (though that's a great part of it). It's because it's the only language which I feel gets out of the way for me…
I appreciate the ruthless design choices behind Go. Crafting a language so there are as few ways as possible, and preferably one, to solve a problem must be beautiful at a large scale organization. In my experience java codebases in big companies are nightmare factories because of the freedom you get from more similar languages. The Go dream of having a single decent solution to a problem instead of 20 that range fro…
Large Java codebases in giant companies are often very poor because:
1. Giant non-software companies often have low hiring bars for their software teams.
2. They are full of bored programmers working on boring software, these people then find ways to make their lives more interesting and kill the time by over-engineering things.
3. These codebases are often very large, old, and have suffered many requirements changes with little or no time allocated to clearing technical debt.
There's nothing in Go that'd make any of these things better. It may superficially appear this way because Go is, in the grand scheme of things, still quite new and hardly used in the enterprise (because it doesn't solve anything better than Java), and as such there aren't any large enterprise codebases written in it. But if you compare the language features, it's hard to explain what would make Go result in better quality software than Java and easy to find things that'd make it worse.
Having dealt with enough spaghetti code over the years (just a few of industry experience, and some more years of academia), I understand what Go's strengths are. It's an opinionated language that stops users from being too clever or writing code that's too complex. That said, I've always hated the trends that have brought Golang into popularity. The engineers I've felt who could benefit from Golang the most could al…
> I'm a much bigger proponent of languages such as Rust or Haskell which give the developer the _tools_ to ensure their own data integrity As a big Rust proponent, I don't think it makes sense to invoke Rust here. The goal of Rust is to provide a more secure low-level foundation for software; any tools it provides to "ensure data integrity" are in service of that end, and pale in comparison to the sort of correctness…
Earlier quoted context omitted.
a developer who hasn’t heard of Go must live under some special kind of rock
A rock with ".NET" written on the side of it.
Earlier quoted context omitted.
Is there an editor that supports jump to definition for macros?
I don't know. I have a hunch that lots of macros still will be better with the new macro system, but we'll see. Anyway, regardless, there's certainly more work to do! And it's being actively developed quite heavily. For example, it will be on stable Rust very soon.
Earlier quoted context omitted.
Hopefully it's a very good kind of rock where there are no bad languages like Go.
what makes it a bad language? have you written much in it? what didn't you like/couldn't you do?
Earlier quoted context omitted.
It is certainly a fantastic solution, and I definitely appreciate the work that Sam Boyer and the `dep` contributors do. There's a lot of "gotya"s with using dep though. One that gets me a lot is the fact that I like to commit my vendor folder, just for faster CI. So if I committed my vendor folder with a copy of "k8s.io/client-go", and then in a different project I imported a package from my vendored project, it wou…
Ok, but why would you do that? Either just vendor it in the new project (copy-paste a directory) or download it to your gopath and import that. The nice thing is that you don't have to change the import when you decide to vendor.
If I have project A, which imports dependency A. I (for faster tests is the only real answer), decided to commit the vendor folder.
Now, in project B, if I import a package of project A, which uses dependency A, it will look for that specific version of dependency A. Specifically errors like this:
pkg/projectb/example.go:18:30: cannot use *w (type "github.com/dependency/pkg".Example) as type "github.com/project/a/vendor/github.com/dependency/pkg".Example
because of this, I guess my real complaint here is that "vendor" doesn't seem to be the right word. I'm really just looking for something to complain about.
Earlier quoted context omitted.
(NOTE: I am not a gopher) I thought godep was that? It's marked as suitable for production now, and I think official as of their next release. https://github.com/golang/dep
>(NOTE: I am not a gopher) I thought godep was that? It's marked as suitable for production now, and I think official as of their next release. I didn't realize they were working on solving this, that's fantastic. Hopefully it can gain traction.
My favorite line: "Go is huge in China". My first thought: don't they mean Weiqi!?
Earlier quoted context omitted.
> but I was heavily impressed by both Goroutines and channels as ideas You know they didn't invent this right?
goroutines are definitely unique to go. I'm sure the approach/style has been done before but this implementation is pretty unique to Go.