Four years of Go
blog.golang.org
blog.golang.org
However, if you do a lot of collection processing, you start to really itch for something like generics (Which can lead down some pretty interesting rabbit holes: http://blog.burntsushi.net/type-parametric-functions-golang). I think this is a pretty big feature to be missing, actually. I hope it comes soon in future updates. It's pretty frustrating to have to reimplement data structures that can accomodate custom structs.
But overall, it's very impressive, and a step in the right direction. I think we're approaching a golden age of programming languages, where syntax, expressiveness, and performance are all given equal seats at the table.
I really hope it keeps gaining momentum.
This was reason enough for C to get popular.
Only if commercial UNIX and Windows also get rewritten in Go.
> This was reason enough for C to get popular.
C got popular because UNIX was adopted by the enterprise and C was the system language.
I doubt C would ever been popular without UNIX.
Mhm.
> ... easy to reason about...
So very much no. There is nothing about the stateful nature of C-programming, its syntax or the patterns people use that is easy to reason about. You're comparing it to what, exactly? C++? C is an amazing language but comparing it to the languages that were around when it became popular it's not even close to relatively easy to reason about. Even less so nowadays.
> provides enough abstraction to easily write complicated code
This strikes me as a weird thing to list in "pros". Complicated is the opposite of good. Abstractions should let you write simple code, not complicated code. I feel like you've either misunderstood the word "complicated", massively mischaracterized C or you have a very weird view on abstraction.
> Of course, some other language with this set of properties might have taken C's role if it had not been for unix, so maybe that's what you meant.
I'd like to point out that your assumption that people use programming languages because they are better than the alternatives is pretty naive. The most popular languages are decent, no doubt, but have you noticed how every really good language suffers from a pretty huge lack of users? We all know these languages are better, but it's never been an issue of "You're not good enough for people to use you".
If there was ever any indicator for a good language it'd be "What do people choose when they have the freedom, knowledge and opportunity to choose anything without any outside influence?". That scenario is so wildly scarce to observe and anyone who is in that situation likely suffers from biases acquired earlier on his programming journey.
>What was taking its place at that time?
Pascal was fairly heavily used, but was dying out. LISP was hot because it was the middle of the Great AI Boom, Modula-2 was supposed to replace Pascal and be a systems programming language, and ADA was supposed to be the next great thing. Apple had created Object Pascal. Self was the big research language. Nothing really took hold until C++ in the latter part of the 1980s.
The UK financial sector seem to like academic stuff then.
For example, Go has no REPL. (It's difficult for statically-typed languages to provide one.) It's commonly believed that a REPL is valuable and increases productivity. So if you were offered the choice, is there any circumstance in which "no REPL" is equally powerful as having one? Well, the vast majority of great hackers seem to agree that it's always superior to have a REPL than to be forced to live without.
Lots of people love programming in Golang (I especially love to write distributed systems with it!) yet it probably won't ever offer us a REPL. That must mean one of two possibilities are true, both of which are bizarre: either 1) we love Go in spite of being limited by not having a REPL, or 2) having a REPL isn't as big of a deal as everyone thought.
So I'd like to ask all of you: Do we love Go in spite of being held back by it? If so, then what are the factors that cause us to decide that using Go is worth giving up programming power? After all, each of us are choosing to use Go in lieu of more powerful languages. So why do we choose to give up programming power?
Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought? That seems plausible. It's at least as plausible as "it's a good idea to give up REPLs for static typing."
Go is wonderful to work with. But I'm so confused why it feels wonderful to me. I know I love programming in it, but once I start thinking about the implications, I start to wonder: Isn't giving up power a bad thing, and therefore choosing to use Go == choosing to be forever held back by its deficits, and therefore it's a bad decision? Or is it true that having every possible language feature available to you ("maximum potential programming power," i.e. as far above Blub as possible) isn't as big a deal as we all thought?
This pg essay talks about why it's worthwhile to have as much power as possible: http://www.paulgraham.com/avg.html (search for Blub Paradox) .... So either he's wrong, or we're ignoring him even though he's right. Which is it?
EDIT: There are other limitations besides lacking a REPL, e.g. there's no dynamic typing. It seems like we should try to figure out why it's a good idea to give up any programming power at all.
Given this focus, it sort of makes sense why you might not miss a repl as much in go (though personally I do still miss it). Repls are most useful for exploring and experimenting with complex data, while I think go's focus is more on streamlining and bulletproofing all the machinery surrounding the data than doing a whole lot with the data itself.
I don't mean this as a criticism and I'm not trying to say that you can't do serious data processing in go, just that it's not a core strength like it is in functional languages. I think the majority of applications out there actually have fairly light data processing needs and heavy glue needs, so go's set of tradeoffs make it a great candidate for tons of projects.
No, it's not. As long as you have a way to polymorphically print a return value, which there are ways around (in Go, with reflection; in Haskell, with typeclasses; in Java, with Object's toString), there is nothing semantically difficult about a REPL for statically typed languages.
> there's no dynamic typing
Yes, there is, through `interface{}`.
You could give a BMW M3 a faster engine, or a more full-featured Bluetooth sound system, but it's the way the steering wheel feels that makes people love that car. Same with Golang. They did an extraordinary job balancing the language, especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance.
This one is perfect however, and really explains my feelings towards Go (and recently, C, oddly enough).
Go really failed to appeal to a lot of systems programmers, despite their intentions. Go is picking up people who used untyped languages and still didn't accept that static typing does not mean java. They finally have a simplistic statically typed language that isn't java to use.
I've made a live editor [1] for Go that I use very happily (and I keep working on a 2nd generation version, rewritten in Go, which will be more user-friendly to install and use).
There are other REPL-like tools like [2] and [3].
[1] https://github.com/shurcooL/Conception#demonstration
[1] https://github.com/scala-ide/scala-worksheet/wiki/Getting-St...
The importance of REPL is very exaggerated. Neither Java, C#, C++ nor C have one (and together, these four languages probably make up for 95% of programming languages).
There is nothing that prevents any of these languages to get one (Scala has one, a bunch of these exist for other statically typed languages), it's just not that useful when you have powerful IDE's at your disposal.
Most of the time I need REPL-like functionalities, I need it in the heart of my application, with all its structures and state initialized and in the middle of a breakpoint. I hardly ever need to type snippets of code with zero context around them, which is what REPL's offer.
Btw, in regards to needing initialized state - code that can't be initialized easily, smells badly. And in Python and Ruby for example, you can stop the execution at any point in your software and initialize the REPL, having complete access to the current context.
In Ruby it's as easy as:
require 'ruby-debug'; debugger
import pdb; pdb.set_trace()
It's true that Java, C# or C/C++ don't have a REPL, but that's why I don't use Java, C# or C/C++ (or Go).
[1] http://msdn.microsoft.com/en-us/library/f177hahy(v=vs.71).as...
[2] http://msdn.microsoft.com/en-us/library/aa716276(v=vs.60).as...
The closest thing C# has to a REPL is the Mono C# Shell, built on top of Mono's C# Eval and it's pretty cool, but it's pretty new and raw and needs Mono.
So what?! Languages and implementations are not the same thing.
So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language.
Basically, I don't care what the ideal implementation for a language X might look like in 10 years from now, what I care about is (1) what am I able to do with it right now and (2) what's the community's culture like?
Lately I've been learning some Clojure. I'm fascinated by how Clojure developers work with the source-code. Emacs is an extremely capable editor, but for Clojure it's a full-fledged IDE and a shell for the REPL and it can do anything you'd expect from an IDE. And the whole workflow is basically typing code, sending that piece of code for evaluation in the REPL, typing in the REPL some quick invocations to see how it works, rinse and repeat. The learning experience is also completely awesome, as for some reason you end up reading a lot of the standard library's implementation - coupled with the REPL on the other side in which to quickly type what you read - the workflow is amazing (though Smalltalk developers are probably laughing at me right now).
Reference implementations only define languages that lack a proper ANSI/ISO/ECMA standard.
> though Smalltalk developers are probably laughing at me right now
Yes we are. :)
Emacs is a light version of a Lisp Machine. Now imagine how would your OS be, if everything would be as customizable as Emacs.
Sadly, Lisp machines and Smalltalk environments died on the mainstream.
This is why we Lisp developers have networked REPLs -- I can start up a remote JVM, in communication with other services, connected to my local vim session. I can dynamically load code into it, start and stop my application, etc, all from my editor.
C# ==> http://www.mono-project.com/CsharpRepl
C++ ==> http://root.cern.ch/drupal/content/cint
C ==> http://www.softintegration.com/demos/chstandard/interactiveC...
Java ==> http://www.javarepl.com/console.html
People, please pay attention in compiler design classes and don't mix languages with implementations.
For java there is bean shell/groovysh which isn't quite as good.
There is a mono repl and there is linqpad for c#. Ive used linqpad and it is very usefull.
scala worksheets are also very cool.
I often find myself exploring in a language with a good REPL and then implementing the findings in a language that does not.
I constantly use REPLs to experiment, verify output of functions, etc. In the case of Go I open the Go Playground at least once a day, often much more.
A REPL is a nice learning tool, but actually not that useful for productive programming. Go has a playground for learning and experimenting.
I use small files instead of repls most of the time. There's no program that's too short to be stored in a file.
The current grandaddy is Devel::REPL - https://metacpan.org/release/Devel-REPL
The new kid on the block is Reply - https://metacpan.org/release/Reply
PS. I do find using a Perl REPL invaluable for me.
If it's "cumbersome" to acquire the state you need for testing, then that sounds like a design problem that you should fix. The best kind of tests are reproducible and part of a test suite anyway.
When I mentioned state, I did not mean testing. Sure, a properly designed system will have all it's computaional parts abstracted in a functional way so it will be trivially tested compiled or not. However, REPL is incredibly useful during the development process when the abstractions required are not yet clear, so it allows one to easily explore design possibilities without committing signficant effort of implementing a correct compilable module.
So we are pleased to see Go being used for the job it was designed for, but we are also happy to see that Go has a broader appeal.
This sounds a bit like revisionism. Rob Pike made it clear that the initial motivation for Go was the slowness of the C++ compilation.
Go was clearly initially targeted at replacing C++ and it's not being successful in that area at all.
Personally, I think it will grab a decent amount of Ruby and Python programmers but it won't go much further than that.
This is a strong overstatement. It's true that we thought more C++ programmers would be into Go, but it's also true that there more than a few teams at Google that have moved from C++ to Go, or chosen to use Go instead of C++ for new projects. It's not a black and white thing; there is no archetypal C++ programmer that does or does not like Go.
To reiterate: Go was designed for systems programming. People are using Go for systems programming. On top of that, there are many others using Go for other purposes. We're pretty thrilled about this.
I think it has nothing to do with the difference between C and C++ and everything to do with the reasons why people use C and C++: extreme performance, zero-cost abstractions, and integration with native libraries.
I still think the initial part stands. C and C++ are not visually or mentally similar languages. Go is very similar to C in logic, so I'm not sure why it was expected that C++ people would flock to it(unless of course they weren't happy with C++, which brings us back to the first condition in that they were probably only using it for performance).
Go provides most of the benefits of the JVM without being as much of a memory hog. Thus, it makes it a nice replacement for somebody who would rather use Pascal/Modula than C++. (Java originally was seen by me as a Pascal in C++ clothing for Unix)
C++ gives me back stronger type and enough power to have a safer language than C can ever offer.
I also jumped into Java when it appeared for the same reason.
Until Go compilers provide support for generics and dynamic loading, I rather use C++1y, D or Rust.
Mapping interfaces onto a funky function/routine call syntax (an optional parameter in a second set of parens for the "receiver"), and maintaining stack frames around a procedural type reference (closure) after the enclosing scope returns, are about the only new tricks.
Or, was adding garbage collection that big a need? GC of course makes Go quite different from C++, so they should not be surprised if some "speed demons" refuse to convert over. (note that I hate C++, but can see the point of this aspect)
But there is plenty of action at that level in the Go community, and as distributed consensus libraries like go-raft mature it will only become easier to write and trust such software in Go.
I developed software system with hundreds of millions to a few billions data entries items in the core object store (C++) and need to very fast access time. There are needs to open/load/read those objects in database in very fast speed (< 0.01 seconds). When I profiled those operations in early version of the code, the biggest bottleneck is always the malloc/free when the system reached > 10 millions records.
To get around those limitation, I end up design the data structures / datastore that eliminated the malloc/free, new/delete and do my own memory manager to map all the info directly to the structure in the file via mmap and do my own sub allocations. With those, I can get everything in < 0.01 seconds constant access time regardless the size of the database. (from startup of the program to return the value to client.)
I think all modern day database or BIG DATA type system app depend on its own custom memory manager. My theory, a language that depend on garbage collection can not be used in those big data app design.
I love to be proven wrong by someone re-implement the mysql, (or even just sqlite) in "pure golang" (not sqlite driver in C) that can provide similar level of performance with golang's garbage collector compare to sqlite's C counter part.
The use case I care about is DB size of 0.1GB - 50 GB with hundreds of millions of records in the DB.
I'd say go is actually an ideal language for building a database because:
1) syscall's and low level io (including mmap) are all pretty much first class. 2) networking (duh)
Some final ramblings: I realize "systems programming language" has lots of different definitions, some of which go doesn't meet due to it's stop the world gc. I'll concede that point, but as a parting shot let me remind you all that free'ing a tree of objects can cause similar pauses, although at a more convenient time. For me, I would assume that there are no guarantees in a database type system, you just want to go for something like: "99% of requests complete in less than a millisecond under certain controlled conditions". You never actually know if: 1) You have disk contention for that data you're reading causing pauses. 2) You've been swapped out and that pure in-memory operation slows down by an order of magniture 3) A billion other things.
For me personally, I don't really mind adding
4) The golang gc ran
To that list of things because benefits are worth the tradeoff, but that decision depends on the project.
References ---------- http://golang.org/pkg/syscall/ https://groups.google.com/forum/#!topic/golang-nuts/AzAtpOXt...
One main different between C and go is this:
C can type cast any mmap pointer and de-reference it got the values (pointer, offset to other locations) extremely fast - < 0.01 micro-seconds (assuming page is swap in.) BTW, I do track C line code execute time nano-seconds resolution all the time. It is not difficult to do with RDTSC instruction. It gave you timing resolution in term of CPU clock cycles - 1 2GHz CPU clock cycle = 500 picoseconds, One can easily see the system paging and context switching info from those resolution.
In C code, that is only a few assembly instructions. In go (or other GC type language) that one operations is translate to multiple C functions calls. That's probably tens if not at lease hundred times different in pure CPU cycles.
Using a GC just requires a different mindset when designing data structures.
Most of the software we build at Google are server processes that talk to other server processes. Go was designed primarily for this role, but it is obviously useful for a lot more.
1. So we don't get generics, but the language built-ins seem to get to be type-parameterized (channels, slices, maps). Unfortunately the syntax for doing so for each of these is inconsistent (probably as a result of being special-cased rather than dog-fooded using language-level generics): []float, map[float]float, chan float.
2. Built-in types seem to receive other special treatments as well, which includes special initialization keywords (make vs. new) and built-in functions (len, cap, etc.) but I don't see why this needed to be the case, even for performance reasons. There's no reason why the these built-in types couldn't pretend to implement built-in interfaces to make more transparent with user-types while having the compiler optimize them with special-case functions for efficiency.
3. Unused variables are a hard error which is a completely understandable stance. Unfortunately, I think people may use workarounds to get around this. Also, I can't believe unused variables are a hard error, but uninitialized variables are not! Instead we are supposed to trust that everything is OK since they get initialized to some kind of "zero" value that isn't even under the developer's control.
4. Other small quibbles: I think pattern matching on function arguments could have been implemented as sugar that uses interfaces and method calls under the covers. Also named return values are ugly, and the function declaration syntax could have been made more concise.
Like many well designed and well engineered things, I think familiarity and time cause that satisfying feeling to blend into the background and become the norm. You only realize the difference again when you have cause to use some other tool laying around (I just need to pound this nail I will just grab this random hammer laying here) and it "feels" different -- the weight is wrong or the grip is weird.
I by no means claim Go is perfect, but it seems to a great match for the kinds of things I tend to work on, and it "fits in my hand" rather well these days.
Wow! The state of C++ searches on google were 0 in 1987, as were searches for "Apples" and "Oranges" so go must be doing incredibly well to have infinity times the results!
Beyond that, Go certainly doesn't have the same backing from Google as C# had from Microsoft, on the other hand Microsoft had a monetary incentive to provide support and tools/frameworks as they charged for those proprietary implementations while Google is giving Go away under a permissive licence.
Anyway, for fun I looked at the language poll made here recently on HN and compared C# and Go:
C# 1130 likes, 465 dislikes Go 1126 likes, 365 dislikes
So it would seem that Go has reached the same popularity as C# here on HN atleast. https://news.ycombinator.com/item?id=6527104
Which doesn't seem to matter anyway. There are tons of languages released every year that fare even worse than languages released in 1980, despite having "ubiquitous-internet, Github and widespread blogging" at their disposal.
Those tools are force multipliers. If the initial force is zero, the output is still going to be zero.
Anyway the hype is surely not the reason why anyone should use go. People should use go because it has good libraries, encourages good interfaces, is fast and space efficient, has good self documentation, is easy to test, etc.
Who's to say that a similar thing isn't happening with the current latest and greatest tools?
There was and continues to remain NOTHING that compares to the Java platform.
Java can do stuff and people use it which is fine. The con was that it was inherently portable and secure and can be used for client software. None of that is true. Today if someone told me that our new client interface was going to be java that person would be reassigned to a role where their awful judgement would not resurface.
Java today is basically the slower edition of C++ which isn't that amazing of a niche.
It is inherently portable, because the bytecode can be run everywhere you have a JVM. You don't need to compile for every platform you wan't to run your software in, or muck around with cross-compilers. True, you can do plattform-spesific things in any language, but the Java standards library is almost entirely cross-plattform. In this way, Java really is as cross-platform as it gets.
The language itself is more secure. Buffer overflow? Forget about it. Undefined behaviour? Forget about it. Wierd stuff happening due to pointer arithmetick. Forget about it. Memory leaks? Forget about it, (well, almost).
Why can't it be used for client software? A JVM language can be used for anything that doesn't require minimal use of memory or short start-up time. Any program you write that will be running for more than 10 seconds and don't run in a memory strained environment, fits Java rather well.
Java is also easier to learn and reason about IMHO than C++.
Java today is the easier, safer, more portable but slower and memory-hungry edition of C++. Which is why there is a hype. Altough that hype is slowly dying, due to Java (the language, not the vm and ecosystem) being outdated compared to it's competitors.
This part I have some issues with: the language is still quite modern (compared to C, for example). There are several other reasons for its slow demise: its licensing issues and initially problematic Linux implementations put it at a disadvantage on the server side and in circles where open source was important. It is quite verbose and not well-suited for web development - not the best proposition at a time where scripting languages and rapid web prototyping were on the rise. Finally, the enterprisey orientation of later developments around Java and heavyweight ecosystem really put off beginners - editing XML (build.xml bigger than the whole program...) sucks.
C is supposed to map very easily to what actually happens under the hood. Thus C will never have closures, type-inference, generators and the like as a part of the language. This is a part of the languages design, which is why you shouldn't compare it to feature rich languages like Java or even C++.
There is nothing wrong with hype if that hype is warranted, and Java certainly has an unmatched track record in terms of delivering solid, portable and easy to maintain code bases that power millions of applications today.
> The con was that it was inherently portable and secure and can be used for client software.
Java hasn't been pitched for client software since the death of applets, circa 1999.
Java is so good in so many domains that it's easier to name the areas where it's not the best: graphical applications and CPU intensive programs (games, numerical calculations). That's about it. For anything else, Java is most likely to be a very solid default choice.
... today. Thrownaway2424 said (my emphasis) "Java in the 90s was a spectacular con job that millions of developers and managers bought hook, line, and sinker."
This was true. Sun purchased Java's popularity. It did not even come close to living up to the hype in the first few years. I could segfault it without much difficulty using Swing, and I was hardly using it for anything (school assignment!). I was not a sophisticated developer at the time. I should not have been able to do that.
It is also true that through tenacity and dedication, Java eventually did live up to its promises. But that came later.
XML is still the right tool for the job for many use cases. JSON is great for serializing data structures. XML is great for marking up various types of textual data.
Other people have already covered your comment on Java.
We need the structure that JSON can't give us and other data markup languages are too obscure to teach them to everyone we work with.
In the 90s, before Java, you had C/C++ dominating server based code that wasn't COBOL (Smalltalk tried to compete, but it's failure is a whole different story), with BASIC/Delphi/PowerBuilder/OracleForms/arguablyMFC dominating UI based code.
I will grant that Java gained a lot of buzz due to Java Applets in the browser and with deceptive claims regarding how portable AWT and later Swing applications were. But for server side business application coding (NOT systems coding), Java blew C/C++ out of the water.
C++ on large projects, especially with the feeble template compilers at the time, had insanely long compile/link times. It wasn't unusual to kick off a build and have to wait an hour or more to be able to test it. It's true you could break things up into dynamic libraries to try to reduce link times, but that meant more work, especially if you had to run on different platforms. And there were specialized tools like ClearCase's ClearMake that could speed things up, but they were far from commonplace.
Java for server based code compiled quickly and eliminated the link times (well, it moved linking to runtime, but effectively it also made each class into it's own mini shared library). And Java stack dumps were orders of magnitude more useful than C/C++ core dumps. Performance was slower compared to C/C++, but faster than interpreted languages at the time, and generally "fast enough" for most business applications.
Java's JDK also provided a lot more "out of the box" functionality than what you had with the C++. Heck, even just having a standard String class was tremendously more useful than having to deal with char arrays. And the collection library was feeble, but it was there. (The C++ STL wasn't released until 1998, and RogueWave was probably the closest thing to a de facto C++ library, but it was a commercial product).
The rise of internet e-commerce also convened to help Java out. A lot of sites started with cgi-scripts, which had to launch a new process for every CGI request. Even C/C++ CGI programs were slow because of this. Java's servlet spec provided a very convenient way to run multiple requests in a single process, which was typically at least an order of magnitude faster than CGI at the time. And it was much easier to write servlets than to compile a custom Apache C/C++ module into your apache distribution.
And for as many headaches as Java caused for "cross platform" UI code, it actually worked pretty well for cross platform server side code. Gone were the spaghetti pragmas from cross platform C/C++ code.
So what happened with Java is that the applet/UI buzz got in through the enterprise door, but it's server side conveniences are what enabled it to gain tremendous enterprise acceptance. And IBM jumping on board the Java ship was somewhat of a green light for COBOL shops to move to something else that was still blessed by IBM.
>> XML was pretty big back then, too
XML really didn't come about until the late 90s and was really more of a 2000s buzzard. It's being rightfully replaced by JSON for a lot of browser/server interactions, but for better or worse there are still quite a few places that it's sticking around.
There WAS an industry in 1987 and people who are around now were also around then, and can compare how well Go does compared to how well C++ did circa 1987.
Hopefully in 4 years when Golang developers are in demand, I have 4 years of experience under my belt. :)
These skills will transfer very well into other programming languages.
It may be better than Python for some kinds of large applications programming, I don't know. But since a lot of apps do need the simple scripts and the application logic, it's kind of nice to have them all in the same language - which is one place where javascript may take over more, I suppose, if ever they can convince OS designers to build node.js tools into the default installs...
Oh really? Checking every single function call for an error return code doesn't complicate things?
It's more than unfair since they don't show any numbers. At all. Not for Go, not for Java, not for anything.
The graph is cute but it's not even a number of installations, projects on githubs or lines of source code: it's Google searches. Searches measure nothing more than buzz. I bet Google Wave showed similar curves facing up for months.
If the Go team had hard and impressive numbers, I bet they would show them. The fact that they don't makes me think that Go is not seeing a lot of traction, besides a few Python and Ruby programmers.
Has anyone come up with a good solution to this? Preferably using Vim tooling.
:Drop fmt
:Import fmt
However, it doesn't impact whether I enjoy writing Go code or not. It tends to be mitigated by blessed built in types and functions with parametric polymorphism (e.g., `map`, `[]`, `append`, `delete`, etc.) in addition to Go's structural sub-typing and type embedding. First class functions help too.
Actually, this results in a really nice aspect of Go that I've come to appreciate: reading and writing Go code tends to have very little cognitive overhead. Things tend to be very straight-forward and clear. I'm not sure if this is because there aren't generics, but I have my suspicions that it is. The language itself and its semantics is very simple and can fit in your head easily. But this is my experience, YMMV.
Dirty little secret: sometimes I cheat a little when writing small commands in Go and sacrifice compile time type safety by using my `ty` package.[1]
[1] - http://blog.burntsushi.net/type-parametric-functions-golang
The problem is Go lacks immutable data structure. I believe everybody know why immutable data structure is required. Go slice and map are all mutable-only, so to make some read-only data view, we need to write all the containers by hand. Amount of code increases exponentially.
It would be great if Go had such a immutable slice/map stuffs, but they decided not to have that due to legacy compatibility issue with existing []byte/string(which is actually just an immutable view on []byte) types.
So now the only hope is generics. I don't want to write hundreds of same list/map classes just to offer immutable views. That's all duplicated works, and I just want ability to write List<T> and Map<T>.
If you don't think immutable data structure or view is not important, Go is good enough to you. But that feature is crucial to me, and that's one of the biggest reason of why I stopped using Go.
I got a half-working solution [4] with a lot of interface{} and some reflection, but upon speaking with some of the Golang devs, the consensus was "this is not something you do in Go." From what I understand, you're expected to build a custom memoizing function for each set of datatypes you're expecting to use it for (which admittedly is not a ton of code), and generic helpers are not advised.
I can't say authoritatively whether "Go needs generics!" or not, but life has been much easier after porting my code back to Python—though a large part of it was because it was a fairly dynamic webapp which is still a pain point for Go. I hope to give Go another try soon, probably for a different project.
[0] https://pypi.python.org/pypi/dogpile.cache
[1] https://pypi.python.org/pypi?%3Aaction=search&term=cache&sub...
[2] https://pypi.python.org/pypi?%3Aaction=search&term=memoize&s...
[3] http://docs.python.org/dev/library/functools.html#functools....
To me, it just seems ugly. I like a type system where I know what a type is at each point, and there isn't some ugly "catch all" type that you can use when you run out of other options, which effectively just throws away all type information (and this is what interface{} does, as everything implements it).
public T Get<T>(int id, string cacheKey) {
}
In Go, you have to return an interface (and ideally an error)
Here would be the equivalent,
v, err := s.Get(id int, cacheKey string)
if err != nil {
//Handle error here
}
if v == nil || v.(*models.User) == nil {
return nil, http.StatusNotFound
}
interface Fooer {
func Foo()
}
type Bar struct {}
func (s Bar) Foo() {}
func (s Bar) Baz() {}
func DoFoo(f Fooer) {
f.Foo() // fine
// f.Baz() compile error
f.(Bar).Baz() // fine
}If you want a Bar specifically (as the DoFoo code does above), it should take a Bar as an argument.
If you want to accept any struct that satisfies Fooer, add all the methods to Fooer that you need them to satisfy...
Doing otherwise is just subverting the type system and you might as well use a blank interface and effectively have no type checking on your input - if you require a Fooer and then typecast someone might pass a Fooer and get a nasty surprise when it doesn't work.
Yes, that is one of the reasons I eventually moved to D.
And the rise of interest in "golang" in general seems to correspond to the massive spike in China [ http://i.imgur.com/Y3oO2jf.png ].
I'm not really sure what that means...
Also, in my experience, very few (mainland) Chinese play weiqi. Everyone plays Chinese chess, but very few play Go. So people searching for "go" are quite likely searching for the language. (Although I'd expect that the people who know about the language know enough to search for "golang", so who knows)
http://www.meetup.com/Go-London-User-Group/events/147685182/
Don't worry about the waitlist, people always drop out nearer the time.
Yeah I was been ironic but go is quite a nice language =)
Ok, so now I really have to attend next year's FOSDEM.
After compiling Android a few times, though, you'll appreciate what the Go team was talking about when they said C++ compilation time was a driver for them.