News for hackers. Stuff that matters.
Re:Go at Google: Language Design in the Service of Software ... by bishop_mandible on Tuesday December 04, 2012 @07:31PM (#4874202)
"For the record, around 1984 Tom Cargill observed that the use of the C preprocessor for dependency management would be a long-term liability for C++ and should be addressed."

And in 2012 Apple tries to address it: http://news.ycombinator.com/item?id=4832568

Re:Go at Google: Language Design in the Service of Software ... by myg204 on Tuesday December 04, 2012 @08:04PM (#4874307)
Go is 3 years old. Also, golang addresses more than just this issue, the concurrency approach is interesting for example.
Re:Go at Google: Language Design in the Service of Software ... by cjensen on Tuesday December 04, 2012 @08:18PM (#4874357)
D is 11 years old and solves the exact same problems plus it uses a more traditional approach to objects.

The big difference is Go has Google+Pike pushing it and might actually get widely adopted. Getting some improvement is not a bad thing.

Re:Go at Google: Language Design in the Service of Software ... by danieldk on Wednesday December 05, 2012 @03:35AM (#4875454)
The big difference is Go has Google+Pike pushing it and might actually get widely adopted.

I don't think it is just that. There is also a difference in culture and tradition. Roughly, Go fits more in the C and Python tradition, D and Rust fit more in the C++ and Haskell tradition. Simplicity versus formal correctness.

I think the Python/C pond is just larger than the C++/Haskell pond.

Re:Go at Google: Language Design in the Service of Software ... by agentS on Tuesday December 04, 2012 @08:45PM (#4874440)
Considering one of the goals of the language is simplicity, I don't see how D has solved this problem.
Re:Go at Google: Language Design in the Service of Software ... by pjmlp on Wednesday December 05, 2012 @03:05AM (#4875400)
Because everyone else doesn't want to throw away the last 20 years of language design.

Go's search for simplicity is seen as a solution looking for a problem in the language design communities.

Re:Go at Google: Language Design in the Service of Software ... by danieldk on Wednesday December 05, 2012 @03:27AM (#4875440)
Go's search for simplicity is seen as a solution looking for a problem in the language design communities.

But most programmers are not in language design communities. There is a big potential for a 'safer C' or a 'faster Python'. Yes, that's a simplification, but also how people will see Go.

Re:Go at Google: Language Design in the Service of Software ... by pjmlp on Wednesday December 05, 2012 @04:14AM (#4875543)
> 'faster Python'

Why throw away Python's capabilities to execute it faster? Just make use of PyPy.

Re:Go at Google: Language Design in the Service of Software ... by Symmetry on Wednesday December 05, 2012 @09:31AM (#4876362)
PyPy is geometrically about halfway between CPython and Go, performance-wise.
Re:Go at Google: Language Design in the Service of Software ... by pjmlp on Wednesday December 05, 2012 @10:07AM (#4876527)
For the type of applications Google is showing off with Go, I doubt it matters.
Re:Go at Google: Language Design in the Service of Software ... by drivebyacct2 on Tuesday December 04, 2012 @09:13PM (#4874508)
I do not mean this as an attack but have you written much actual "real" Go code?

There are several reasons I'm interested in D and more so Rust, but they're very different than Go.

Re:Go at Google: Language Design in the Service of Software ... by codewright on Tuesday December 04, 2012 @11:29PM (#4874885)
I do not mean this as an attack but have you written much actual "read" D code?

See how this never ends?

Re:Go at Google: Language Design in the Service of Software ... by drivebyacct2 on Tuesday December 04, 2012 @11:35PM (#4874901)
Not really given that I think you're missing out on the advantages of Go, looking for the wrong things and generally missing the point of the article entirely.

And yes, I have. Hence my comment.

Er, you weren't the GP, sorry, but my point remains, though somewhat directed a cjensen.