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

11–20 of 139 posts

Re: Why I Don't Want to Learn Go

#11

Post by heretohelp »

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

>>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 vs. linked-lists are the trivial but canonical example)

The moment the programming language, at any fundamental level, precludes me from defining how the machine should behave with respect to memory, semantics, or otherwise...it ceases to be a language that can be used for systems programming.

Disintermediating the meddling of C compilers is hard enough, languages like Go and Java are 'intractable' to say the least for actual systems programming.

Obj-C is only acceptable in the context of systems programming when you stop using everything that makes it Obj-C and just write C code.

I outlined additions/improvements that could be made to C and utilized in the context of systems (rather than applications) programming.

In a single sentence, it's about fundamentally about POWER and not "speed". That's why the desert-island language is C.

Re: Why I Don't Want to Learn Go

#12

Post by zoul »

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 and act like they were the only options available.

Re: Why I Don't Want to Learn Go

#13

Post by cageface »

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

>>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.

Re: Why I Don't Want to Learn Go

#14

Post by cageface »

heretohelp wrote: post #8
jgrahamc wrote: post #6

This is addressed on the Go FAQ: http://tip.golang.org/doc/go_faq.html#garbage_collection The authors believe that they can make GC a low overhead operation in Go and they believe that it's essential to take memory management out of the hands of the programmer to save programmer effort. Lastly, they say that should you need to you can always work around the GC by doing your own memory management (linked example). It…

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#.

Go isn't competing with C and C++, it's competing with Java and C#.

This is exactly why I'm taking a wait & see approach. If it gains enough momentum to develop the kind of tool & library ecosystem Java & C# enjoy I'll learn it but I've wasted enough time chasing dark horse language contenders already.

Re: Why I Don't Want to Learn Go

#15

Post by heretohelp »

cageface wrote: post #14
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#.

Go isn't competing with C and C++, it's competing with Java and C#. This is exactly why I'm taking a wait & see approach. If it gains enough momentum to develop the kind of tool & library ecosystem Java & C# enjoy I'll learn it but I've wasted enough time chasing dark horse language contenders already.

>This is exactly why I'm taking a wait & see approach. If it gains enough momentum to develop the kind of tool & library ecosystem Java & C# enjoy I'll learn it but I've wasted enough time chasing dark horse language contenders already.

I don't even have to do that. In my world, I'm free to oscillate between C and Python, depending on the problem being solved. Bonus: One can call the other.

I have no need for mid-tier corporate languages like Java and C# anymore. Go can be a "better" mid-tier language all it wants, I still won't learn it because it doesn't do anything better than Python or C currently do.

I actively avoid using or creating codebases so grossly-huge that you need the "bug-avoidance" and performance of something like Java and C# to the point where Python is no longer practicable.

When you need more "performance" because your codebase is too fat, you've got a bigger problem that can't be solved with a faster runtime.

But what do I know? I'm just a startup kid who ran screaming from the .NET ecosystem.

Re: Why I Don't Want to Learn Go

#16

Post by microtonal »

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 for C code and slowly makes editors and IDEs more effective.

Anyway, don't take this to mean that you're doing software wrong if you don't see the value of Go.

I fully agree with the author, on the one hand Go does not provide the performance of C or C++, on the other hand it nearly no useful new abstractions to manage complexity. Languages such as Haskell, OCaml, F# or even D provide a better type system and have similar or better performance.

Google is a special case

Out of curiosity: how much is Go used in Google? What percentage of new projects use Go compared to e.g. Java or C++?

Re: Why I Don't Want to Learn Go

#17

Post by cageface »

heretohelp wrote: post #15
cageface wrote: post #14

Earlier quoted context omitted.

Go isn't competing with C and C++, it's competing with Java and C#. This is exactly why I'm taking a wait & see approach. If it gains enough momentum to develop the kind of tool & library ecosystem Java & C# enjoy I'll learn it but I've wasted enough time chasing dark horse language contenders already.

>This is exactly why I'm taking a wait & see approach. If it gains enough momentum to develop the kind of tool & library ecosystem Java & C# enjoy I'll learn it but I've wasted enough time chasing dark horse language contenders already. I don't even have to do that. In my world, I'm free to oscillate between C and Python, depending on the problem being solved. Bonus: One can call the other. I have no need for mid-tie…

It's hard to love Java as a language but I'll still sometimes reach for it over Ruby or Python or C because it's not that much more verbose and it can get within 4x or so of C++ code without even trying.

And often the large codebase finds you, no matter how hard you try to avoid it, and there you start to appreciate some of the design decisions of Java.

Re: Why I Don't Want to Learn Go

#18

Post by heretohelp »

cageface wrote: post #17
heretohelp wrote: post #15

Earlier quoted context omitted.

>This is exactly why I'm taking a wait & see approach. If it gains enough momentum to develop the kind of tool & library ecosystem Java & C# enjoy I'll learn it but I've wasted enough time chasing dark horse language contenders already. I don't even have to do that. In my world, I'm free to oscillate between C and Python, depending on the problem being solved. Bonus: One can call the other. I have no need for mid-tie…

It's hard to love Java as a language but I'll still sometimes reach for it over Ruby or Python or C because it's not that much more verbose and it can get within 4x or so of C++ code without even trying. And often the large codebase finds you, no matter how hard you try to avoid it, and there you start to appreciate some of the design decisions of Java.

I don't deny it has its place for some people, but it's definitely not my experience that

>Ruby or Python or C because it's not that much more verbose

I've seen some shocking differences in LOC and comprehensibility between Ruby/Python vs. Java code, even when a concerted effort has been made to avoid the typical sins of Java codebases.

You might just be more patient than I am, or a better Java programmer. I don't know. All I know is that I end up experiencing kidney failure every time I have to interact with Java code.

Re: Why I Don't Want to Learn Go

#19

Post by masklinn »

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, which might be possible not to use at all (not sure) if you don't want it. It also has unique pointers (reclaimed when they vanish out of use) and stack allocation.

* HoF, unicode-native strings (although they're char vectors so maybe not ideal), pointers cleanups (and more than one pointer type which you may or may not agree with), "tasks" ("green processes"), absolutely trivial C interop (so you should be able to easily use pthreads I think), structurally typed records, tuple types, lots of pattern-matching love (for dispatching and unpacking), explicit mutability marker

[0] http://www.rust-lang.org/

Re: Why I Don't Want to Learn Go

#20

Post by mmisu »

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…

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++.
Post reply on HN