I've just recently started playing with go and I think the most impressive part is how close you can get to a dynamic language development feel without sacrificing the benefits of static compilation, speed, binary distribution, etc.
There is a lot to love about go and it is very quickly starting to look a lot more interesting than other languages like ruby for future projects.
And for people who want to "level up" their programming skills and get an excellent language for writing servers in with a great faculty for safely concurrent semantics:
How is deployment with clojure? I haven't used either, but deploying golang programs looks incredibly simple, whereas JVM wrangling (which I last did years ago) was never fun for me. Does either one support erlang-style hot code swapping?
JVM deployment is a little more involved, but due to the use of the virtual machine, can allow for hot code swaps. However, this isn't cleanly baked into many application architectures, so YMMV.
A lot of people just clone their code to the server and do "lein ring server-headless", (lein is the clojure build tool) which starts the server.
You can also package all your code and its dependencies into a single jar, then copy that jar to your to your provider and run it.
It's pretty easy basically, and more advanced options are available, but even if it was more involved, I think the benefits you get with Clojure are big enough that I'd be willing to put up with quite a bit more difficulty than there is.
You might be over-rating the usefulness of code hot-swaps in production with Erlang. Erlang devs I've talked to have looked a little green in the gills when I asked about it.
Coming from Python and Ruby, being able to just deploy a jar is a dream.
Python has packages ("eggs", although the term has multiple meanings, I'm unaware of good unambiguous name to things you host on PyPI or alikes). You put your code under a certain conventional directory structure, write simple setup.py file and, well, that's about it.
(Although, as I happen to use mostly Debian-based systems, I prefer not using Python packages directly but build .deb out of them with stdeb and use system package manager to deploy. Just dput the built package to company's private apt repo, and Puppets pull the update.)
Eggs are incomplete, broken, don't really solve the entire problem, and don't even solve the problem they were designed to solve.
It's a mess, there are multiple factions and implementations, and until people started consolidating there were 4-5 concurrent popular approaches to packaging Python libraries.
I've lost tangible shards of my sanity to Python packaging and some of my poor coworkers are fighting the terribly useless fight regularly still to this day.
Worse, most Python projects that have any non-trivial dependencies usually entail NumPy, SciPy, or Cython.
Have you ever packaged something that's using multiple C and Fortran dependencies for automated deployment? It's horrific.
Meanwhile, back when I'm at home and I use jBlas or any other Clojure, Java, or Scala library here's what I have to do:
Add dependency to project.clj:
[bulwark "0.0.3"]
Ship the jar.
lein deploy $maven_repo
Writing Clojure code at home is incomparably more pleasant not just in pure code, but in all the accouterments and tooling as well.
Tried the language recently. Wanted a in-memory data structure that could represent a filesystem-like graph. Ran away when I understood (please correct me if I got that wrong, but I wasted a whole weekend and found nothing) that it's either totally type-unsafe void*^H^W interface{} all the way or I have to write my own separate implementation for every and each type of graph I'll use, without any significant way to reuse code.
The types of your nodes probably don't have much to do with any algorithms you may be writing. Consider your algorithms as functions which act on an interface. Keep your graph data within a type which adheres to that interface. Then you only have to duplicate the type and not the algorithms, and you can easily create new types which the algorithms can use.
Even if you stuff the algorithms into the same type you have your data in (like most generic languages seem to encourage you to do), you still only have to type-cast/type-switch on getters and callbacks. And the only major missing requirement I can think of is that your nodes aren't guaranteed to be of homogeneous types (and you can hack that with a callback if you want).
> "The types of your nodes probably don't have much to do with any algorithms you may be writing."
Which is precisely why he wants generic types.
> "Consider your algorithms as functions which act on an interface."
How would he write a function that explicitly expects a graph whose nodes contain ints, and not, say, strings? What kind of interface would that function act upon?
> "you still only have to type-cast/type-switch on getters and callbacks."
Although I'd prefer to have generics, the issue isn't obvious. Generics can be really hard to understand. For example here's a HashMap in Scala:
class HashMap[A, B] extends AbstractMap[A, B] with Map[A, B] with MapLike[A, B, HashMap[A, B]] with HashTable[A, DefaultEntry[A, B]] with CustomParallelizable[(A, B), ParHashMap[A, B]] with Serializable
If that's what the type system is going to end up being with generics I'd rather just cast things. Sometimes less is more.
I don't know Scala but the very basics of the language, however notation seems clear.
Class HashMap is parametrized over two types, A and B (presumably, key and value types). The rest seems to be implementation details, that play no importance unless you're going to actually use them. Just as integers are totally ordered, but unless you have use to that fact (i.e. comparing those integers), you can safely ignore that.
Same as with interfaces - if there's a interface Foo { ... } somewhere, you don't have to care your types implement it unless you're actually using it.
One problem with that idiomatic Scala code is that all inherited traits have to be declared in the same place, making the definition conceptually "too loaded". (Scala's implicits allow for something more flexible, akin to Haskell's type classes, though.)
That suggests a problem with subtyping (or, rather, with inheritance as construct for implementing subtyping), not with generics. Parametric polymorphism is a most natural notion.
Without generics you'll need to use an alternative approach. As you said you can use interface{} everywhere. Another option is to create an interface that does what you need. Checkout "sort" for an example: http://golang.org/pkg/sort/#Interface.
Sure, I can `type Tree struct { Child []*Tree; Node NodeType }`, where `NodeType` is either `interface{}` (makes `Tree` reusable by sacrificing type safety) or some concrete type (sacrifices `Tree`'s reuse) but that's about how far I can progress. Also, I have to manually ensure that only one of Child or Node is set, but not both.
I just can't do anything like `data Tree a = Leaf a | Node [Tree a]` there.
(Edit: okay, my mind swayed a bit, that was trees, not graphs. I had different ideas on data structure to use, and my memories are a bit messy. Sorry about this. The problem should still hold, it applies to both trees and graphs, and I think many other data structures too.)
The 'one of Child or Node' isn't really an issue since you probably shouldn't expose the members of the struct (the tree should be accessed via methods). But I agree with your point about containers.
I think he already covered both, the second with "or I have to write my own separate implementation for every and each type of graph I'll use, without any significant way to reuse code".
Have you given Rust a try? As far as I understand, it supports generics and defining your own data types pretty well, although I've never tried Rust myself.
Rust's polymorphism system is somewhat limited compared to, say, (GHC) Haskell. But, to the best of my knowledge, it is the best among languages aiming at mainstream.
> "Strongly typed (with dyamic casting)"
> "while Go is statically typed, it has a strong system for dynamic casting and reflection".
This is not even wrong. The whole point to using types is to make strong guarantees about the meaning of programs without even having to run them. Dynamic casting and reflection destroy the usefulness of these guarantees, by virtue of their semantics depending on information only avaluable at runtime. Strong typing with dynamic casting and reflection is like a safe knife whose handle is a blade!
> "Really good at concurrent stuff, pretty fast"
Give me a break. Concurrency support is all about compartmentalizing the use of resources as much as possible, reducing sharing between the concurrent units of computation (processes, tasks, goroutines, whatever you want to call them) to the bare minimum required for the program as a whole to serve its goal. How does Go's shared memory model help in this regard? This fundamental inadequacy has negative consequences both for correctness (synchronization is a convention, it is not actually enforced) and for performance (Go needs a stop-the-world garbage collector).
===
Go might have been barely interesting ten or fifteen years ago, but in 2013, this kind of design has to be rejected as mediocre.
I don't know why you're being down voted. Your points are completely valid. Without Google's name behind it, Go would not have had all this hype around it.
Fanbois hate it when someone points at the flaws in their favorite language. I still cannot comprehend why. As much as I like Haskell and Standard ML, if someone pointed out their flaws (Haskell: lame module system, needing arcane hacks to selectively introduce strictness; SML: no open sum types, no applicative functors even when generative ones do not make sense), I would not take issue with that. Realizing our tools are not perfect is the first step to improving them.
I have nothing against Google, but their programming languages (at least, the ones that I know of), Dart and Go, are really mediocre and uninspiring. For all their bad reputation, Microsoft at least has F# and is indirectly involved in the development of Haskell. Even Microsoft's take at an objected-oriented language for the uneducated masses, C#, is much better than the Google- and Apple-endorsed alternatives (Java and Objective-C).
For people who use go in production; what do you use for database abstraction and mapping ? I found several "ORM" but either they throw static typing out the window, or they seem to be way overblown in what they try to do (ending up dictating how some of the data has to look in the database), I look only for a database abstraction (which db/sql doesn't provide), does a good one exists ?
Division by zero in floating point is well defined and useful, and does not produce a runtime exception. So why is this a compile time error?
Edit And it produces the wrong result for division by negative zero: http://play.golang.org/p/DKoVG0Vlaf It should be -Inf, not +Inf. Go's floating point math is whack.
Does it only throw a compiler error if you use 0 as a constant? Let's say you have a function that returns an int; does it force you to check if that int is non-zero before using it in division?
It can only throw a compiler error if you use a 0 literal (or constant), because it cannot determine the runtime value of a variable denominator at compile-time (obviously).
It does not force you to check, but if you wanted to "catch" the "exception" (really, "recover from the panic"), here's how you would do that. Note that this is admittedly a somewhat unidiomatic use of recover(): http://play.golang.org/p/dAQ01dus9Y
For others: note that that's only because Queue29 assigned 0 to a variable before using it as the denominator, so there's no way for Go to catch that at compile-time.
If you divide by a literal 0, this is a compile-time error, so there's no panic (and no need to recover()): http://play.golang.org/p/E0jSDAHwtg
Assuming it's not a division by constant zero that's caught at compile time, it panics. Go's panic/recover system seems conceptually similar to try/catch and exceptions, but they aren't a drop-in replacement for exceptions due to some differences in both style and execution. There's a good blog post[1] on the Go blog going into more detail about defer/panic/recover, if you're interested.
"This isn’t a language for use in UIs or game clients, but it is an extremely competent language for making servers, infrastructure or parallel/distributed processing systems."
Golang has a GUI tool kit: the "net/http" and "html/template" packages. While I personally hate EcmaScript with a passion, I have to admit every single GUI tool kit or windowing system I've worked with had serious fundamental design flaws not unlike JavaScript and the DOM.
The entire scenario is not unlike the Tcl\Tk days. People will bitch and whine but will do so while using it until something better comes up.
There sure has been a ton of Golang hype lately. At the risk of being downvoted, just wanted to add my 2 cents: seems obvious to me that Google's PR team has been in full motion on Go lately. At the very least, there are quite a few Google fans active on HN routinely pushing Go. Which is no problem of course.
I just find this somewhat frustrating given that we also have the massive NSA surveillance scandal unfolding. Because I'd like to think that intelligent, free-thinking hackers would opt for using products & technologies from companies & organizations not so directly, deeply, and intricately involved in said scandal.
Anyway, kudos to Dan for his detailed article - I'm sure he could care less about the political alignment of the corporation he is getting his tools from - and really it should be about technology first; so if Golang fits his needs most optimally then by all means that's what he should be using. Just saying, don't forget about the alternatives ;)
FUD. What proof are you referring to that Google is "directly, deeply, and intricately involved in said scandal?" Should the industry drop C++ (Microsoft) and Java (Oracle) support or similar (Scala, Python, etc)? AMD and Intel processing? All American companies; completely ludicrous.
And there is plenty of other reading material to review regarding Google's history with the NSA (see my other links posted in the nested comment below).
Perhaps I should not have said "directly, deeply, and intricately involved in said scandal" in the tone of 'matter of fact' - because it is indeed an opinion, but I'm just drawing what I feel are logical conclusions. IMO Google is the NSA's primary Trojan Horse into the free market. I am in no means declaring this as fact, like I said originally - just wanted to drop my '2 cents' if that's OK.
It goes deeper than that. You are suggesting that intellectual, free thinking and Google can't coexist, or to work AT or WITH Google is to be not intellectual nor free thinking. It's ludicrous to label Google employees and users. You would suggest that Robert Griesemer, Rob Pike, Ken Thompson, and those Google employees that publicly deny your FUD [0] can't be intelligent, free-thinking hackers. Crazy.
I believe you're taking my comment out of context. I shared 'my 2 cents'; an opinion - and did not label Google users or employees. I apologize if you found my comment rude, but I clearly intended it to be taken with a grain of salt.
For the past ~68 days or so, this is literally the only thing you've talked about here. PRISM NSA PRISM PRISM NSA. Whatever floats your boat, but please stop trying to inject politics onto programming threads.
In all fairness, before today my last comment was 46 days ago. And before that there are only handful of comments regarding this issue - looks like all within the same week of the NSA news breaking.
Anyway, next time perhaps I can simply write an article and submit it as a separate thread; rather than speaking out in the thread itself. Thanks again.
I really think it should be about the technology first... I have seen a lot of the same sort of opinions hold back adoption of Mono for projects, because .Net itself came out of Microsoft. Java is now owned by Oracle... so does that mean we should get to migrating all those Java applications off of that stack too?
Hell, NodeJS is backed by Joynet.. does that mean I shouldn't use that platform since I don't plan on hosting with Joyent?
I think it's pretty important to at least try to keep the politics out of certain technology decisions. Sometimes it may well become important, sometimes it is less so.
I think it's unnecessary to feel frustrated. "intelligent, free-thinking hackers" can make their judgement on a technology if they are given complete information about it, which is the case here since, as pointed out by the other comment, Go is an open source project.
My understanding is that Go is an open source project, of which the main maintainers are employed full-time by Google specifically in order to improve the language and make it more useful and used within the company itself.
Sure, perhaps it could be said then that Go is similar to that of Android. Which is the prime example of one of Google's 'open' projects that has done wonders for its' industry. Yet given the NSA's surveillance scandal and Google's long history of a close & secretive working relationship with the NSA - today perhaps we should be questioning whether or not we are still comfortable using an Android device. Or programming with Go.
Neither of these articles prove anything like the kind of claims you're making. I'm concerned about PRISM too but I've yet to see any evidence that Google is any more willingly complicit in it than any other US tech giant.
That's a good assessment, I don't disagree this is or that there is even any 'hard proof' but at some point some of us will make a conclusion about things with the information that is available. To play devil's advocate: I have not seen anything to convince me that the Google is not a key component of the NSA's mass surveillance efforts.
And indeed, other tech giants should share the blame for being involved in PRISM - I tend to single-out Google because of their long & documented history in doing business with the NSA and other intelligence agencies like the CIA.
Never understood the kind of people who wont believe obvious things without first seing a smoking gun on the hands of the culprit and/or a written confession.
I guess it's what passes for valid to the politically naive.
Indeed. Put it this way, if you suspect a serial killer has taken residence in your neighborhood - are you going to wait around for a 'smoking gun' before making conscious decisions about your interactions with that individual?
So what's your alternative if every single one of your neighbors is a serial killer?
Like I said, I share your concerns about PRISM but singling out Google seems like losing the forest for a tree when we have abundant evidence that all the US tech giants have been forced to comply with NSA requests.
There's always another town. And likewise, so many alternatives to Google tech - and all solutions provided by the other 'giants'. Besides, this is an industry driven by technology & innovation. If there isn't a solution or an incumbent is dropping the ball - that's opportunity for geeks like us.
Besides that, why give them the benefit of the doubt anyway?
I have no qualms about singling out Google. Of all the 'giants' this is a company that has the most volume, quality, and relevant information on all of us. They need to be held accountable & scrutinized to the highest degree in the handling of said data. The fact that they are the company most active in their business relations & engagements with the intel sector should be ringing alarm bells.
I think its more that go is a useful language alternative to say using C, or dynamic languages. Recently more and more people are catching on to this. Its like rails in 2007ish in feel to me.
Also we can't constantly deal with the NSA, we do have work to get done and things to learn.
There is a lot to love about go and it is very quickly starting to look a lot more interesting than other languages like ruby for future projects.