Go 1.1 is released
blog.golang.org
blog.golang.org
[1]http://help.duckduckgo.com/customer/portal/articles/216392-a...
Sarcasm doesn't belong on HN.
That said, choice of programming language is important. It's possible to be 10x to 100x more productive in one language (at least to start with), if it has libraries (included in the standard lib or community) that do most of the hard work for you. It's very easy to get started with a Python project, if your work at all uses Numpy/Scipy/ETC. The choice of programing language also is a big factor in what engineers you can hire in the future.
But OTOH it really "just works" out of the box.
WRT generators: have you tried using channels? "The tour of Go" seems to instill you with the idea that you should not iterate over lists and use channels instead.
I also miss list comprehensions and, for that matter, type-parametrized functions.
OTOH, static duck typing is brilliant: best of both worlds.
BTW it looks like less work at compile time than the elaborate run-time solution that you linked to. It probably will not even require generation of specialized versions for primitive types.
But, that output / work product is -- and a huge part of Go's value is around the EDGES of a system (build, standard formatting, deploys, etc)
That being said, right now the dominate Go web library is "net/http" from the Go standard library, supplemented by Gorilla (as needed): http://www.gorillatoolkit.org/
If what you are looking for is really a Go web framework however, there are a few in development including Revel: http://robfig.github.io/revel/
There's a few, but I think it's still too early to really call out a "defacto" framework.
Revel, as mentioned, is a popular "full stack" framework, but it can be pretty heavy. web.go[1] gets a lot of use (it sits at a Flask/Sinatra level), and beego[5] looks good but it's also totally acceptable to plug a few libraries together without much work on top.
For example, I'm using:
- mux, sessions, schema & context from Gorilla[2]
- go.auth for social sign-in [3]
- the RethinkDB driver [4]
... and that's about it. Write your routes with mux, set up your handlers with auth/sessions/schema, and generate your models & queries with whatever DB you want. The standard html/template library is good enough (and there's a Mustache library if you need it), and the standard http library covers everything in between.
TL;DR: If you enjoy writing Flask/Sinatra apps, you'll enjoy writing Go web apps. If you're coming from a full-stack framework (like me), there is definitely a learning curve, but I feel that Go's documentation and std. lib flatten that out a little.
[1]: https://github.com/hoisie/web
[2]: http://www.gorillatoolkit.org/
[3]: https://github.com/bradrydzewski/go.auth
It provides nearly everything, likely including things you don't even need. It's likely that a lot of the parts included won't be needed by a "typical" web application, and if you want to do things another way you'll need to spend some time switching those components out. To be fair though, having "everything" can be a big plus, especially when you don't know what you might need (or have the time to glue things together).
I don't know how tightly coupled the components are in Revel, but if it's like Django, some things are easy to add/remove (middleware), and others are much harder to work around (ORM, views, etc.).
And for those who missed my attempt at humor: http://slashdot.org/story/01/10/23/1816257/apple-releases-ip...
You, sir, are a risk taker. Kudos.
That said, it's fun to read the old thread. I like this comment from dbrutus:
Do you want revolutionary? Ask yourself, what chip is this running? Ask yourself, what is the OS on this thing? This is v0.8 of Apple's PDA folks. They're just waiting for the hardware and the economy to get a little better.
Well, opinions can be off base too. Especially in engineering matters.
For example he was totally off base that wireless would be feasible in a 2001 machine, with adequate battery life and performance -- or that it would offer any benefit at the time.
He was also totally off base in commenting about the "less space than a nomad" being lame, ignoring the fact that the iPod was also far more pocketable.
Plus, he deemed it "lame" (probably just for those two reasons) without even commenting on the vastly improved navigation and user experience compared to everything that was there before. Again, off base.
Well I mean, he presumably thought the Nomad was cool, indicating that massive size (nearly a pound!) and shit battery life were not really important to him. The Nokia 9500 came out 3 years later with WiFi and was pretty small, even by today's standards. Could they have put WiFi into a device the size/weight of a Nomad 3 years earlier, and gotten at least some shitty battery life out of it? I suspect so.
"Lame-ness" is an opinion, not really something that you could call objectively wrong. (Though obviously I think we all agree that his degree that the iPod was lame was itself lame).
Had he said "there is no market for this" instead of merely implying it, then he would have been wrong in a more objective way.
It's true that "adequate battery life" does not have a hard, very specific answer, and it's more of a range (and also depends on the capabilities of the era and what users are used to have).
But it's still not "all subjective". E.g if somebody says "1 hour mp3 player battery life is totally fine for me" -- doesn't mean he has a valid opinion that people should respect. In fact, he would probably be laughed off any product design meeting. (Sure, it can be fine "for him". But that's like saying "being hit with a stick if fine for me" if you are a masochist. In no way it represents what would work for most people).
>Personally, I always thought iPods had a terrible UX for forcing you to use iTunes instead of just mounting the drive
That was its definitive advantage. Just mounting the drive would be the backwards option, for people used to manage their own directories instead of letting the computer do it for them.
With iTunes they got people to also grasp the concept of file metadata, playlists, arbitrary organization based on tags and smart playlist queries, etc. And it opened the road for work on them offering a Store, iTunes Match et al.
>And that he just took into account those two reasons is just speculation.
It's based on the only data we have. What he actually said, and the reasons he gave for saying it.
CmdrTaco's opinion ("Lame") is an opinion, not a statement of fact masquerading as an opinion, so it is neither valid nor invalid. Most reasonable people would strongly disagree with this opinion.
Well, for all practical purposes there is.
You're having an underlying premise that personal value/taste judgements cannot by definition be wrong, which I strongly disagree with.
It might not be as clear cut as 1+1=2, but that doesn't mean that everything goes.
If opinions were such as you suggest (totally separate from judgements of fact and totally divorced from the realm of validity or invalidity), there would be no point in sharing them, because they would be totally irrelevant, irreducible and meaningless to anybody but the person having them.
This whole thing is based on the idea of "opinion" as "personal taste beyond critique". Like one happens to like brocolli whereas another likes nachos. Well, in my, err, opinion, even taste for food can be subject to critique. If a food is bad for you, I can say you're wrong to like it. Even if he says "this food is lame FOR ME", one can show him that his "personal taste" is mostly a cultural construction, an effect of early nurture, national cuisine, class, etc. So, it can be "lame for you" just because you don't know any different.
>CmdrTaco's opinion ("Lame") is an opinion, not a statement of fact masquerading as an opinion, so it is neither valid nor invalid.
There is a thing such as an external reality, and in that reality things have attributes and rankings. If from nothing else, at least from expert and general consensus. And I don't think either the expert's or the general consensus validates his opinion.
If opinions could be objectively right or wrong, then they would not be opinions.
No, I'm also making the bigger claim that "most people have a different opinion than him" _for good reason_.
That is based on a qualitative appreciation of certain measurable aspects of reality.
Plus, opinions are also based on facts. If you get the facts wrong, or get what the facts imply wrong, then your opinion is also wrong. (a crude example: I, mistakenly, believe that Mother Teresa killed millions of people, so "in my opinion she is evil")
I assume he is jokingly suggesting that the detractors are wrong.
Yes, I believe the detractors are wrong. And I believe they are especially wrong about generics. One of CloudFlare's most hard core C++/Boost guys 'tried out' Go to see how he liked it and is rewriting everything that needed redoing in Go.
The combination of a 'small, powerful' language that supports multicore machines and the good standard library means people can _get things done_.
CmdrTaco was of course entitled to his opinion, and nobody is suggesting that we take from him that right. However most would also say that in their opinions, which they are also entitled to, his assessment was very lame.
Chet: "Get out the drool cup!" Erik: "In use, my friend! Drooool!" Chet: "Then break out the scraper, because someone's gonna have to scrape my jaw off the floor!" Erik: "That's also in use, to scrape my spooge off the monitor! Spoooge!" Chet: "Ouch! Fetch me my eye medicine, because I have an eyeache from watching a whole mixed bag of eye candy!" Erik: "All of the eye medicine's already in my eye! I'm done with the scraper, though."
[1] - http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
* - To the extent that you may find micro-benchmarks a useful measuring stick.
var service map[string]net.Addr
func ParallelWrite(data []byte) chan error {
res := make(chan error, 2)
f1, err := os.Create("file1")
if err != nil {
res <- err
} else {
There's also the fact that the array (I'm guessing) of bytes diverges from every other language to put them in front of the type which looks like crap. We see the same poor choices of delimiters as with map value types.
Then there's this
func main() {
c := make(chan bool)
m := make(map[string]string)
go func() {
m["1"] = "a" // First conflicting access.
c <- true
}()
m["2"] = "b" // Second conflicting access.
<-c
for k, v := range m {
fmt.Println(k, v)
}
}
It's also difficult to tell in the for loop if v is being assigned as "range m", or if "k, v" are a tuple resulting from "range m"
It's too bad because the goals of the language are quite nice from a CS perspective.
> It's also difficult to tell in the for loop if v is being assigned as "range m", or if "k, v" are a tuple resulting from "range m"
The `range` clause returns two values: index, and value at that index. It's really pretty easy to read and get used to once you actually read some documents.
I feel that braces on blocks are more important to readability/clarity—because blocks should be identifiable—compared to parentheses for if statements. I don't think the if gets lost in there, but if you do then that's fine.
> We also see that "make" is lowercase yet a method, but os.Create and ParallelWrite has caps for a method.
That's because "make" is a built-in function for building slices and maps.
Packages with exportable functions (i.e. os.Create, http.HandleFunc, etc, etc) use capitalisation to denote "public" functions[1]. Functions within the os or http packages (for example) that should not be used directly by someone using the library retain a lowerCase approach. This reduces the risk and confusion surrounding which functions you should be working with when using a library.
> It's also difficult to tell in the for loop if v is being assigned as "range m", or if "k, v" are a tuple resulting from "range m"
Each key:value pair in m (a map, or "dictionary") is being assigned—hence the :=, which declares & assigns k & v in one line—for the entire range ('length', really).
Obviously you don't agree with some of the syntax in Go. That's fine. But some of your criticisms appear to stem from a misunderstanding or lack of knowledge about some language-agnostic concepts (channels, range, exportable functions) that I don't think Go obscures.
Was uninformed about caps. That was a minor point for me, however, and in hindsight I should have at least investigated that before saying something.
Ok I see the consistency in :=, but in that sense I'd personally like to see something closer to Scala where the tuple is explicit by doing something like:
for (k, v) := range m {
for (k, v) := range(m) {
When you're tired and have been starting at code all day long having more visual gestalt in the language helps... syntax highlighting serves much of this but it's better IMHO if the language highlights itself.
He pointed out that utilizing a language through a DSL or FFI that utilizes indentation instead of another method makes utilizing that language inside another language more difficult as it is easy to introduce bugs in the host language that are non-obvious to debug based on the indentation being incorrect but not obviously so.
I recommend watching all of his videos as they are very illuminating due to his primary focus being that of software engineering rather than theory.
It does look weird at first—I thought the same thing. But after writing some code with it, the design has a nice simplicity. When decoding C types, you have to sort of go back and forth "int * x[]" (an array of pointers to int) but in go it's always one direction: "int * []x". The type is always grouped together and that ends up being much easier for humans to parse.
Ditto for putting the return type after the function args. Seems backward if you're used to C/Java/etc but it makes things nicely composable, plus now every function starts with "func", and not a random return type.
I'm fine with the losing the parens around the ifs. Other languages do that and less syntax can look less messy. I do, however, HATE the required curlies. And the fact that stupid go-fmt always wants to format them out differently than I do:
if short_check { short_code() } // My preferred formatting for short error tests
if short_check { // go-fmt always wants to do this.
short_code()
} // Blech.
Nooooo! :-p
I used to prefer short one-liners like that (well, still do in ruby), but in Go I'm starting to kind of enjoy the blindingly obvious, verbose way of doing it. It makes me feel like Mr. Rogers[1][2]. Sure it's plodding, but it's exceedingly clear and easy to understand.
[1] http://www.youtube.com/watch?v=yXEuEUQIP3Q [2] http://www.youtube.com/watch?v=Upm9LnuCBUM
def parallelWrite(data: Array[Byte])
Google code style guidelines are anti-one liner, so that's not surprising to me that Go's formatter tries to enforce that.
I also employ one-liners but judiciously. It can be easy to miss the condition or side effect, particularly with returns. I waffle on whether it should or shouldn't be allowed. But there's something to code compactness on large projects...
As any Go programmer will tell you, Go is a very readable language. It's one of the design goals. It is _not_ a design goal to impress people making superficial judgements.
Also, LOL: https://news.ycombinator.com/item?id=5327478
Yes I did just post that. Should I wait until there's an article on coding aesthetics first? I'm a seasoned programmer with experience in many languages. Reading a new language should make me want to use it because it's an improvement in many ways, particularly around expressivity and clarity. IMHO Go isn't as good as it could be. I wasn't saying Go as a whole is bad or not worthwhile.
Like I said, Go isn't designed to impress superficially. It's a pragmatic language for getting work done.
If a programming experience was designed to impress superficially, then it wouldn't live in a pure text editor at all. I'm commenting on aesthetics as it also relates to usability (readability). I don't get this mindset that things that functionally work well have to be ugly. It's a very unix/engineering mentality that just isn't true. You CAN have both.
In Go's case, I tried to give it the benefit of the doubt, and went through a couple of tutorials, but while there were some nice parts of it that just reinforced my initial impression.
Every other language except:
- Actionscript, TypeScript, Haxe
var x:int = 10;
val x : int = 10;
Var x : Integer;
x : integer := 10;
DSEG segment
x word
CREATE TABLE tbl { x INT }
Dim x as Integer
<!ELEMENT x (#PCDATA)>I meant the [], not just generally the type.
go: data []byte most (all?) other languages that use [] in arrays: data byte[]
Nevertheless, it's similar to Algol's bracket syntax, except in Algol the type comes before the variable:
[]INT numbers = (0, 1, 2);clearly c is some kind of "chan"nel-based synchronisation object for which <- is both the read & write operator (presumably blocking); the "go func" declaration is building a closure that is immediately invoked which, given this appears to be a parallelism demo, probably happens in a separate thread (green or OS unstated). m appears to be a map of string to string, so the assignment to k,v is almost certainly a tuple returned from iterator "range m" because that's just how things go in documentation-level examples.
I know nobody likes a smart-ass but it's a good example and even if some of the above is wrong, I got a taste of Go from it that I rather like. So thanks.
How much do I need to know about pointers to use and learn Go? Is Go garbage collected in the C#/Ruby sense?
I recently switched from full ORM usage to hand tuned SQL queries and loved watching the speed of my application increase 10-fold. I'm having a bit of a speed high and Go seems like the perfect language for this.
What book should I buy to learn Go from the ground up?
Edit:This seems like the perfect place to start.
Do you understand how they work in C? Maybe try reading a little about that. For Go, I'd recommend starting here: http://tour.golang.org/#1 (Don't miss the next arrow in the lower right-)
After running through that you should have an idea of what you don't know- which makes asking questions people can provide useful answers to much easier. :)
>>Is Go garbage collected in the C#/Ruby sense?
I'm not sure what your sense of C#/Ruby GC is, but I'd go with yes.
Very little. Just what pass by value and pass by reference mean in the context of pointers.
The very basic you need to know is: if a function argument is defined as (*foo), you are changing the item you pass to the function (like in Javascript or Java), whereas if it's defined as (foo), you're changing a copy of it and the original item remains unaffected.
Go has pointers, but no pointer arithmetic (in the base language), and it also has GC, so most of the problems people have with pointers in C are not there.
=============================
So it's like PHP where I need to pass in `function modify(&$foo) {` to modify a variable passed by reference.
If you're thinking in terms of PHP's primitive types, then yes: that's probably the best equivalent. PHP has the whole objects always being "passed by reference" [0] thing going on too.
When you pass a slice, for example, you are passing a structure that has a pointer to the underlying data by value; you could think of it as a reference BUT its not what you think it is. What you are passing around is actually a struct that is passed by value:
type SliceHeader struct { //[1]
Data uintptr
Len int
Cap int
}
Yes, but this value is not the ACTUAL value (e.g the underlying storage).
When people (especially newcomers to pointers like the person that started this thread) speak of "pass by value" they refer to their data (the actual value).
So that Go passes _the structure_ by value is quite misleading, compared to the expectation of what "pass by value" means.
For practical purposes, I think they're better off to think of it as a reference.
No, they should learn to understand what is actually happening. Otherwise things, at best, do not make sense and, at worst, can lead to bugs when using functions like append(): http://play.golang.org/p/eTJXu6XMNJ
Isn't this the exact definition of a reference type?
A quick example: the standard library `flag` package lets you parse command line arguments, and returns either pointers or values. You need to know which is which. It's easy, for example, to do this:
var filename = flag.String("file", "default.txt", "file to open")
fmt.Println("Using file ", filename)
So I would say you need to know way less about pointers than C but you still need to know the difference.
However, if you pass an object or an array, the called function can change a field in the object or an element in the array (the difference between those two is an optimization), and the change will be visible to the caller.
Go, however, lets you pass in an explicit pointer to an int, through which the function can change the int to which the caller pointed. Of ourse, the caller can also change the passed-in pointer if it wants, but that has no effect on the caller's variable.
JavaScript, however, is call-by-value. Primitive types (string, number, boolean) are passed to functions by copying their value, and reference types (such as any object you create) are passed by copying the value of their reference.
The reference semantics can be observed in JavaScript in some cases, such as:
var i = 0;
for (i = 0; i < 10; i++) {
setTimeout(function() {
document.write("i is now " + i);
}, 10);
}
Do yourself a favor, and learn the basics of pointers (might as well just read up on C), then move on to Go.
Before you go down the route of buying a paper book, try the interactive tutorial on the golang web site. It's pretty good. There's also a lot of good, and free, reading material on that site to help you learn.
Also, regarding pointers: They're really not that bad, but I understand a lot of people can have trouble with them.
Just realize that in languages like Ruby, and Python, you're never directly working with the computer's memory (as in RAM) - that is abstracted from you.
However, in a language like C, you are. (As an aside, you still aren't directly dealing with it, the operating system abstracts it from your program via the virtual memory system, but you can ignore that for now, and look it up some time when you see fit.) So the first thing you need to make sure is that you understand the difference between stack storage, and heap storage.
Once you understand the heap, and that it is essentially a large block of memory with sequential addresses, you can begin to understand pointers. They are just variables that contain the address of some other variable stored in memory. Languages that support pointers usually give you some syntactic sugar to make working with the "pointed to" object through the pointer easy.
Of course it can all get more complicated, but in summary, give them a shot...you'll gain a much better understanding of many things once you learn them a bit.
Then I went through those. https://news.ycombinator.com/item?id=5365401
As for learning pointers -- I've never been able to get entirely comfortable with pointers in C -- the syntax just feels unnatural to me. I much prefer either assembler (intel syntax) -- or Pascal, eg:
http://www.tutorialspoint.com/pascal/pascal_pointers.htm
Go syntax is closer to C, though. So knowing C, Go might be easier (than not knowing C) -- but it isn't a prerequisite.
And congrats!
EDIT: Yes I know what the faq says [1]. I was wondering if someone working on that can shed light on how the development of a satisfactory proposal has been going. Also, what's exactly wrong with template instantion like in C++ from the perspective of Go devs?
The Go team is open to generics as soon as there is a proposal they feel fits right without performance penalties. Read: http://golang.org/doc/faq#generics
>>Does the community care about that?
Yes, but most people in the Go community are OK waiting for the "right" solution.
>>How have people been working around that?
Generics are nice and convenient, but you can write anything/everything without generics. Just look at everything written in C. And C doesn't have interfaces like Go.
Because using interface{} for the same tasks fits so much better and has so much better performance right?
Tons of languages have implemented Generics -- it's not rocket science since at least 2 decades.
If the Go team is not interesting in working on the thing, then I doubt they would be really evaluating any "proposal".
>>tons of languages have implemented Generics -- it's not rocket science since at least 2 decades.
Sure, but that doesn't mean there are not concerns about the way it is often implemented: http://research.swtch.com/generic
The Go authors have repeatedly stated that they will not be implementing generics.
They don't seem to miss them, I don't miss them, and indeed most people who write much Go don't seem to miss them. The people who continually whine about generics seem to be the type who say, "Oh boy, I'd sure LOVE to write a bunch of kickass code in Go, but I just couldn't do ANYTHING without generics! Why don't you put them in, then I'll try the tutorial"
It's not something we feel the need to work around, we just sit down and write concise programs that do the job, in fewer lines than C++.
Edit: as others have mentioned, it seems the authors would be willing to put them in if they find a way to do it without crapping up the language. If they do, I'll try writing Go code with generics, but they have a bad taste for me after dealing with code containing GenericType.cpp, GenericType.hpp, AbstractType.cpp, AbstractType.hpp, AbstractGenericType.cpp, and AbstractGenericType.hpp all in one place.
That's not true. We just don't have a way of doing them that works well in the language. http://golang.org/doc/faq#generics
Not so http://golang.org/doc/faq#generics; "This remains an open issue." In the discussions I have read, if an implementation of generics is proposed that doesn't sacrifice performance and it truly generic, they are open to it.
What I have seen said is that implementing generics was not on the table for 1.1 or maybe even 1.x
Sounds like weasel speak for "take a hike and leave us alone".
But in all seriousness they are interested in implementing generics, just not in a hurry to do it. It doesn't seem unreasonable to me to label it a low priority feature compared to other things they have added to Go. Java got along just fine before generics (which are arguably poor) and C still gets along fine without them. The Go authors are saying, lets add Generics when we are all happy about the solution and feel we are going to get it "right".
If it's a feature needed for the standard library, then it's safe to say the devs will need it to. The devs aren't (shouldn't) be consistently writing programs that are more trivial than the standard library.
I could easily write a custom Append func in my own application because I would know the Slice types I'm trying to operate on. Writing a language feature is different than writing an application, and it has nothing to do with how trivial something is.
Honestly, Append() as a concept is about as trivial as it gets..
More precisely, you would write one custom Append function per Slice type. AppendString, AppendInt, AppendWhatever.
True enough. But libraries can easily tend toward either of those extremes. And any obstacles to library development will eventually become obstacles to application development.
The JVM engineers have been free to do whatever they want in terms of optimizations at runtime, like code inlining or escape analysis. They may even add trace compilation or whatever they feel like it's necessary. The JVM's GC is precise and generational. The CMS garbage collection rarely blocks the whole process and you've got options for GCs that are totally non-blocking. In fact, the JVM's GC is so efficient that allocating and deallocating short-lived objects is almost as efficient as doing that on the stack.
Russ Cox speaks about the boxing that Java does, but Java makes boxing almost a non-issue. Personally I've learned to appreciate the JVM and what it can do in the context of servers receiving tens of thousands of requests per second.
And here in lies the problem - Go is too low level to achieve the same level of optimizations that Java is able of. But on the other hand it's totally dependent on a per-process GC and personally I don't think we'll ever see a precise, generational GC for it precisely because Go is too low level. The Rust engineers at the very least redefined the problem by making individual threads in a process have their own heap and their own garbage collector.
Go on the other hand feels like a hack on multiple accounts. And to me it's not a beautiful hack either, plus once a language achieves inertia, you cannot change its fundamentals without redefining the language to be something else entirely. If Go will indeed get popular, it will join a long line of languages that people hate, because they have to maintain code-bases written in it, with no easy way out.
Its authors say they don't want Go to be like C++. In many ways, it already is.
Both of these optimizations are present in this release of Go. Granted, there is no doubt more inlining opportunities exist, and better escape analysis is possible, but I think you'd want to chose different optimizations to highlight your point.
What specifically makes you think that there'll never be a precise, generational GC for Go? What about Go makes it too low-level for such an implementation. Unless I'm missing some key issue, I definitely think its possible...
> Go on the other hand feels like a hack on multiple accounts.
Again, what specifically about the language gives you this impression?
> If Go will indeed get popular, it will join a long line of languages that people hate, because they have to maintain code-bases written in it, with no easy way out.
Forget about evidence, you're making claims with absolutely no reasoning behind them. What is different about Go as opposed to say Python, or Erlang, or Node, or C++ in this situation? A code-base written in any of these languages needs maintenance... I don't see how Go is any different in this situation.
No, they have repeatedly made ho-hum excuses about how they can't think of any proper way of implementing them, and that they will do them if they find a "clean way".
>They don't seem to miss them, I don't miss them, and indeed most people who write much Go don't seem to miss them. The people who continually whine about generics seem to be the type who say, "Oh boy, I'd sure LOVE to write a bunch of kickass code in Go, but I just couldn't do ANYTHING without generics!"
Well, isn't this dismissal of them a kind of "confirmation bias"?
Sure, they people who don't care about generics can churn out tons of code without them. Like people have been churning out tons of code in C or pre-generics Java anyway. And, sure, they might not even miss them.
Plus, some of the core Go members have been using languages without generic for decades and even created some. So, being used to working like that, it makes sense for them not to miss them.
That doesn't mean the people who DO want them are wrong in wanting them in -- or that because guys writing C for several decades doesn't find a need for generics in Go, means that there really isn't one.
C compilers are fast, but they aren't that fast. Go compiles so fast that it changes the way you write and organize code; you would never consider compilation overhead in any decision you made in a Go source tree, where you might do that in a C codebase. For instance, Go programmers routinely compile code, run it, and throw away the compiled binary! You wouldn't think it would be possible for compiler speed to be so much better than C that it would make a difference, but Go's compiler manages it.
Okay, Go is fast, but it's not that fast. My 1000 LoC program takes ~1 second to compile. While it's certainly fast enough for me, it's not imperceptible.
If I wanted to spend the time I could do something like append the blob to the end of the program executable instead of just clumsily jamming it into DATA, but this all exists in a library that doesn't need to change often so the fact that it takes ~10-15 seconds to compile is not a problem in practice.
At least, Go team will be aware of your pathological case and have a chance to speed up it.
Maybe it'll work for your use case.
that sounds pretty interesting, is there a GitHub page I can look at ? thanks !
A nicer, more accessible (python/ruby/etc folks seem to like it a lot), faster compiling reasonable alternative to C is a worthy goal - I really don't get why some people get into flamewars over it.
I would think that, even before I had used Go. Ignoring the smaller scanning benefits of Go that come about from the more rigid syntax for braces and such, the C preprocessor system introduces a complete nightmare when it comes to requiring multiple passes over the same code, especially for code that is naive about include guards, pre-compiled headers and other "best practices".
C (and C++ is even worse) has a lot of very large low hanging fruit to cull when it comes to writing languages with faster compilers. Whatever speed C compilers have now is due to the geniuses who wrote the compilers and decades of shoulders to stand on, the language is actively working against them at nearly every turn when it comes to compilation speed.
That aside, I agree. Go compiles very, very fast. So fast that it never occurred to me that "go get" did a compilation until it was pointed out to me that it did.
I look forward to seeing the speed boost that C and C++ get if/when modules are available: http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf
Sure, there are compilers that do a poor job at optimizing it, and it's very easy to make it slow on memory starved systems, but on a system with enough RAM to keep your headers in memory, and a compiler that doesn't totally disregard compilation speed, the overhead of skipping over blocks of include files using include guards is low and for code that doesn't, a compiler that can process multiple source files at the time can trivially cache large chunks of parsed headers.
As I've pointed out elsewhere, Bellard demonstrated TCCBOOT that used TCC to boot-time compile the Linux kernel in 15 seconds on a P4 - it's sufficient to demonstrate that it's difficulty in pre-processing or parsing C quickly that is the block for fast C compilation, but that to the extent it is even a real problem it is architectural decisions in the major C compilers and/or optimisation.
It's quite possible Go can be compiled faster, but so far I've not seen any compelling evidence that it is even roundly beating readily available C compilers. Certainly the numbers bandied around in this thread are not impressive.
I did some ocaml work a few years ago and had a similar revelation. Its compiler is just as fast—my short little programs were more or less instantaneously compiled. Fast compiling is really, really nice, even though it seems like a silly thing to tout.
C compilers that are written to be fast rather than flexible can be extremely fast. E.g. see Fabrice Bellards "TCCBOOT", that he demonstrated compiling the Linux kernel at boot-time in 15 seconds on a 2.4GHz Pentium 4: http://bellard.org/tcc/tccboot_readme.html
TCC can also be treated much like an interpreter like your go example.
It all boils down to having the parse each include file every time it appears, because the preprocessor might change the meaning of the file in each inclusion.
Yes, you need to pre-process and potentially parse them again, but in practice most C include files use include guards and are low cost to process if done even remotely properly.
This is why Plan9 C compilers have the strict rules that header files don't include other header files and you as a user need to include them all.
I need to look into TCCBOOT in more detail.
It is also perfectly possible to cache token streams or even pre-parsed (with some caveats) versions of the headers specialised by the value of used pre-processor definitions, which in most cases will prevent re-parsing of most include files (only causing re-parses when the pre-processor definitions actually change).
The pathological worst case for C code can be horribly nasty, but real-world code is generally fairly well behaved and easy to speed up processing of on modern systems that aren't terribly memory starved. Even on systems that are memory starved, there have been plenty of C compilers that can "pre-compile" headers to speed up compilation.
I assume you are aware, but tcc can be treated exactly like an interpreter:
#!/usr/bin/tcc -run -lgmp
#include<stdlib.h>
#include "gmp.h"
/* all this in eg. fac.c */
void factorial(mpz_t r, int n)
{
unsigned int i;
mpz_t tmp;
mpz_init(tmp);
mpz_set_ui(r,1);
for (i=1;i<=n;i++)
{
mpz_set_ui(tmp,i);
mpz_mul(r,r,tmp);
}
mpz_clear(tmp);
}
int main(int argc, char** argv)
{
mpz_t r;
mpz_init(r);
int n;
if (argc == 2)
{
n = atoi(argv[1]);
factorial(r, n);
gmp_printf("%d!:%Zd\n", n, r);
mpz_clear(r);
} else {
exit(1);
}
exit(0);
}
chmod a+x fac.c
time ./fac.c 1000
1000!:4023872(... snip for formating ...)000
real 0m0.007s
user 0m0.004s
sys 0m0.000s
edit #2: indentation/block formatting of code. edit #3: missing "time" prefix...
edit: s/tpl/tpu/
btw, the tp linker - http://turbopascal.org/linking-modules-and-creating-exe-file
http://prog21.dadgum.com/47.html
edit: in fact a number of the things that Rob Pike has brought up in talks reminded me of that article
% make clean
% time make make-listener make-sender make-diag make-ssl...
3.42s user
1.05s system
105% cpu
4.240 total
% find src/ -name '*.go' | xargs wc -l | tail -1
17870 total
% make clean
% time make -j4 make-listener make-sender make-diag make-ssl...
5.75s user
1.99s system
382% cpu
2.020 total
% time make -j4 make-listener make-sender make-diag make-ssl...
1.56s user
0.73s system
209% cpu
1.090 total
(I should have not counted the tests in the above analysis. There are 7,290 lines of tests and 10,580 lines of code).
> Yes, we wrap the go build tools with make.
i.e. instead of issuing "go build foo/mylib" and "go build bar/myotherlib" in parallel, just issuing "go build foo/mylib bar/myotherlib".
I say this because I remember there being logic inside the go command to parallelize builds already, see the "-p" flag in "go help build". In particular, the go command will be able to avoid statting all the files, comparing mod times twice, recomputing the DAG, etc. Although, considering how fast it runs anyway, this speedup might be negligible...
: time go build -a
real 0m3.980s
user 0m5.012s
sys 0m1.140s
: time go build
real 0m1.854s
user 0m1.760s
sys 0m0.332sMy home server is an AMD FX-4100 (quad core, 3GHz; this is one of the early Bulldozer CPU's and definitively not a speed daemon - I picked up the CPU and motherboard for <$150 a year or two ago).
I just tested a 6k C program that compiled in 1s flat with gcc 4.7.2, or .44 seconds with -j4, and a 13k lines one that completed in 2 seconds, or .88 with -j4.
Gcc isn't exactly renowned for being a fast c compiler.
A "no op" build of the 13k project takes .004 seconds, though, perhaps that's the reason - if your make setup is horrendously complicated perhaps it's slowing your numbers down a lot. And it's certainly possible to make C compilation incredibly slow if you do lots of nasty pre-processor hacks.
But then again whether 6k, 13k or 18k lines, both your project and mine are tiny.
(For those that don't know, this website was created for a talk about Go given by Andrew Gerrand. Code: https://github.com/nf/go11 , slides: http://talks.godoc.org/github.com/nf/go11/talk.slide#17)
http://www.youtube.com/watch?feature=player_detailpage&v...
I guess the question then is "do you trust those guys?" So far the answer seems to be yes.
I'm surprised by the speed of the dev team. It seems that just a few days ago that we saw the latest RC and just a few days before then was the previous RC. Fast development!
Using GDB seems akin to working with assembly
http://geekmonkey.org/articles/20-comparison-of-ides-for-goo...
I'm the author of one of them (Zeus) and while the results are not as slick as the Visual Studio debugger it's a better than straight out GDB.
I wanna give Go a start but can't see any community website that lists Go libraries like NPM.
EDIT: I'm not asking for "npm install person/project", I'm asking for a community website and a file like package.json that records information about a project.
As I observe, Go projects are really messy. I saw some code importing dependencies like "import github.com/foo/bar".
I think Go should focus on declarative programming and its aesthetics culture.
http://golang.org/cmd/go/#hdr-Download_and_install_packages_...
$ go get github.com/person/project
And yes, "go get" comes with the standard gotools.
Edit: WTF? why this comment is down-voted now?
Nothing that I'm aware yet. It's mostly community-based discovery and recommendations, but a centralized repository would sure be nice.
These are by no means all the 3rd party stuff out there, but it's a good starting point.
Incidentally, this website is intended to automatically generate and serve the documentation for all those projects in a centralized place. You don't even have to submit your projects. Just type the import path in the search box, and the site fetches the code by itself.
Edit: And here's anther community-built site to do continuous integration testing for your projects. It too, has an index of registered projects: http://goci.me/
I think Go needs to focus on improving its community and its aesthetic culture.
You seem more eager to make grand proclamations than to gain understanding.
You must read different mailing lists, G+ groups and IRC channels than I do...
>>and its aesthetic culture.
ROFL, what? How do you feel about the "aesthetic culture" of C programmers? Because you know- thats not a very popular language or anything...
I'm pretty sure that page is auto generated by GoDoc, an automatic documentation tool that generates documentation on the fly.
For auto generated documentation I'd say it looks pretty darn good!
try this in your command-line: npm install name/project
npm install pkg@1.2.3
npm install foo/bar#cfdea4213
Look if you or Oakaz feel so strongly, go build that centralized repository. But looking at centralized repos in different languages there are as many misses as hits. And even among hits -- pip for example -- the core benefit pip provides IMO is not discovery. More often than not, I find a Python package via a Google search and then merely install it using pip.
Your snark here is a little absurd IMO.
I know CPAN does.
That's not messy; that's idiomatic Go. By convention, package imports can be URLs to version control repositories, which the `go` tool uses to determine dependencies and install them automatically.
Go has no equivalent `package.json` file. All package information is inferred from the source code.
The closest thing to a central repository is on the Go wiki. [1] Many people also use godoc.org [2], which is searchable.
[1] - https://code.google.com/p/go-wiki/wiki/Projects
[2] - http://godoc.org/-/index
Haha.
Everybody understands Go has a tool that deals with dependencies for you. And any other language can have it.
And this is why I avoid monopolistic platforms even though they are fast. If the owner of your platform has no taste of aesthetics, you'll write fast and ugly looking code. which is not fun for me.
As PG says in his book, a good solution should also look good and simple.
Go is very imperative, ugly looking, and not simple.
This link is actually a self-answer by you.
>Go is very imperative and ugly looking, and not simple.
Further, this is just stupid:
>And this is why I avoid monopolistic platforms even though they are fast.
If you don't want to use `go`, so be it. The manual compiler and linker tools are available that you can cobble together with make or ant or whatever masochistic tool you prefer.
>This link is actually a self-answer by you.
What are you whining about? What do you want? That's just a laundry list of known/seen Go packages. As everyone else has already told you, there's no need for a package.json and this literally isn't a problem for anyone actually writing Go code.
I disagree.
The two aren’t mutually exclusive. If that URL goes down, is there a fallback mechanism?
For what it’s worth, I agree with oakaz’s sentiment that Go is “very imperative” and “not simple”. It is deliberately designed that way, with lots of syntax and types for representing (abstractly) the inherent complexities of its intended domain. Any ugliness, however, is purely subjective.
The OP (of this thread) said, 'I saw some code importing dependencies like "import github.com/foo/bar."' I did not understand this as a criticism of the design choice of using URLs as imports, but rather, a statement about some Go projects doing something horrendously wrong.
Yes, one can think URLs as imports is both messy and idiomatic, but I do not feel that was central point of the OP. I suspect we will never get a clarification, though.
> If that URL goes down, is there a fallback mechanism?
I don't know what you mean. If the package is no longer available at the URL then it cannot be downloaded from that URL.
> For what it’s worth, I agree with oakaz’s sentiment that Go is “very imperative” and “not simple”. It is deliberately designed that way, with lots of syntax and types for representing (abstractly) the inherent complexities of its intended domain.
Go was not deliberately designed to be "not simple." In fact, it was deliberately designed to be simple. Simplicity's name is invoked again and again as a justification for including or not including changes to the language.
The Go developers are aware of this limitation, and their typical recommendation on the mailing list is that you should never need to use anything other than the latest version of any third-party library, e.g.: https://groups.google.com/d/topic/golang-nuts/3gEseiCwdf0/di...
> The Go developers are aware of this limitation, and their typical recommendation on the mailing list is that you should never need to use anything other than the latest version of any third-party library
It's either that, or you pin the version you want in your own fork of the package. Which is not an unreasonable solution to the bitrot problem.
Regardless, this limitation doesn't stop the `go` tool from being awesome. It's easily one of the reasons why I use Go in the first place.
If B1 and B2 are really incompatible, then yes, there's a problem; but not being able to solve the problem completely in all cases doesn't mean we need to throw our hands in the air and not even try to handle the simple cases. I think it's telling that Google uses a custom build system for their Go projects, rather than "go get".
(And forking all of your dependencies is an option, but it's not quite that simple. In order to get truly reproducible builds, you have to mirror all of their dependencies as well, and patch all of your forked versions to fix their imports.)
It's not just incompatibility at the package level. Allowing them to simply coexist in the `GOPATH` ecosystem is problematic. It isn't technically difficult to offer a package tool that can handle different but compatible versions of a library, but it certainly increases the complexity of the system. The simple directory structure of `GOPATH` and its correspondence with import URLs would be lost.
> In order to get truly reproducible builds
Yes, if that's what you need then you'll have to pay that price. But not everyone needs that. For software I release, I only pin dependencies when they have a track record of breaking or don't update frequently enough for my purposes. In practice, it's pretty rare.
> If B1 and B2 are really incompatible, then yes, there's a problem; but not being able to solve the problem completely in all cases doesn't mean we need to throw our hands in the air and not even try to handle the simple cases.
That's ironic because that's exactly how I see the `go` tool. Package management is extremely difficult to get right, so instead of throwing their hands in the air, the Go devs put out a tool that is simple to use and has proven to work very well in practice.
The fact that the `go` tool is so simple is one of the reasons why I love it so much. If and when I need to be 100% confident in my builds, I'll happily pay the price to make it so.
Google uses custom build systems for lots of things ;)
In fact, to not under-generalize, I think it's safe to remove 'build' from the previous sentence.
It's not only an option, it's a practical necessity to freeze the dependency tree locally so you can run a rebuild when someone's knocked the remote repository offline. Doesn't everyone do this?
Mind you ruby also has a central repository in the form of rubygems which allows for this kind of versioning.
Go, lacking the same thing, relies on people just entering github URLS which seems insane to me but could work I guess if everyone agrees to tag their projects using semantic versioning where appropriate. Then you could do something like person/project@v1.2.3
Mind you, of any of the companies on the planet I could think of that has the resources to to create, manage and maintain a rubygems equivalent for go, Google would be top of the list.
There's no need to guess. It works. Almost the entire Go ecosystem uses it.
> Then you could do something like person/project@v1.2.3
This has been suggested. But it's just a mechanism for versioned dependencies; it doesn't address the transitive dependency problem that I cited.
As of right now, if you need to pin a dependency to a particular version, then you fork it yourself. I welcome this infrequent pain with open arms to the benefit of keeping the `go` tool simple.
It's not like people haven't tried to setup a central repository with versioned packages [1], but it just hasn't caught on.
[1] - http://www.gonuts.io/
For a given definition of "works". Personally speaking, my "good" has not been met but of course, each to their own. The "Fork it if you want version x" workaround also would not satisfy me.
Google has the resources, reach and authority to easily setup a central repository. If they did then I would not be surprised to see people start using it like CPAN and rubygems.
You say you do not want the go tool to become complex but there is no reason the dependency management side of things cannot be done with a separate tool to keep things segregated.
The current tool seems to roughly match the ruby 'gem' command (albeit with-out a central repository). I am surprised google has not created an analogue of the ruby 'bundler' gem with its 'bundle' command.
Yes. I addressed that.
And if that package references another package on github understandably I need to pin it too, but do I also need to modify all of the imports in the original third party package I wanted to reference the pinned dependency?
Only if you want to. You don't have to.
> but do I also need to modify all of the imports in the original third party package I wanted to reference the pinned dependency?
Yes, but it's trivial:
find ./ -name '*.go' -print0 | xargs -0 \
sed -i 's#github.com/BurntSushi/wingo#github.com/YourName/wingo#g'I guess I don't understand why it's expected that I would run production code that imports from a third party automatically. I don't want to deploy updates some random person committed today to some third party package I'm using or some package it depends on, so if I want to use a third party package I have to recursively pin it and its dependencies and recursively modify import statements.
Along those lines, did you know that Maven2 (and possibly in Maven 3) it's possible to have dependencies that are pulled into your bundle that are at a lower version that specified in a top level pom? Yup, versioning is really hard.
No. You can compile for ARM + a platform (i.e. Linux, BSD) if you want to run Go code on an ARM device. Think RaspberryPi or Beaglebone running an ARM port of Ubuntu/Arch.
Writing Go code targeting iOS (or Android) is a whole 'nother ballgame.
Minux did an iOS port, it's not part of the official tree because an iOS port required a rooted device. Perhaps this might have changed as with two word funcs, the Go runtime doesn't do runtime code generation.
I remember reading that Go was ported to darwin/arm, but it can never be supported since there is no way to legally run their test suite for it.
https://plus.google.com/115863474911002159675/posts/DWmyygSr...
Maybe one day it'll come. If on that day iOS has gained a public XPC API I'll be quite the happy camper.
It would be interesting to compare number of downloads for Python/Ruby.
How practical is it to use such a language for large code bases?
But this is 2013, there are somethings that expected to come from a language default. Exceptions are one of them, few such things I can think of are things like regular expressions, closures etc.
It's really a hard design problem. I agree that some form of error handling should be a language default, but I'm not sure if "traditional" exceptions should be it. As a C++ dev who has worked on projects with and without exceptions, I can say there is pros and cons to both.
But this is 2013, there are somethings that expected to
come from a language default.
Exceptions are one of them,
I'm finding the multiplayer aspects of my current game to be an excellent fit for Go, making good use of concurrency and networking.