181–190 of 233 posts
Earlier quoted context omitted.
Which is why Go is advocating using "go generate" to generate code. See projects such as https://clipperhouse.github.io/gen/
A fantastic idea, even slower to compile (since you need to parse extra source files), more complex workflow, and extra files which developers have to remember to ignore.
Just as K&R introduced us to "Hello, World," I'm amused they adapted their first program to an Unicode world: "Hello, 世界." Seems like a great first chapter, covering computer graphics and web server/byte fetching to boot.
> they adapted their first program to an Unicode world: "Hello, 世界." Would be nice if you could compose those complicated Unicode characters from simpler building blocks, e.g. fmt.Printf("Hello, %a", "→↘𠃊廿↓田介")
Earlier quoted context omitted.
> Developer time costs more than compiler time. I find that to be a very odd statement. Usually, the developer waits for the compiler in order to find out if the code compiles and executes properly. That is, every minute of compiler time costs a minute of developer time. Worse, the developer time you spend due to lack of a feature, you spend while writing some code that would benefit from the feature. The compiler ti…
> I find that to be a very odd statement. Usually, the developer waits for the compiler in order to find out if the code compiles and executes properly. That is, every minute of compiler time costs a minute of developer time. If your business starts to hit a wall on compile times you can buy a computer that can compile twice as fast. It's much harder to buy a developer who can think twice as fast. And every year the…
Buying a fast machine only gets you so far. Large C++ projects take minutes to compile even on the fastest machines available. Plus, you'd need to buy one for every developer.
> when you have a 2000-line Go project, in language X you'd be able to cut 500 lines from each half of it considering each half in isolation - and then you'd be able to cut some more because of things that were common between the two halves - so you'd end up with just 750 lines of language X.
While this is true in theory, in practice I think the effect is not quite as large. As the project grows, developers take ownership of certain parts of the code and become ignorant of other parts. This is the whole point of abstraction. Under these conditions it will take a heavy investment of time and effort to find and replace the things in common between the two halves. So you might cut 250 lines in common between two 1000-line halves, but you're not going to cut 25,000 lines in common between two 100,000-line halves without a serious amount of work.
I think Go's design shows awareness of this effect. The Go literature does not preach the battle against code duplication as strongly as, say, Java. The goal is to make it easy to understand the other team's 100,000 lines, even if that comes at the expense of some code duplication.
Note: I am not a Go programmer, but I do think that optimizing for ``code entropy'' (lack of duplicated code) over all else is a mistake.
Earlier quoted context omitted.
Never gonna happen, Go 2 is considered harmful.
This is one of the things I like about Go: it's "done." In exchange for passing on extensions that might make certain use cases easier, we'll avoid the bloat and have decades of backward compatibility. We just came out of a decade of nifty language mania. What I learned is that languages are boring but problems are interesting. Algorithms and solutions are interesting. A great solution to a challenging problem is rea…
Earlier quoted context omitted.
Which is why Go is advocating using "go generate" to generate code. See projects such as https://clipperhouse.github.io/gen/
A fantastic idea, even slower to compile (since you need to parse extra source files), more complex workflow, and extra files which developers have to remember to ignore.
Earlier quoted context omitted.
Never gonna happen, Go 2 is considered harmful.
This is one of the things I like about Go: it's "done." In exchange for passing on extensions that might make certain use cases easier, we'll avoid the bloat and have decades of backward compatibility. We just came out of a decade of nifty language mania. What I learned is that languages are boring but problems are interesting. Algorithms and solutions are interesting. A great solution to a challenging problem is rea…
From the book: "But it has comparatively few features and is unlikely to add more. For instance, it has no implicit numeric conversions, no constructors or destructors, no operator overloading, no default parameter values, no inheritance, no generics, no exceptions, no macros, no function annotations, and no thread-local storage."
Are they actually proud of having no generics? :o
For instance, when generics are mentioned in relation to Go, then it should auto-reply with this link: https://news.ycombinator.com/item?id=9622417
It would save so much time.
Earlier quoted context omitted.
Users of Acme, written by Rob Pike. See screenshots on this page and note that the font used is not monospaced. http://acme.cat-v.org/
Is there a reason why Acme doesn't use a monospace font? I couldn't find any justification on that site.
Earlier quoted context omitted.
> While I think your comment is unconstructive, I do have to say that I don't quite understand why Go decided to force hard tabs. Since you're using goftm which imposes a strict discipline, tab-indents and space-align allows configuring tabwidth however you want locally without imposing that on other collaborators. The issue with the idea is usually doing it consistently and people properly configuring their editor (…
people properly configuring their editor A lot of coding is reading examples online these days. Trying to read Go code on GitHub is awful since three forced tab indents feels like you're 50% across the screen already (and forget trying to read it on mobile). Browsers don't really have a "set tab width" option that I've found (and forget trying to set user options on mobile browsers). a check against nesting code too…
From the book: "But it has comparatively few features and is unlikely to add more. For instance, it has no implicit numeric conversions, no constructors or destructors, no operator overloading, no default parameter values, no inheritance, no generics, no exceptions, no macros, no function annotations, and no thread-local storage."
> no default parameter values Hearing this leaves a bad taste in my mouth, because one of the (mis)features I've found in Go is its implicit default value in struct initialization. In Go, you don't get a compile error when you miss some fields while initializing a struct. e.g. type T struct { a int b string c float64 } t := T{c: 1.5} will happily set `t.a` to 0 and `t.b` to an empty string. While this is useful for m…