Why I Don't Want to Learn Go

http://arantaday.com/why-i-dont-want-to-learn-go

by dwwoelfel • 14 years ago

212 137 14 years ago

reirob• 14 years ago

Thanks for the link! The author expresses exactly my thoughts.

In essence: Go is not a system-level language (GC) and for problems where performance does not hurt so much there are other alternatives.

To add my personal opinion: I would not consider Go for another reason - I will not invest in a language that is backed by one company. I did this once with Java and I will not hurt myself again. Java's start was fantastic but then came all the business crap like EJBs and tons of frameworks.

babarock• 14 years ago

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 shortcoming, than maybe they should come up with a more technical analysis, or at least some sort of benchmarking.

smanek3• 14 years ago

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 examples to that effect.

If you want benchmarks, check out the numbers from moving some of the critical allocations off heap (and out of the GCs reign) in the Java HBase project: http://www.slideshare.net/cloudera/hbase-hug-presentation

flogic• 14 years ago

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

axiak• 14 years ago

My understanding is that go still provides a lot of tools to indicate when you want memory allocated and where the memory will go (which can optionally be left out). If these were used, wouldn't that make it easier for the go gc to perform better?

pjscott2• 14 years ago

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.

heretohelp13• 14 years ago

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

Bounds-checked arrays...optionally. Make the distinction very obvious in the code/type-signature.

Higher-order functions, optionally. I don't really want an object system, just the ability to utilize callbacks in perhaps a nicer way than how function pointers currently function. I'd actually be happy with a standardized syntax sugar for function pointers.

Compile-time (only!) duck-typing and polymorphism. This part I think Go got right, but its sins were too great and the problem it was solving too poorly defined to make up for this.

Unicode-native from the ground up.

Clean up the string/array/pointer conflation, adopt the semantics of the bstring library as the default string type for the language, but leave open the door for 'raw-er' string implementations.

Don't reify language types without enabling people to implement their own data structures at the nitty-gritty level.

Cross-OS green-threads might be nice. Let people define their own concurrency models and semantics on top of what the language provides by default though. Same problem as the language type reification, don't delude yourself into thinking you've solved the world's problems with your subset of solutions. Let people use things like ptrheads without punishing them for doing so.

But most profoundly of all:

Make a language that would make writing a library like libev or libevent less bug-ridden and a lot more fun.

P.S. I sincerely hope someone writes a "pragmatist's" systems language like this.

berntb2• 14 years ago

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

heretohelp13• 14 years ago

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.

cageface3• 14 years ago

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.

anamax3• 14 years ago

> It use reference counting which should have a more predictable memory handling behaviour.

Correct reference counting in multi-threaded code running on a multi-core machine adds significant cost to a simple pointer copy (aka "add reference").

masklinn2• 14 years ago

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/

heretohelp13• 14 years ago

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.

pcwalton2• 14 years ago

We're working on improvements to the language (namely, regions and dynamic arenas) to make it possible to not use the reference-counted pointer type at all if you don't want it, while retaining the type safety. Regions have their own set of costs, as we're finding out (mostly due to the annotation burden if you start doing complicated stuff), but I think we'll be in a nice sweet spot. Rust gives you three basic options:

(1) Regions, when you want safe, low-overhead allocation. The downside is a more complex type system. (Usually you don't see the complexity unless you're returning pointers that contain references to the stack, at which point you have to convince the typechecker that you aren't creating dangling pointers by doing so.)

(2) Safe, garbage collected heap allocation. This gives you maximum flexibility at the cost of runtime overhead.

(3) Unsafe pointers. This lets you manage your memory manually, like C++. Of course, this is unsafe.

Also, I suspect we're going to add fixed-length vectors; we've been discussing this quite a bit lately and I think there's general consensus that they should be present in the language in some form.

groovy2shoes2• 14 years ago

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

heretohelp13• 14 years ago

It's the most promising out of the current cohort that includes Rust, I'll say that much.

Clay seems to understand that you cannot compromise.

msutherl• 14 years ago

I'm curious if anybody has written something equivalent to CoffeeScript for C...

andolanra• 14 years ago

Something that provides syntactic sugar that compiles down to C? You'd be looking for Vala[1]. I haven't used it so I can't vouch for it in practice, but I know it compiles to C and uses the GObject system for object-oriented programming. It's not as much of a syntax change for C, but it apparently adds quite a bit semantically. There's also a Scheme implementation called Chicken[2] that compiles to C source, and I know there are others that I'm not recalling off the top of my head.

[1] https://en.wikipedia.org/wiki/Vala_%28programming_language%2... [2]: https://en.wikipedia.org/wiki/Chicken_%28Scheme_implementati...

losvedir• 14 years ago

As I understand it, this fellow named Bjarne Stroustrup did once. Of course, the project eventually grew beyond its humble beginnings...

jgrahamc• 14 years ago

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 feels like they are trying to honor Hoare's "premature optimization is the root of all evil" by considering non-GC languages to have optimized the wrong thing.

heretohelp13• 14 years ago

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

cageface3• 14 years ago

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.

alexchamberlain• 14 years ago

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

jrockway• 14 years ago

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++, Java, and Python, but it doesn't work as well because the process is manual.

Similarly, compilation time and runtime for every component, no matter how unimportant, is of utmost importance for Google's codebase. It may not matter how long it takes to run one one-off script, and it may not matter to you how long it takes to compile, but it does matter at Google because we compile every project and run every test after every commit. (OK, builds and tests that are obviously unaffected are skipped. But it's still a lot of code being built and tested.) So your Python project that takes 5 seconds to run tests instead of 1 second ends up wasting decades of CPU time throughout its life time. Same for C++ projects that take many hours to compile. Go tries to be as expressive as Python and run as fast as Java (and compile faster than anything else), and this saves lots of time in aggregate. (Remember, when you break someone's build, the delay between submitting your change and the system knowing about the breakage can result in a lot of hair-pulling for the developers on the project you broke. But if we can know the build is broken before the change is even submitted, then many hours of developer productivity are saved.)

Anyway, don't take this to mean that you're doing software wrong if you don't see the value of Go. Google is a special case and just because we have some problem doesn't mean you should have the same problems. One-man shops should optimize for individual efficiency instead of aggregate efficiency like Google does.

smanek3• 14 years ago

That's fair - the largest code bases I've ever worked on are all less than ~200K LOC.

They've enforced style by mandating committers hook a linter into a git pre-commit hook, and compilation time hasn't been a huge problem since the languages always support incremental/partial compilation (Java/Lisp for the most part).

I can imagine that not working at Google-scale.

adgar3• 14 years ago

> They've enforced style by mandating committers hook a linter into a git pre-commit hook

Style-related presubmit hooks are a part of every project at Google. Plus readability requirements, etc - style is kept pretty damn consistent.

> compilation time hasn't been a huge problem since the languages always support incremental/partial compilation (Java/Lisp for the most part).

This is the far more interesting problem to solve at scale with a single centralized repository.

microtonal3• 14 years ago

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

mmisu• 14 years ago

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

wisty2• 14 years ago

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.

zoul3• 14 years ago

> 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 interesting discussion about the way these companies use their versioning systems:

https://news.ycombinator.com/item?id=3548824

Some of the practices (like keeping their whole codebase in one big repository) look quite questionable, if not downright stupid from a smaller viewpoint, but make sense in their case. Go could be a similar thing – most serious languages are designed with good modularization, encapsulation and other features that support large scale code bases as most of us know them, but that does not mean these languages are a great match for software at the Google scale.

leoc3• 14 years ago

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

EdiX• 14 years ago

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

drats2• 14 years ago

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

leoc3• 14 years ago

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

stdbrouw• 14 years ago

(1) Google spent lots of developer resources on Unladen Swallow, which ended up not giving the speed increases they expected, but that's another story.

(2) Last thing I heard, Google's trying to minimize their Python usage in favor of Java.

reitzensteinm• 14 years ago

PyPy's memory usage up until now has been quite a bit higher, which makes it unsuitable for some server workloads.

Still, I assume this is fixable, and it's getting more and more competitive in terms of the megabyte-second cost of computation (i.e. if you use twice as much memory but run four times as fast, that can be OK depending on the circumstances).

markokocic• 14 years ago

> 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 large codebases".

dhconnelly3• 14 years ago

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

bh42222• 14 years ago

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!)

anamax3• 14 years ago

> We try [to make all code look like it was written by the same person] for C++, Java, and Python, but it doesn't work as well because the process is manual.

However, Python, because space is significant, tends to look fairly similar "in the wild". Add minimum adherence to a style guide and you're pretty close to that goal.

zoul3• 14 years ago

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.

stcredzero4• 14 years ago

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

batista3• 14 years ago

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?]

jacquesm3• 14 years ago

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 towards single threads of execution with a very high level of expressiveness that is developed by a bunch of open source gurus under the supervision of a benevolent dictator.

dripton• 14 years ago

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.

pjmlp5• 14 years ago

For the type of applications people have been writing in Go, Python + PyPy would equally do as well.

batista3• 14 years ago

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 towards single threads of execution with a very high level of expressiveness that is developed by a bunch of open source gurus under the supervision of a benevolent dictator.

The development model (benevolent dictator/backing company) does not have anything to do with the comparison. The license is also orthogonal. Not sure why you are adding those to the table.

The comparison I made is all about runtime behavior re: speed/memory usage here.

And, what I am saying is that despite Go being static and compiled and touted as "very fast", it's slower in a lot of respects to EVEN plain old Python, not to mention Java, which runs circles around it.

I'm not saying one would/should use Python and Go for the same tasks (though many people do, seeings as Go feels a little like a dynamic scripting language thanks to the easy syntax and the nice type system).

I'm saying "Hey, isn't the basic reason for someone to use Go over something like, say, Python, that it's supposed to be faster and with better memory handling? How does that play in practice?".

dhconnelly3• 14 years ago

http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

Scaevolus• 14 years ago

The conclusion of that thread was that his Python benchmark was accessing the hashmap's entries in sequential order (due to python's hash function being intentionally non-random), while the Go benchmark was accessing keys at random (since its hash function is random) and trashing the cache.

stcredzero4• 14 years ago

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.

smanek3• 14 years ago

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 a niche, it's got to be at a 'higher-level.' And that requires competing more directly against Java or Python - a much higher bar than trying to be better than C.

minimax• 14 years ago

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

scanr• 14 years ago

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.

Roybatty• 14 years ago

The title is wrong. It should be "Why I Don't Want to Learn Go and You Shouldn't Either"

jbooth3• 14 years ago

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.

pjmlp5• 14 years ago

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

jbooth3• 14 years ago

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.

dhconnelly3• 14 years ago

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.

zvrba• 14 years ago

In light of C++11, I see Go as something rather obsolete. I see absolutely no reason why I should spend my time on a language that's different just for the sake of it, instead of studying new features of C++.

fauigerzigerk• 14 years ago

Where Go fits in seems very clear to me. It is a less memory hungry and less verbose replacement for Java, fit for the age of fine grained parallelism.

Go will never replace C/C++ for embedded systems and operating systems. Go will never replace JavaScript in the browser. And Go will never replace Haskell, Lisp, ML, Scheme, etc, for those who have a very deep interest in programming languages themselves.

digamber_kamat• 14 years ago

I think a large portion of online life is already ruled by Google. I will never use Go only because it comes from Google. A mobile with Google's OS, a Google browser and Google for email and now we will also code in a language controlled by Google?

I have nothing against Google, but as a community of web developers our interest lies in diversifying and ensuring that no one gets more powerful than us.

Also looking at the features of Go itself, it seems to me that the languages caters to many needs of Google and not many of us may have those needs.

jff• 14 years ago

I don't like giving over my life to Google either, but there's a big difference between using Gmail for everything and writing programs in Go. Go is an open source project. You can fork it right now if you want, call it Not-Evil-Go or whatever, and BAM it's no longer controlled by Google. They can never make it just up and disappear, the worst they could manage is to do like Oracle did with OpenSolaris and force the community to fork it.

phatbyte• 14 years ago

I wonder why aren't they using something like ARC in ObjC instead of GC ?

webjprgm• 14 years ago

Why can't someone make a language where you can optionally use GC on one chunk of memory and use automated reference counting on another chunk? Tell the compiler which variables should be in which category, and then most of the quick programming is done in GC while all the stuff that needs to be performant will be in reference counting but automatically managed so you shouldn't have to know outside of the one keyword to flag the variable and occasionally breaking a cycle when you want to free a structure (or using weak references like Obj-C allows).

jamesgeck0• 14 years ago

I'm not very familiar with it, but doesn't C# or the CLR let you do something like this with managed and unmanaged code?

pjmlp5• 14 years ago

Modula-3, Ada, Oberon are just a few of such languages.

breckinloggins• 14 years ago

I agree with the GC point. If I'm using a low-level language, my litmus test is "could I write an OS Kernel in it".

I have a naive question: could GC in Go be replaced with something like Apple's Automatic Reference Counting (ARC)? It could be an optional feature backed by inserting real alloc(), retain(), release(), and destroy() calls, so you'd still have full control if you wanted to turn it off.

drucken• 14 years ago

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.

Why I Don't Want to Learn Go

Related Stories