Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Don't Want to Learn Go

arantaday.com

Post reply on HN
Print view View original

111–120 of 139 posts

Re: Why I Don't Want to Learn Go

#111

Post by leoc »

dagw wrote: post #53
leoc wrote: post #49

Earlier quoted context omitted.

I'd guess that C++, Java and NIH are all powerful forces at Google.

Given that Google hired Guido Van Rossum and that python is one of the three (and up until very recently two) supported languages for GAE, I think we can safely assume the Google isn't entirely anti python.

> I think we can safely assume the Google isn't entirely anti python.

I don't suggest otherwise. It's known that Python is one of Google's three languages approved for internal use (or apparently four now that JS has got a foothold). But I'm sure I've seen reports that people are nonetheless being pushed towards Google's other two officially blessed languages, at least on production code - and in fairness, Google is a place where developer time is often cheaper than the machine time you have to spend to save developer time. But moveover it seems that, even when people in Google do want to fix their Python performance issues by making Python perform better rather than by reducing its use, they tend to want to do it in-house rather than by adopting or supporting other people's work: look at Unladen Swallow. That would be in line with the rather hubristic, command-economy approach - "let's hire all the world's smartest people, then order them to build the future" - that seems to determine Google's actions in general. Hiring GvR fits that pattern too (as well as making plenty of sense).

But I'm sure other people here are much better informed about this than I am.

Re: Why I Don't Want to Learn Go

#112

Post by meepmorp »

tesseractive wrote: post #107
meepmorp wrote: post #89

Earlier quoted context omitted.

I think F# is largely based on OCaml. I'm not sure what'd make a language official; MS does the development work on it, so I guess that'd be a yes on officialdom?

To be more precise, F# is based on the non-OO parts of Caml, with a completely different object system so it would be be compatible with .Net objects from other languages such as C#. IIRC, the original research was going to be into making Haskell for .Net, but there were enough issues (in particular, being purely functional makes interop with C# and the existing .Net libraries radically more difficult) that ML seemed…

Ah, thanks. I was going on a vague memory of something read a while back. I wasn't entirely wrong - 40% maybe - so that's nice.

Re: Why I Don't Want to Learn Go

#113

Post by edwardw »

zoul wrote: post #34
microtonal wrote: post #16

Earlier quoted context omitted.

Go is designed for large codebases, which is a problem that the author may not have, and so he may not see the benefits. Aren't most serious languages designed for large code bases? (and compile faster than anything else), So, why not invest in incremental compilation for an existing language? E.g. the ECJ compiler for Java has done wonders in terms of immediate feedback while developing. clang aims to do the same fo…

> Aren't most serious languages designed for large code bases? Maybe the big companies like Google and Facebook are approaching a new meaning of a “large codebase”. They have a huge number of programmers, the development is much more distributed into different locations and time zones, and the release cycles are much smaller than they used to be with large codebases in the past. There’s for example this very interest…

> Maybe the big companies like Google and Facebook are approaching a new meaning of a “large codebase”.

If codebase is that large, language alone can't solve all the problems. Be it compiling time, testing time, or whatever problems large codebase may have. I guess that's exactly what Steve Yegge tried to say in his famous Platform Rant blog post.

Re: Why I Don't Want to Learn Go

#114

Post by pjscott »

smanek wrote: post #5
babarock wrote: post #3

Unfortunately, as much as I want to agree with it, the article seriously lacks any credibility. Go claims to present high-level features (namely GC) for low-level system programming. Obviously, this sounds new and ground-breaking. Simply dismissing it on account that "GC is unacceptable [for low level problems]" is nothing short of stating a disbelief: it doesn't prove anything. If anyone wants to prove any shortcomi…

Do you seriously doubt that the Go GC is significantly worse than the Oracle JVM GC (by the metrics of pause times and throughput)? I don't think I've ever heard anyone suggest that it isn't. My point with this article is simply that, even if Go's GC catches up to the JVMs (which would be an amazing accomplishment in itself), it would still be too inefficient for serious systems work. I provided several real-world ex…

IIRC the Go authors have explicitly said that there's probably a lot of low-hanging fruit for improving their GC implementation -- they were focused on getting something working and out the door.

Re: Why I Don't Want to Learn Go

#115

Post by drucken »

Article summary: Go is a "better" Java. Why would it claim to be a systems programming language?

It is a fair point. If anything it illustrates that Google have mis-marketed the product rather than anything else.

Re: Why I Don't Want to Learn Go

#116

Post by pjscott »

minimax wrote: post #65
smanek wrote: post #31

Earlier quoted context omitted.

It's different, because I'm saying that much system level work has to optimize by not using a garbage collector . I've literally implemented off-heap malloc()/free() in Java because GC is so untenable. I argue that makes a language with has a GC that you can't avoid (as far as I know, it's impossible to allocate an 'object' off-heap in Go) a fairly poor choice for much system level work. Which means, if Go is to find…

I don't think you're getting his point. I can still replace GC with malloc() and we end up with the same criticisms of C that you have of Go and Java. > I'm saying that much system level work has to optimize by not using malloc(). I've literally implemented off-heap malloc()/free() in C because malloc() is so untenable. Anyone who has had to write fast C programs that make a lot of small objects eventually ends up he…

You could make the same kind of criticisms, but not with the same strength. there are real quantitative differences between the speed of explicit malloc/free and even a really nice garbage collector. (Unless you have a very special allocation pattern, like a whole lot of short-lived allocations and a generational garbage collector that uses stop-and-copy for the nursery generation. That's like the best possible case for GC.)

Re: Why I Don't Want to Learn Go

#117

Post by acdha »

adgar wrote: post #100
zoul wrote: post #25

Earlier quoted context omitted.

Obligatory link benchmarking various Objective-C operations: http://www.mikeash.com/pyblog/performance-comparisons-of-com...

I'm a bit concerned about at least one measurement: Read 16-byte file 100000 iterations 2.1s for 100k reads 21219.3ns per read This appears to be testing... the filesystem cache? It's certainly not seeking on a rotational disk, "SSD" isn't on the page, so... not sure where he's getting 21 microsecond reads from.

It's measuring the overhead of a set of open()/read()/close() syscalls - exactly the situation where you would want to use the cache to avoid physical disk latencies swamping the language variation.

Re: Why I Don't Want to Learn Go

#118

Post by edwardw »

nknight wrote: post #98
flogic wrote: post #76

Earlier quoted context omitted.

In C, don't people just allocate a slab of memory for critical paths too?

Sometimes, perhaps, but simple malloc/free are much faster and more predictable than what you see in GC'd languages, often mitigating the problem. On top of that, many critical paths can avoid even those by confining their memory allocation to the stack, something that effectively ceases to exist in GC'd languages.

> but simple malloc/free are much faster and more predictable than what you see in GC'd languages

More predictable, very likely. Much faster, this is simply not true. E.g., quotes from an article by Brian Goetz[1]:

  The common code path for new Object() in HotSpot 1.4.2 and later is
  approximately 10 machine instructions, whereas the best performing
  malloc implementations in C require on average between 60 and 100
  instructions per call. ... "Garbage collection will never be as efficient
  as direct memory management." And, in a way, those statements are right
  -- dynamic memory management is not as fast -- it's often considerably faster.
> allocation to the stack, something that effectively ceases to exist in GC'd languages.*

Not true, either. With escape analysis, Hotspot JVM can do stack allocation. The flag of doing escape analysis is actually turned on by default now.

[1] http://www.ibm.com/developerworks/java/library/j-jtp09275/in...

Re: Why I Don't Want to Learn Go

#119

Post by nknight »

edwardw wrote: post #118
nknight wrote: post #98

Earlier quoted context omitted.

Sometimes, perhaps, but simple malloc/free are much faster and more predictable than what you see in GC'd languages, often mitigating the problem. On top of that, many critical paths can avoid even those by confining their memory allocation to the stack, something that effectively ceases to exist in GC'd languages.

> but simple malloc/free are much faster and more predictable than what you see in GC'd languages More predictable , very likely. Much faster , this is simply not true. E.g., quotes from an article by Brian Goetz[1]: The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions, whereas the best performing malloc implementations in C require on average between 60 and 100 in…

That writeup is certainly interesting, mostly with regard to escape analysis, but it's entirely untrustworthy with regard to the comparison to malloc. First, it appears to base its assumptions about malloc implementations on a paper dating to 1993 (WTF?!), second is that it thinks "instructions" is a meaningful metric for judging performance.

Re: Why I Don't Want to Learn Go

#120

Post by msutherl »

heretohelp wrote: post #4

I concur with the concurrer and the author with my own more 'positive' addendum: I just want a cleaned/tarted up C. Something that doesn't make the critical mistakes of Go and Obj-C (adding runtime overhead), but adds optional compile and runtime semantics that can be very helpful and powerful. Some ideas: No GC. This is NOT negotiable. I'm tired of belabouring that point. Give me something nicer than the current C b…

I'm curious if anybody has written something equivalent to CoffeeScript for C...
Post reply on HN