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

41–50 of 139 posts

Re: Why I Don't Want to Learn Go

#41

Post by _delirium »

mmisu wrote: post #20
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…

I think clang has a good chance to became as competitive as Go for compilation speed. This way you will have a fast compile/run process and the power of C or C++.

I could believe it for C (tcc is an existence proof for very fast C compilers), but building a C++ compiler of that speed is a pretty difficult task. Separate compilation for templated code is also really hard to get right, since the standard isn't really designed for it and gives few guarantees; if a templated class is changed, determining when you can safely avoid recompiling classes that use it is tough.

Re: Why I Don't Want to Learn Go

#42

Post by muyuu »

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…

I also don't plan to learn Go, but if I have to because it becomes the de-facto standard for some important niche, then I will. This depends massively on the quality of their implementation and also on that of their competition.

Re: Why I Don't Want to Learn Go

#43

Post by scanr »

Why I have learned go:

The overlap between problems that I'd like to solve with node.js and go is pretty large and I prefer being able to use a statically typed language with coroutines and multicore support built in.

The libraries are great for server side programming.

Go optimises for both speed and memory usage. Folk who run benchmarks often seem to ignore the latter but given how the cloud is priced, optimising for memory usage can be a big win.

Go's GC is suboptimal at the moment. That said, I suspect that it'll improve pretty quickly. Go benefits from all those lessons learned during the man centuries spent building the Java GC.

Re: Why I Don't Want to Learn Go

#44

Post by EdiX »

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

> One key feature is that the Go compiler itself is the style guide

Unless something changed in the last six months that's not the case, there is a tool called gofmt that will do the reformatting if you call it.

I'm not really sure I see publishing a style guideline in the form of code rather than english text makes any difference, at least it didn't make it for my go code.

I suspect it has more to do with the fact that some of the developers behind go use acme than anything else.

Re: Why I Don't Want to Learn Go

#45

Post by microtonal »

_delirium wrote: post #41
mmisu wrote: post #20

Earlier quoted context omitted.

I think clang has a good chance to became as competitive as Go for compilation speed. This way you will have a fast compile/run process and the power of C or C++.

I could believe it for C (tcc is an existence proof for very fast C compilers), but building a C++ compiler of that speed is a pretty difficult task. Separate compilation for templated code is also really hard to get right, since the standard isn't really designed for it and gives few guarantees; if a templated class is changed, determining when you can safely avoid recompiling classes that use it is tough.

Definitely. I am anxious to see how much C++11's extern template will improve compilation time, when it will be used by large libraries.

Of course it's still a horrible kludge. But the reality is that C++ exists and is widely used ;).

Re: Why I Don't Want to Learn Go

#46

Post by leoc »

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…

> Aren't most serious languages designed for large code bases?

Well, C is basically designed for Version 6 Unix, the Programmer's Workbench http://en.wikipedia.org/wiki/PWB/UNIX and troff, not a very large code base by today's standards.

Re: Why I Don't Want to Learn Go

#47

Post by drats »

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 tries to be as expressive as Python and run as fast as Java

Why the seemingly almost complete lack of love for Pypy from Google then? It's not like you can stop using Python anytime soon even if you keep extending Go. I believe Google's made one tiny donation to Pypy. Given their benchmarks (http://speed.pypy.org/) and given Google has literally tens of billions in hard cash lying around I can't see how you can't get them some money. A few hundred thousand to Pypy would be justifiable on the performance improvement YouTube would experience alone. Sure the motto is "don't be evil" rather than "do good" but this seems like a no-brainer. Can you give reasons why it's not happening?

Re: Why I Don't Want to Learn Go

#48

Post by berntb »

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…

>>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 on your problems. :-) I decided a long time ago that what I really liked most was to create lots of functionality in as short time as possible. But I admire people that care about things and learn about them relentlessly, so thanks for the information.

Re: Why I Don't Want to Learn Go

#49

Post by leoc »

drats wrote: post #47
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 tries to be as expressive as Python and run as fast as Java Why the seemingly almost complete lack of love for Pypy from Google then? It's not like you can stop using Python anytime soon even if you keep extending Go. I believe Google's made one tiny donation to Pypy. Given their benchmarks ( http://speed.pypy.org/ ) and given Google has literally tens of billions in hard cash lying around I can't see how you can…

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

Re: Why I Don't Want to Learn Go

#50

Post by kibwen »

heretohelp wrote: post #40
masklinn wrote: post #37

Earlier quoted context omitted.

> 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. Yeah that's about what I'd expect considering the language's goals. > 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. Rust has the `unsafe` escape…

Then it might work out fine, I don't know. In general I have to work off of their purported goals and priorities to get a feel for where the final destination of the language will be when it's more complete. If they say they aren't going to prioritize machine semantics, C-level runtime performance, or systems-grade control over code generation then I have assume those priorities will fall wayside to the established p…

Your hunch is correct, Rust's developers have stated that Rust isn't aiming to be a language with which to implement kernels or device drivers.[1]

It's interesting to see that the domain of "systems" programming languages appears to be splitting into "kernel-level" domains and "perfomance-critical application-level" domains. In this light, it seems more like C++ is the one caught straddling the gap. Should be interesting to watch this space for the next decade or so.

[1] https://github.com/mozilla/rust/wiki/Doc-project-FAQ

Post reply on HN