191–200 of 249 posts
3542 files 540,000 lines of Go code 65,000 lines of comments So on average only 170 lines per file, including 17 lines of comments. Are this normal ratios ?
The LOC per file average seems slightly high for my taste but okay.
I'm 3.5 years into using Go exclusively as well, and this rings very true to me with regard to generics: > Interfaces are good enough 99% of the time. Generics would be really nice for generic data structures (heaps, trees, etc), but code generation is ok at that. Generics could allow for some nicer (and safer!) nil handling and error checking, but I think the benefits-vs-complexity are less clear than with generics…
Agree. I feel it so much.
I stopped counting the companies I couldn't join because they had exotic languages or just the latest fad of the year.
That's a very effective way for a company to stay away from having any experienced engineer while making it very hard to recruit at all (note that both effects amplify each other!). The hardest and newest the languages, the worst it is.
As an employee, that's a painful way to have a company cancel a decade worth of experience. I'm not interested in starting fresh again. Bye.
I happened to believe that a language should have one style. You want a functional language? Use it. You want a procedural language? Use it. You want an OOP language? Use it. They're all good, but not in one language. For example, you like FP idioms, and program everything with maps. I like for loops. You have to fix my code one day I'm on vacation. You think that it's ugly, and rewrite it as a map. I get back, bug c…
There should be one-- and preferably only one --obvious way to do it.Earlier quoted context omitted.
I think you are missing the point. Of course you can't assume what a function will do with certainty.
From CS point of view + is just a function name just like any other. A concept used in lambda calculus, introduced in computing since Lisp exists. Also part of abstract mathematics field, where operator symbols get defined for the proofs.
From a Go point of view, it isn't.
Earlier quoted context omitted.
From CS point of view + is just a function name just like any other. A concept used in lambda calculus, introduced in computing since Lisp exists. Also part of abstract mathematics field, where operator symbols get defined for the proofs.
> From CS point of view + is just a function name just like any other. From a Go point of view, it isn't.
[1] - According to the language designers own words
Earlier quoted context omitted.
Even though I've written more ruby than anything else over the last decade, I have to agree with this. Ruby is nice OO language, but it's unabashedly multi-paradigm, and that leads to a lot of mess when you get a team with varying backgrounds the result is potentially a byzantine mix of procedural, object-oriented and functional styles.
When you are in a big project a multi paradigm language seems to be the only way for introducing new styles. In the stuff I am working on I can't just switch to a new language. I agree that this can create a mess though.
The beauty of Java, Go and Haskell (never thought I'd use those 3 in the same sentence) is that you really have to work to fuck things up that badly.
Earlier quoted context omitted.
one of the things that go eschews is operator overloading. a := b + c What's the runtime complexity of this statement? How much memory will it cause to be allocated? In go there's only two possibilities for what this code is doing... either this is string concatenation, or it's adding two numbers. Both of which are immediately comprehensible for impact on run time and memory. In C#, you can overload operators, so the…
Hogwash. In a language with operator overloading, this would be something like `a.assign(b.plus(c))`. Which really doesn't tell you more about what go on under the wraps than the operator form. What can be confusing is what the meaning of `+` (or `plus` is). In some case it can be fairly obvious (e.g. concatenating sequences), while in other not so much. Operator overloading is nice, but has to be used tastefully (li…
What can be confusing is what the meaning of `+` (or `plus` is)
QED
Earlier quoted context omitted.
> From CS point of view + is just a function name just like any other. From a Go point of view, it isn't.
Just because Go eschews decades of CS knowledge, in the name of the "easy to hire programmers" for Google[1], it doesn't make it less true. [1] - According to the language designers own words
Earlier quoted context omitted.
Just because Go eschews decades of CS knowledge, in the name of the "easy to hire programmers" for Google[1], it doesn't make it less true. [1] - According to the language designers own words
What you wrote isn't a universal truth. In Go, + is not a function like any other. There's no argument to this.
Earlier quoted context omitted.
I've got another heresy coming up: Outside of very specific fields, language doesn't matter . I was quite strongly attacked on another thread for implying that WhatsApp is just another CRUD app. The thing was that I wasn't bashing their dev team. They could have done a crazy amazing job, and it helped their company take off, but what was their secret sauce? The ability to have an (almost) free SMS/MMS app which worke…
The problem is that WhatsApp really isn't just another CRUD app and it's very unlikely that you could pull off an engineering feat of that scale with a different technology. It is the exact counterexample of what you say.
That's it.
It's not that different from Facebook.
Now, to get it to scale it may pay to use a high-reliability language. To make it secure you may not want to write it in C. But it would have taken off the same had it been written in Perl, PHP, Lisp, C, Assembly or Erlang.
Maybe it would have needed more hardware.
Maybe it would have crashed a few times.
But it would have taken off nonetheless.