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

61–70 of 139 posts

Re: Why I Don't Want to Learn Go

#61

Post by heretohelp »

berntb wrote: post #48
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…

>>In a single sentence, it's about fundamentally about POWER and not "speed". Most code isn't inner loops in device drivers. My point was that Obj C's behavior should be more or less deterministic, and method calling reasonably fast? So "more or less" is just not good enough for you. [Edit: E.g. cache interaction is too hard to reason about when doing lookup for method dispatch, etc?] Well, I'm too laid back to work…

>I decided a long time ago that what I really liked most was to create lots of functionality in as short time as possible.

That's what I do now, but it's not what I've always done and I'm keenly aware of the limitations my peers are dealing with on a daily basis.

Re: Why I Don't Want to Learn Go

#62

Post by jlouis »

alexchamberlain wrote: post #38
heretohelp wrote: post #8

Earlier quoted context omitted.

Nobody believes GC is a bad idea, it's a canard to suggest otherwise. It's that it's a contradiction of terms to say that you are offering a "systems" language but the language in question has non-optional GC. Go isn't competing with C and C++, it's competing with Java and C#.

I believe GC is a bad idea. Programmers should know what their objects are doing.

You are severely mistaken about GC then. GC means to a large extent that programmers should know what their objects are doing. Perhaps even more so than in a non-GC'ed language.

The inherent problem with GC is when you put it into hands of people without that knowledge. Then the GC will save them and reclaim their data, whereas it would otherwise be a space leak and dead program. This means that you will have programs that work, but they will run slowly. GC-fanatics like me say that the program has bad productivity since it spends all its time in the garbage collector.

The advantage of GC though is this: If you know what you are doing, you don't need to manage memory in about 90% of your program. It is often either good enough or way faster than doing it yourself. Both in raw performance and in programmer time. A hint is that most modern parallelizing malloc routines use garbage collection internally to make them run more concurrently and faster :)

For the last 10%, the solution is the same as in any other language. You allocate large chunks of memory and then you handle that memory yourself. The advantage is that you only have to do this for a small part of your program and that means you can build software much faster.

The only place where GC is provably a bad idea is in hard real time systems.

Re: Why I Don't Want to Learn Go

#63

Post by bh42222 »

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+…

We try to do the same thing for C++, Java, and Python, but it doesn't work as well because the process is manual.

Use http://astyle.sourceforge.net and add it to your build process and/or commit or push/pull hooks of your source control.

(I am surprised I have to give this tip to anyone on HN!)

Re: Why I Don't Want to Learn Go

#64

Post by pjmlp »

jbooth wrote: post #56

The thing with Go is, it's really easy to write your critical path in C and then write the other 95% of the code in Go and not have to deal with crap like null-terminated strings and a lack of built-in data structures. Go has better integration with C than any other language I've seen.

Better than C++ and D? You must be joking.

Re: Why I Don't Want to Learn Go

#65

Post by minimax »

smanek wrote: post #31
stcredzero wrote: post #24

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…

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 here. You end up incorporating some sort of pool based allocator, which I'm sure you can come up with in Go just as you can in C (or Java, or whatever).

Re: Why I Don't Want to Learn Go

#66

Post by dhconnelly »

markokocic wrote: post #57
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. If Go is really designed for large code bases, then IDE support for go with code browsing, refactoring, debugging and profiling would be developed in parallel with the Go language itself. Since Go IDE support go only as far as petty Vim and even pettier Emacs modes, I couldn't call go "made for l…

http://code.google.com/p/goclipse/

Re: Why I Don't Want to Learn Go

#67

Post by jbooth »

pjmlp wrote: post #64
jbooth wrote: post #56

The thing with Go is, it's really easy to write your critical path in C and then write the other 95% of the code in Go and not have to deal with crap like null-terminated strings and a lack of built-in data structures. Go has better integration with C than any other language I've seen.

Better than C++ and D? You must be joking.

Ok, not better than C++ and I haven't used D. I should've said "other mid-to-high-level langauge". But using C++ doesn't solve my complaints about the clunkiness of the non-critical path stuff. Still have wacky string handling and I'd rather write my own bintree or hashmap than have to use STL.

Re: Why I Don't Want to Learn Go

#68

Post by dripton »

jacquesm wrote: post #36
batista wrote: post #22

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://…

You could compare python with perl or php, you could compare Go with C, C++ or Java. But to compare Go to Python is a bit weird. Of course, you could do it, but why would you, almost every metric that you'd want to use would be off. You're comparing a compiled language with lightweight threads aimed at just-above-low-level programming backed by a single vendor with an interpreted language that is mostly geared toward…

I think it's fine to compare Go and Python. They're both general-purpose programming languages. When choosing to write a new program, you can often pick either of them. I can imagine problems where either might be a reasonable choice. In fact, there are programs that I've written in both. (Granted, those were Project Euler exercises, not code that someone was paying me to write.)

Don't get too caught up in the marketing.

Re: Why I Don't Want to Learn Go

#69

Post by dhconnelly »

I understand and recognize as valid all of the author's concerns. I am personally using Go for things that I used to do in Java. I recognize that this may not be realistic for people heavily invested in the JVM, but I'm finding development with Go to be much more enjoyable than Java.

Re: Why I Don't Want to Learn Go

#70

Post by dhconnelly »

batista wrote: post #22

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://…

http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
Post reply on HN