[wwweston]

OK, I'll admit it. I've spent six months with Go. I keep waiting for the moment when I understand it, maybe even develop some enthusiasm for it, and reach Pike-enlightenment.

And I pretty much hate the language. I feel like I'm writing in something that combines the worst weaknesses of Pascal and Java. In fact, Mark Dominus' comments about Java (http://blog.plover.com/prog/Java.html ) approximate my experience Go far better than I would have guessed when I started the project I'm on.

People who seem to be smart nevertheless keep talking it up... some not even as just a good tool but as their favorite language.

So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)?

[MetaCosm]

Composition. That is the single biggest thing that has impressed me as my codebase has grown. Concurrency and messaging is nice, but I come from Erlang... I am not easily impressed by concurrency and messaging. Composition, the power of interfaces in complex systems is the key for me. It is what makes me stay with Go, and why I will probably stick around for a long time. It is so obnoxiously useful, without ever getting in my way. Let's talk for a second about the tiny little function

io.Copy(dst io.Writer, src io.Reader)

It reads data from reader and writes to writer... simple. Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). The first way you will probably use it will be to copy between some stream and a file without having to eat up all the memory to store the buffer (not using ioutil.ReadAll for example)... but then you realize you can use a gzip compressor on the writer side, or a network socket, or your own code... and io.Copy works with anything that fulfills its interface.

As you build out a complex application, you start by creating your own functions that take advantage of existing interfaces foo.OCR(dst io.Writer, src img.Image). After that you start building out your own interfaces... like a MultiImage interface that has ImageCount and ReadImage methods that returns the count of images and binary data... but then you realize the images could be big, so you make the ReadImage method return an io.Reader... and now you have gone full circle and are using io.Copy to copy imageX from a stack of images to return to your OCR function that will output the data to an io.Writer which you made actually a gzip writer because text compresses well.

Beyond composition -- obviously, the concurrency and messaging is nice and when you need it vital. The other thing that will help make Go "click" is being very "data oriented" in your design... be vicious and minimal: http://youtu.be/rX0ItVEVjHc (great talk on data oriented design) and be absolutely pragmatic, focus on getting shit done, always...

[coldtea]

>It reads data from reader and writes to writer... simple. Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). The first way you will probably use it will be to copy between some stream and a file without having to eat up all the memory to store the buffer (not using ioutil.ReadAll for example)... but then you realize you can use a gzip compressor on the writer side, or a network socket, or your own code... and io.Copy works with anything that fulfills its interface

And how is that any different than any language with interfaces? (Besides the implicit thing?).

[arnehormann]

Because of the implicit thing! The api designer doesn't have to write the interface, you can do it yourself. As long as naming conventions are kept to and the signature matches, you can apply this anywhere.

Imagine a close() interface in Java. There isn't one - but having a try {...} finally { x.close(); } can be very useful sometimes. But having interface graphs made of granular interfaces makes everything slow and causes a lot of complexity when you try to think about your type hierarchy. That's why interfaces always just grow and you can't use them any longer because other classes only implement part of the api. Something usable for all of awt, swing, file handling, random foreign libraries? Unthinkable. Also, adding something in a later release (like CharSequence in 1.4) can have a wide ranging impact and requires you to change a lot of code.

In Go, you just add an interface from the union set of multiple structs api - and you can use it. No matter who wrote those structs. The value is enormous. Think of it as something like dependency injection at compile time.

[mschulze]

>Imagine a close() interface in Java. There isn't one

https://docs.oracle.com/javase/7/docs/api/java/lang/AutoClos...

You can even leave out the finally when you use an autocloseable resource.

    //r will be closed no matter what
    try(Resource r = getResource()) {

    } catch(SomeException e) {

    }

[arnehormann]

My Java is getting rusty... I read about this sometime somewhere but forgot it, thanks! I should have picked something like "String getText()", then.

[pjmlp]

> Because of the implicit thing!

Known as structural typing and available in most modern languages.

[icebraining]

available in most modern languages

Well, "modern" is an ill-defined concept. As far as I'm aware, structural typing is not really that common, is it? Besides OCaml and Scala, is there any relevant (used outside of academia) language that supports it?

[pjmlp]

D and C++ templates for example.

F# also supports it, given its ML linage.

C# tricks with dynamic, although in this case it is dynamic typing, so not really the same thing.

[losvedir]

Would rust's "traits" count as structural typing? (I know Rust may not count as "relevant (used outside of academia)" yet, but maybe in the future.)

[tel]

Haskell's typeclass provide it.

[raverbashing]

Like duck typing?

[LBarret]

I suspect this is like duck typing with some verification before compilation : the compiler checks that the object sent as parameter implements the correct interface.

[diroussel]

It's called structural typing.

[_pmf_]

> Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader).

I've implemented InputStreams from byzantine transport layers in Java that work with the standard library. I don't quite understand what is special about this concept in Go (maybe it's nice for people coming from typeless, messy dynamic languages or nice languages with horribly inflexible and ad-hoc standard libraries like Python and Ruby).

[MetaCosm]

Go has nothing unique (and maybe that makes it special). I mean that sincerely, everything it has, has been done dozens of times. Interfaces in Go are implicit (which is important, IMHO) and really, tremendously simple. These two features make them exceptional easy to use, and ACTUALLY used.

I have used interfaces (or equivalent concepts) in dozens of languages and they always felt like far more of a chore, explicitly using X interface or Y interface, ugly complex declarative specs, etc. Go just makes it painless.

[LBarret]

replace Go with Python in the text, and you won't see a difference: there are iterable, keyable, file-like interfaces, etc. And creating your own is trivial.

[icebraining]

Yes, but Python doesn't compile to a single binary, and usually runs much slower.

What people like about Go is its mix of features, not some specific one by itself.

[pjmlp]

Depends on the implementation.

[cma]

Python doesn't verify the interface is met until run time.

[coldtea]

With all the cases were Go pushes you to use interface{} that's the case in Go a lot of the time too.

If it had Generics that would be another thing.

[jesstaa]

You can make an io.Reader interface in any language. Interfaces don't really shine until you start composing them.

Say you have a type that implements the io.Reader, io.Writer, io.Closer and io.Seeker interfaces, eg. an os.File. This type would also automatically implement io.ReadCloser, io.WriteCloser, io.ReadWriter and io.ReadWriteCloser, io.ReadSeeker, io.ReadWriteSeeker, io.ReadWriteSeekerCloser, io.WriteSeeker, io.SeekCloser etc.

[MetaCosm]

Yeah, I simply think that this is hard to explain in a comment how useful and easy it is. But, I gave it my best Go...

[stinos]

Composition

I read your comment, but this seems more like A sane standard library with proper interfaces and not a language feature per se (also composition to me sounds like the pattern where you create objects which are composed of other objects but that's not what you mean, right)? What you display here can be done in pretty much any language suporting inheritance (or I'm missing something), so your point is those languages don't have io.Copy out of the box?

[Svip]

I think the point here is implicit inheritance. There are many interfaces in Go, but you don't need to specify which interface you are implementing. So you can easily implement io.Reader and io.Writer among many others, without extending your type declaration for lines on end.

This means that many standard types in Go implements either io.Reader and/or io.Writer. That's neat. The implicit interface implementation is definitely a language feature, and the libraries are making good use of it.

(That is not to say, you could not do the same in other languages, but you would have to specify the interface they implement rather than just adding a method with a specific layout.[0])

[0] I am not remembering the right term right now.

[mike_hearn]

I suspect you will come to hate this feature. Just because an class happens to have a method called close() does not mean it works the same way as another class that also has a close method. An interface is much deeper than the prototypes of its methods, and pretending you can pattern match an API to whatever names a code author happened to pick is likely to lead to pain eventually ...

[latch]

The very point of an interface is to decouple the caller from all the implementation specifically because it will work differently between implementation. If you expect two classes to implement it the same way, you an abstract base, not an interface.

Close is a particularly good example. One need only look at C#'s IDisposable to see that it does, in fact, work well. A mock might noop it, another class might close an FD, and yet another might make an RPC call.

I agree that interfaces tend to have fairly narrow family tree. And, by this narrowness, there's little ambiguity about what T GetById(id int) means. As the tree expands, which happens with implicit interfaces, ambiguity is more likely. Nevertheless, there's a fairly large common vocabulary that we'd all largely agree on. Closer, Reader, Writer, Logger, etc. Even in more complex ones, I see little risk of confusion, say, http.ResponseWriter. And, something that I've noticed from Go (which I never did in C# or Java), is the tendency to favor very small interfaces, which ends up being pretty awesome.

That aside, consider that implicit interfaces allow the consumer to define the interface. For example, you create a library that has a concrete struct called MyStruct with a method called DoStuff(). You define no interface because you don't need one.

I, a consumer of your library, need an interface because in some cases I'm using your MyStruct to DoStuff and in other cases, I'm using my own implementation. So I create an interface, define DoStuff(), and BAM!, your structure now implements my interface. I don't have to change your code.

Sure, the workaround is to wrap your structure in my own which implements the interface. But how, in this case, is the implicit interface not a huge win?

Maybe, as you say, it'll screw over people who use it poorly. For everyone else, I see no drawbacks.

[dllthomas]

It's not just "people who use it poorly". The point of an interface is to abstract over some details while guaranteeing others. If I am unaware of an interface, I don't know to avoid the names used in that interface, and I don't know to abide by the invariants assumed in that interface. That seems like it will bite people who've done nothing wrong. If I am providing a library, I can't possibly be aware of every interface anyone might define in code that uses it. I've no clue how frequently this will occur, in practice.

Haskell's typeclasses work around this by letting you define "how a type implements an interface" at either the definition of the interface or the definition of the type. (Or, strictly, anywhere else both are in scope - but that gets messy for a few reasons, so it's discouraged and GHC warns about "orphan instances" unless you tell it not to.)

[Solarsail]

Structural types, as opposed to nominal types?

[Svip]

Basically. But Go obviously also have nominal types.

[MetaCosm]

No, io.Copy was just the example that everyone would recognize in Go, and likely the first interface you will touch.

My point was implicit, exceptional simple interfaces are sorta magic. They are effortless, and because they are implicit, there is no harm in creating a 1 function interface (or 10 of them). Because your caller is never going to have to do an ... Implements ThingA, ThingB, ThingC, ThingD, ThingE, Thi... it implicitly supports an interface if it fulfills the signature.

So your interfaces end up being tiny (just what you need) and pervasive. This means the way your system ends up working tends to be far more aligned along interfaces than anything else.

When I speak of composition (in this case the composition of functions) I am speaking of the ability to use functions together rather freely and with little effort. This is a bit hard to explain, but it feels a bit like a modern shell, you can wire together lots of commands (functions), from lots of places that have no awareness of each other with the pipe | operator. In Go, simple, minimalistic interfaces act as the glue and let you compose lots of diverse functions together exceptionally quickly.

[killertypo]

I NEED to work Go into one of my projects, but dammit I love Python so much. it is a warm and safe and comfortable cocoon. :)

[MetaCosm]

Then you need to scale and your library isn't actually built in C... or only runs on 2.x (or 3.x) and the cocoon seals up and you can't escape... you scream but no one can hear you... you look for help, desperately clawing at cython, numpy, jython, pypy and C extensions -- they all require you to leave your cocoon far behind... you struggle and break free... suddenly you are exposed to the big wide world outside of your cocoon... you look back and realize the cocoon was just a cleverly disguised prison. /hackernewsstorytime

[killertypo]

hahah well I am very comfortable with C and other languages, but I love python for it's versatility and ease of use! It has some very expressive one liners that are surprisingly coherent for being one liners.

[raverbashing]

Just keep in mind Go IS NOT like python, but instead it's a better C

I'd say it's a better C, not a better C++ (or Java/C#)

[lucozade]

As a language maybe but for usage, not so much.

For me, most modern uses of C fall into 3 camps:

+ extreme portability

+ complete, low level resource control

+ foundational libraries

And Go doesn't really qualify for any of these. For the latter 2 largely because of the GC.

I think in practice, that its engineering bent i.e. no frills language and high quality tooling, will more likely see it being used in the server-side application/middleware space. I guess not surprisingly.

So it really is up against Java, Python, Ruby and C++ and is, therefore, interesting in that it isn't trying to compete on lingustic goodies.

[raverbashing]

"As a language maybe but for usage, not so much"

Yeah, I agree with your points. Which is a shame really.

[lmm]

I loved python and wouldn't've given any of it up. Then I switched to Scala and discovered how much I could get the computer to do for me, without giving up the conciseness, readability and expressiveness of Python.

[cgag]

I don't think you're going to come around on it. It's not suddenly going to stop being terrible at abstraction. That essay seems very accurate and applies to Golang.

The strengths of Go to me seem to be its extensive standard libary and the fact that you don't need to worry about writing elegant code because it's not really an option. That reduced decision making is actually really appealing to me on some level, but it's not enough for me to consider it over what I consider better tools (Haskell, Rust).

I'm currently porting a tiny program a friend wrote in Go to Haskell so we can compare notes, and I think the Haskell is both safer and more elegant, but I'm jealous of the fact that all the libraries he used are from the standard library while I have to evaluate libs of varying quality. However, I would rather put my time in to improving the Haskell ecosystem than using something convenient that makes a lot of decisions I disagree with.

edit: I also think there's value in being a conventional imperative language as someone mentioned below. I with there were something between Go and Haskell. Perhaps that'd essentially be Rust with immutable data structures and garbage collection.

[nickik]

I dont know much about go, but I always thought that the problem with 'the standard library does everything' is that it starts to feel heavy and better alternatives pop up. Then you have these dark places in the library that most people avoid, and you cant really throw away.

Clojure used to have something called, clojure contrib and it was kind of awsome, it did pretty much everything in just one jar. It was also a huge problem to mentain and everybody wanted to be in contrib, so you had the one json lib in contrib and fasters outside.

With clojure 1.3 it got split up into many diffrent parts and it still servs as somewhat of a community standard or recommended library. Overall its much better and much more usful, but sometimes I miss the days when everything was in one jar on on dependency.

[cpeterso]

Rust is avoiding the contrib problem by shipping a robust package manager from the beginning and pushing much of the Rust stdlib (and language features) into libraries.

http://crates.io/

[cgag]

I started using Clojure just after 1.3 came out so I could be wrong, but my impression was that while contrib was all in one place, it was still maintained by a bunch of random people who got their code into contrib, rather than being treated as a core part of the language the way (I believe) Golang's is.

[nickik]

Yes it was, like I said it is better now. However it was also kind of nice because everything was just there. Even with good mantainers, some of the same problems could keep existing.

[coolsunglasses]

That's right. contrib was always the red-headed stepchild to core.

[ansible]

So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)?

As discussed elsewhere on this page, Go is not the most feature-rich language out there.

But it does have features that seem to help my solve my problems with a minimum amount of fuss. Like using interfaces liberally, instead of having to define classes. Having lexical closures is also nice.

If you're not working on an application that can benefit from concurrency, you may not see all the benefits of Go either.

What kind of problems were you trying to solve, and how did Go see heavyweight compared to how you'd solve the problem in some other language?

[wwweston]

I like functions as first-class values and closures. If they weren't present, I might well have bailed months ago. :) And from various experiences doing OO with other languages, I can kindof buy that Go interfaces are often 80% of what you want.

Most of what I've been working on is a Rest API. Here's an example of a problem that felt like it should be something for which I'd be able to write an abstraction to deal with, but turned out to be challenging, at least as a n00b:

https://groups.google.com/forum/#!topic/golang-nuts/JhsiiGHQ...

(Incidentally, though I moved past my then really poor understanding of Go interfaces, I wasn't able to apply the respondent's answer or my new general knowledge to achieve the abstraction I was looking for, and settled for just grinding out the same code for the dozen entities/endpoints it applied to.)

Concurrency: I suspect there's a bit that's hidden in some libraries we're using, and we may yet need to write our own code for some API requests that get processed offline, but I haven't had to explicitly write code for it yet.

If you can think of a specific exercise that might serve to illustrate Go's outstanding concurrency strengths, I'd be interested to try it and compare efforts to another language or two.

[ansible]

(Incidentally, though I moved past my then really poor understanding of Go interfaces, I wasn't able to apply the respondent's answer or my new general knowledge to achieve the abstraction I was looking for, and settled for just grinding out the same code for the dozen entities/endpoints it applied to.)

I definitely can't deny that using interfaces instead of regular OO classes takes some getting used to.

Though I don't understand why you had to grind out duplicate code for all the entities / endpoints though. I hacked up things a bit to get it to run on the playground, but as Jesse McNelis wrote, just passing the pointer to foo worked for the code you wrote.

http://play.golang.org/p/jNpK5CRBfv

[aangeles]

Regarding the sample code is "bson_*" is a bson code convention? I notice Mixed Caps [1]is the idiomatic code for go? TIA

[1]http://golang.org/doc/effective_go.html#mixed-caps

[ansible]

That stuff is from the bson Mongo package. I didn't want to pull it into this example, so that it could run on the playground. I replaced dots with underscores in that case.

[stanleydrew]

It's a painful exercise (entirely due to Apple, not Go), but we implemented an Apple Push Notification Service provider in Go that relies on several of its concurrency primitives.

I think implementing a simple HTTP proxy might also be a really good exercise, though I haven't done it.

[spotman]

If you have spent six months, is that just occasionally tinkering and reading things online, or actually using it fairly regularly?

If you have developed software in go, and after a couple months you aren't finding its saving you time, or at least pleasant to work with, maybe its not for you.

I feel like it is similar to C, but more opinionated, with much less rope to hang yourself, and often things I would have used C or Java, I find doing them in golang saves me plethoras of time.

It is opinionated, but for me the aha moment was after I learned enough of the standard libraries to feel comfortable in the language, I find myself getting things done at lightning speed, and it has performance that is as solid as the jvm in your average use case.

I find the code is also pleasant to read, and the language lends itself to writing verbose, simple code, which I find easier to debug than overly abstracted systems.

[curun1r]

> I find the code is also pleasant to read

This, to me, is what he's missing. On the continuum between readable and expressive, Go falls decidedly on the readable side. If you're working on a project by yourself for 6 months, you might not like Go. But if you work on a team or return to code you wrote 6 months ago and haven't touched since, that's when you'll appreciate Go.

Evaluating languages based on simple solo projects will always favor the more expressive languages, but it's a short-sighted evaluation.

[Elrac]

Maybe unlike other respondents, I'm a Go amateur. I've written three projects in Go, one of a few thousand lines and two of a few hundred. Also unlike many others, I consider Go un-elegant to the point of being ugly. In other words, I'm no expert and no fanboy.

What makes Go my go-to language for certain kinds of projects (I'll doubtless be using it again) is that it gets shit done. It has the brutal simplicity and hardware proximity (and raw speed) of C combined with the small handful of things that most significantly contribute to make Java better than C: A simple type system, garbage collection, usable string handling and dynamic data structures (arrays and hash maps). Go also has a fairly large, useful library.

Multiple return values often including errors make error/exception handling very explicit and in-your-face. When something can go wrong, you the programmer are forced to recognize that and deal with it as soon as the function returns. That's a Good Thing IMO. Java-style exception handling, by comparison, looks to me like an elaborate language hack for passing the buck.

There's a ruthless kind of efficiency in Go's surrounding philosophy. There's one way to format Go code, you let the utility take care of it and never worry about formating again. The compiler won't tolerate various kinds of sloppiness, such as unused imports.

As somebody else mentioned, in Go, writing elegant code is not a consideration because it's nearly impossible. Well, I'm sure there are "better" and "worse" ways to write Go code, but not so obviously that I'd be tempted to give it a lot of thought. So I tend to just sit there and write code by the bucketful until I'm done.

Finally, the tooling gets the job done, and quickly. I can compile for and across various hardware environments and ship executables that don't rely on a JVM or other external dependencies.

[meowface]

Going by Paul Graham's "Blub" essay (http://www.paulgraham.com/avg.html), I'd say the problem is that languages like Go and Java are simply not high in the rankings when it comes to power.

[enneff]

The underlying assumption is that the problem that modern programming languages should solve is lack of power. But I don't see that problem in modern codebases. In my experience, the problem is complexity.

[reverius42]

I think in this case more power might be a good proxy for less complexity: power should correlate positively with expressiveness, and expressiveness should correlate negatively with complexity. More expressiveness lets you build more powerful abstractions with less code.

[enneff]

> expressiveness should correlate negatively with complexity

I don't see why that would be true. In my experience, the most expressive languages often produce the most impenetrable spaghetti code. Can you explain your reasoning?

[lmm]

Consider e.g. traverse, which is a function you simply can't write in a language without higher-kinded types. Several times I've written half a page of code only to realize "that's just traverse" or "that's just foldMap" or so on. In a less expressive language I would've had to leave that half-page as is. Surely that means the expressiveness results in more readable, less complex code?

[enneff]

Sounds more like boilerplate or redundancy to me than complexity. Things I would call "complex" in a software system are god objects, APIs with too many options, invisible interactions between parts that appear unrelated, and so on.

[f2f]

your "should" and "should" should be replaced with "doesn't" and "doesn't" or at best "may" and "may".

more code has been written in Go than Haskell, Rust and Ocaml combined.

[sheepmullet]

More code will be written in COBOL this year alone than has ever been written in Go.

[meowface]

So what? More code has been written in C and Java than Go and Rust and Ocaml and whatever-else combined. A language's popularity says little about its complexity or how good of a language it is.

Powerful languages let you grapple with problems, weak languages first make you grapple with the language before tackling problems. Some people feel like Go gets in the way. I have not written any Go, but I understand both the praise and the criticism.

Powerful languages can cause other issues, but they do enable certain things that weaker languages simply never can.

[melling]

You're being a little vague. Can you give a couple examples where software projects were done in "powerful languages?" I can certainly appreciate that higher level languages are better. However, it seems like in practice they are not used as often as you would hope.

[f2f]

C and Java are not the subject here.

[codygman]

Do you have a source? I don't find your claim implausible, however I would like to know how you came to that conclusion.

[f2f]

the internet is my source.

[dons]

> more code has been written in Go than Haskell, Rust and Ocaml combined.

[Citation needed]

[pjmlp]

> In my experience, the problem is complexity.

Simple languages led to complex code bases.

Many of the Enterprise Java sins were caused by the language limitations and developers trying to work around them.

[enneff]

I think the enterprise Java sins were caused by cargo cult programming. Java can actually be pretty nice when wielded by someone who isn't afraid to invent new things.

[pjmlp]

What leads you to believe the same won't happen to Go?

I have seen this happen in C codebases before Java took the enterprise.

Its own little macro based DSL and pointers that were actually handles for the real data.

[enneff]

Java's sin is a fetish for over abstraction. Go has a strong cultural emphasis on avoiding unnecessary abstraction.

[oblio]

True, but in a lot of enterprise situations the complexity is intractable - it is caused by business requirements.

[pjmlp]

Exactly because of that I rather use languages that provide the tools to work with complexity, instead of shunning it into the shoulders of developers.

Anyway Go has its use cases, and it is already an improvement if less C code gets written.

[AnimalMuppet]

The problem with the Blub essay is precisely the assumption that all languages can be ranked on a one-dimensional axis called "power". That assumption is false. (I know this is heresy to say on HN, but in this essay, PG is simply wrong.)

I'm repeating myself here, but: A Haskell user and a Lisp user are both sure that they're at the top of the power curve, and they're both sure that they're looking down when they're looking at the other language, and they can both tell you precisely why they're sure they're looking down ("It doesn't even have a decent type system" and "It doesn't even have macros", respectively). But they can't both be looking down. What's wrong here?

What's wrong is the assumption that all languages can be ranked by a one-dimensional attribute called "power".

Or look at it another way: Power? Power for what? Well, for writing programs. But what kind of programs? General programs? I've never written a general program in my life; I've only written specific ones. Then "power" is whatever's going to make it easier to write the program I need to write. Whatever language does that is the "most powerful" language for the problem I'm facing.

What power is Go shooting for? It's the power to write a ten-million-line application and have it be maintainable for two or three decades. (That's not my guess; it's what Rob Pike said the language goals are.) If you face that kind of problem, Go may in fact be a very powerful language.

[melvinmt]

> So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)?

I highly recommend to read this article where Rob lays out the motivation behind many aspects of Go: http://talks.golang.org/2012/splash.article

[claystu]

What weaknesses of Pascal are being repeated in Go?

[lmm]

There is no escape. The language thinks it knows better than you. The standard library is allowed to do things that your code isn't.

[_ak]

Like what? The standard library is no more special, other than where it resides in the filesystem. You can write C and assembly code as well and link it to your Go code. And I'm not talking about cgo, I mean [568][ac], the Plan 9 C compiler and assembler that come with Go.

[pjmlp]

> Like what?

Maps, slices, the pre-defined functions.

More powerful languages make no big distinction between user defined types and the language provided ones.

[lmm]

I was thinking most obviously of generics. The go standard library is full of generic collections, but you're not allowed to use generics in your own code.

[claystu]

It looks like free pascal has generics: http://www.freepascal.org/docs-html/ref/refch8.html#refse46....

But to your larger point, doesn't any non-programmable programming language exhibit the same weakness to some extent?

[lmm]

Any language will have some "magic" things that are special-cased in the compiler - things like the basic integer datatypes, or the threading primitives - and probably a few more things that are implemented as C code (though if you're lucky this can be done in a "standard" way, through the language's FFI). But most of the standard library should be implemented in the language itself (look at e.g. the Java standard library, or the Python standard library. In a more coherent language like TCL, even language constructs may be written this way - e.g. "for" or "if" can be just ordinary methods. At the other extreme, PHP has the infamous T_PAAMAYIM_NEKUDOTAYIM, because a simple-seeming piece of syntax had to be special-cased in the parser). If the standard library authors kept feeling the need to step outside the language itself, that's a bad sign - it suggests the language is poorly suited to writing libraries in. But you're right that it's a question of degree rather than a binary thing.

[_ak]

That's not the standard library, though.

[howeman]

Actually, the c compiler just got deleted.

https://groups.google.com/forum/#!topic/golang-codereviews/A...

[jfb]

It may just not fit for you. I feel the same way about C++ -- I understand the strengths of a pay-for-what-you-use language with a ridiculously powerful template library, but it just never came naturally to hand for me.

[cft]

Go is the only language that allows one to write very scalable TCP servers fast (i mean development effot). The servers are almost as fast as C (i.e. 15x Python), but the development time is like Python.

[threeseed]

There are numerous options for writing very scalable TCP servers on the JVM e.g. Vertx.

Then you have the option of using Java, Clojure, Scala, Ruby, Python, Javascript or Groovy languages.

[est]

For the record, Go does not allow you to operate on fd, so some fine tuning TCP parameters does not happen unless you do reflection magic and use SysCall. Which is PITA compared to Python.

[tlmr]

What about Julia?

[FraaJad]

Yeah, what about Julia?

which makes as much as sense as asking

- What about R? - What about GNU DAP? - What about FORTRAN?

for writing a TCP server.

[pasxizeis]

Tooling, simplicity (eg. lack of features), composition, channels.

[coldtea]

>People who seem to be smart nevertheless keep talking it up... some not even as just a good tool but as their favorite language.

Being good enough, not knowing any better PL-wise, and the Stockhold Syndrome explains that.