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

21–30 of 139 posts

Re: Why I Don't Want to Learn Go

#21

Post by wisty »

microtonal wrote: post #16
jrockway wrote: post #7

Go is designed for large codebases, which is a problem that the author may not have, and so he may not see the benefits. One key feature is that the Go compiler itself is the style guide: it automatically reformats your code to remove style guide violations. This makes it easy to work on a codebase the size of Google's because everything looks like it was written by the same person. We try to do the same thing for C+…

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…

SQL isn't, and if it's not a serious language, what is? Perl and PHP are what the web app layer was originally built on, and they seem to be designed to maximize developer efficiency for small projects.

Haskell is definitely interesting. If I wanted to build a large system that was super-performant, I'd look at C, Haskell, and Go. I don't know enough to make a great decision, but all three look good.

Go has the advantage of being designed for the kind of thing Google does - massive concurrency. It's also like C, which make it easier to find good programmers who are confortable with it. Actually, you'd be hard pressed to find good programmers who are uncomfortable with a language that's nearly C. I'm not saying Haskell programmers aren't good programmers, but Google probably doesn't have enough of them, and they'd have to port their existing code to a completely different base (bad idea).

The original article complains about Go's GC. For a single process application, this could be murder. I don't think Google uses a single process.

Re: Why I Don't Want to Learn Go

#22

Post by batista »

For all the talk of the speed benefits of Go, and it being static et all, I don't see much improvement over, say, Python.

A lot of the questions re speed bumps on the mailing list are answered with "those are microbenchmarks, what matters is real cases" and generally a "lalala hands in the ears approach", even when it's obvious that the problem is deeper than some microbenchmark only case.

Like this example:

https://groups.google.com/forum/?fromgroups#!topic/golang-nu...

[Downvote? Something very controversial about hashmap O behavior?]

Re: Why I Don't Want to Learn Go

#23

Post by batista »

heretohelp wrote: post #11
berntb wrote: post #9

Earlier quoted context omitted.

>>No GC. Interesting that you disqualify Objective C? It use reference counting which should have a more predictable memory handling behaviour. Or is the dynamic stuff too much overhead for you? To me, it looks cheap (but I'm a scripter since quite a few years). (Not knowledgeable on this; I'm asking, not making an argument.)

It seems most people don't really understand the core of systems programming. Let me try to summarize: There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave. Period. No ifs-ands-or-buts about it. This means you must be able to define memory layout, management, instruction behavior and semantics, and optimally, be able to predict cache locality (arrays v…

It seems most people don't really understand the core of systems programming. Let me try to summarize: There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave. Period. No ifs-ands-or-buts about it.

Actually it seems you don't understand that people mean different thing by "system's programming".

Not all system programming is about no-compromise, i.e as it would if it was only about driver or OS coding.

I'd trust Ken Thompson and Rob Pike to understand what system programming is better than some random dude on HN.

Re: Why I Don't Want to Learn Go

#24

Post by stcredzero »

And before you tell me that the GC isn't that big a deal: it is. Literally every big project I've worked on in a garbage collected language reserves a bunch of memory off-heap at startup and uses that for allocations on the critical path because the GC kills performance.

You could replace occurrences of GC with malloc, switch the language to C, and it would be just as factual. Basically, what the author is saying is equivalent to, "Real projects have to optimize." Well, yes. This isn't deep. It certainly isn't surprising, and it doesn't strike me as a good reason for not learning a language.

Re: Why I Don't Want to Learn Go

#25

Post by zoul »

cageface wrote: post #13
berntb wrote: post #9

Earlier quoted context omitted.

>>No GC. Interesting that you disqualify Objective C? It use reference counting which should have a more predictable memory handling behaviour. Or is the dynamic stuff too much overhead for you? To me, it looks cheap (but I'm a scripter since quite a few years). (Not knowledgeable on this; I'm asking, not making an argument.)

Objective C message passing is much, much faster than function dispatch in a typical scripting language but still too slow for inner loops. C++ virtual functions and, of course, inlined C/C++ functions are much faster.

Obligatory link benchmarking various Objective-C operations:

http://www.mikeash.com/pyblog/performance-comparisons-of-com...

Re: Why I Don't Want to Learn Go

#26

Post by heretohelp »

batista wrote: post #23
heretohelp wrote: post #11

Earlier quoted context omitted.

It seems most people don't really understand the core of systems programming. Let me try to summarize: There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave. Period. No ifs-ands-or-buts about it. This means you must be able to define memory layout, management, instruction behavior and semantics, and optimally, be able to predict cache locality (arrays v…

It seems most people don't really understand the core of systems programming. Let me try to summarize: There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave. Period. No ifs-ands-or-buts about it. Actually it seems you don't understand that people mean different thing by "system's programming". Not all system programming is about no-compromise, i.e as it…

>I'd trust Ken Thompson and Rob Pike to understand what system programming is better than some random dude on HN.

You'd be surprised, Pike has more or less retracted the "systems" moniker due to the reaction it got. He avoids the term now as a result.

I know this because I've been watching Go itself very closely.

But hey, it's just Rob Pike. Maybe ken still calls it a "systems" language. I'm still just a random dude on HN who thought plan9 was a fantastic idea and keeps track of Pike's work as a result :)

Re: Why I Don't Want to Learn Go

#27

Post by stcredzero »

zoul wrote: post #12

As for the GC speed, how do GC and manual memory management compare to the Automatic Reference Counting system that was introduced recently into Objective-C? It looks to me as ARC has the advantages of both worlds: it relieves the programmer from managing memory by hand and has no overhead, as the decisions are made during compilation. I'm a bit frustrated each time people talk about GC and manual memory management a…

Check out iGC. The claim is, by tailoring GC to the ObjC runtime in iOS, you can beat ARC's performance with GC. (Look at how ObjC allocates heap and use read/write barriers to reduce the number of roots that have to be traced.)

Re: Why I Don't Want to Learn Go

#28

Post by groovy2shoes »

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…

Have you had a look at Clay? http://claylabs.com/clay/

Re: Why I Don't Want to Learn Go

#29

Post by microtonal »

wisty wrote: post #21
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…

SQL isn't, and if it's not a serious language, what is? Perl and PHP are what the web app layer was originally built on, and they seem to be designed to maximize developer efficiency for small projects. Haskell is definitely interesting. If I wanted to build a large system that was super-performant, I'd look at C, Haskell, and Go. I don't know enough to make a great decision, but all three look good. Go has the advan…

SQL isn't, and if it's not a serious language, what is? Perl and PHP are what the web app layer was originally built on, and they seem to be designed to maximize developer efficiency for small projects.

I intentionally said most, since, obviously there are serious domain-specific languages. But stating that Go is designed for large code bases, creates a false dichotomy.

Go has the advantage of being designed for the kind of thing Google does - massive concurrency.

So, claims the C fan since there's GCD, so claims the Erlang/Scala fan since it has actors, so claims the Haskell fan since it has green threads, STM, and purity.

Also, is Google interested in massive concurrency or parallelism?

It's also like C, which make it easier to find good programmers who are confortable with it. Actually, you'd be hard pressed to find good programmers who are uncomfortable with a language that's nearly C.

That's a good point. But as a result it provides only a marginally better type system, at the cost of performance compared to C. Why not make it a lot better than C, with the same performance?

Re: Why I Don't Want to Learn Go

#30

Post by heretohelp »

masklinn wrote: post #19
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…

Wasn't bitc trying to do some of that stuff? An other option you might want to look into is Rust[0], especially since the language is still in its early days (0.1) and the developers are more than willing to fix things which don't work. * It does not have bit fields or bounds-checked arrays (which it calls vectors) at this point I think * A bit of GC: it has a reference-counted pointer type, which is task-local, whic…

Been following Rust and bitc. I'll leave bitc alone and instead comment on Rust:

Rust gets a lot closer than Go, but is still straddling this awkward territory between C and Java.

I would imagine that Rust would be fantastic for implementing a database or a web browser or anything else equally complexity-management and performance driven. The concurrency and safety semantics seem to make that case even stronger for making it an excellent language for a database.

The non-optional runtime overhead that I have to imagine is endemic to the purported feature-set would seem to be a non-starter for systems (kernel, driver, embedded) programming.

Safety is one thing, mandatory safety means a mandatory runtime overhead with a mandatory reduction in control and power over the code which is unacceptable.

Post reply on HN