Half a decade with Go
blog.golang.org
blog.golang.org
And I pretty much hate the language. I feel like I'm writing in something that combines the worst weaknesses of Pascal and Java. In fact, Mark Dominus' comments about Java (http://blog.plover.com/prog/Java.html ) approximate my experience Go far better than I would have guessed when I started the project I'm on.
People who seem to be smart nevertheless keep talking it up... some not even as just a good tool but as their favorite language.
So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)?
But to your larger point, doesn't any non-programmable programming language exhibit the same weakness to some extent?
Maps, slices, the pre-defined functions.
More powerful languages make no big distinction between user defined types and the language provided ones.
https://groups.google.com/forum/#!topic/golang-codereviews/A...
As discussed elsewhere on this page, Go is not the most feature-rich language out there.
But it does have features that seem to help my solve my problems with a minimum amount of fuss. Like using interfaces liberally, instead of having to define classes. Having lexical closures is also nice.
If you're not working on an application that can benefit from concurrency, you may not see all the benefits of Go either.
What kind of problems were you trying to solve, and how did Go see heavyweight compared to how you'd solve the problem in some other language?
Most of what I've been working on is a Rest API. Here's an example of a problem that felt like it should be something for which I'd be able to write an abstraction to deal with, but turned out to be challenging, at least as a n00b:
https://groups.google.com/forum/#!topic/golang-nuts/JhsiiGHQ...
(Incidentally, though I moved past my then really poor understanding of Go interfaces, I wasn't able to apply the respondent's answer or my new general knowledge to achieve the abstraction I was looking for, and settled for just grinding out the same code for the dozen entities/endpoints it applied to.)
Concurrency: I suspect there's a bit that's hidden in some libraries we're using, and we may yet need to write our own code for some API requests that get processed offline, but I haven't had to explicitly write code for it yet.
If you can think of a specific exercise that might serve to illustrate Go's outstanding concurrency strengths, I'd be interested to try it and compare efforts to another language or two.
I think implementing a simple HTTP proxy might also be a really good exercise, though I haven't done it.
I definitely can't deny that using interfaces instead of regular OO classes takes some getting used to.
Though I don't understand why you had to grind out duplicate code for all the entities / endpoints though. I hacked up things a bit to get it to run on the playground, but as Jesse McNelis wrote, just passing the pointer to foo worked for the code you wrote.
which makes as much as sense as asking
- What about R? - What about GNU DAP? - What about FORTRAN?
for writing a TCP server.
Then you have the option of using Java, Clojure, Scala, Ruby, Python, Javascript or Groovy languages.
The strengths of Go to me seem to be its extensive standard libary and the fact that you don't need to worry about writing elegant code because it's not really an option. That reduced decision making is actually really appealing to me on some level, but it's not enough for me to consider it over what I consider better tools (Haskell, Rust).
I'm currently porting a tiny program a friend wrote in Go to Haskell so we can compare notes, and I think the Haskell is both safer and more elegant, but I'm jealous of the fact that all the libraries he used are from the standard library while I have to evaluate libs of varying quality. However, I would rather put my time in to improving the Haskell ecosystem than using something convenient that makes a lot of decisions I disagree with.
edit: I also think there's value in being a conventional imperative language as someone mentioned below. I with there were something between Go and Haskell. Perhaps that'd essentially be Rust with immutable data structures and garbage collection.
Clojure used to have something called, clojure contrib and it was kind of awsome, it did pretty much everything in just one jar. It was also a huge problem to mentain and everybody wanted to be in contrib, so you had the one json lib in contrib and fasters outside.
With clojure 1.3 it got split up into many diffrent parts and it still servs as somewhat of a community standard or recommended library. Overall its much better and much more usful, but sometimes I miss the days when everything was in one jar on on dependency.
I highly recommend to read this article where Rob lays out the motivation behind many aspects of Go: http://talks.golang.org/2012/splash.article
more code has been written in Go than Haskell, Rust and Ocaml combined.
Powerful languages let you grapple with problems, weak languages first make you grapple with the language before tackling problems. Some people feel like Go gets in the way. I have not written any Go, but I understand both the praise and the criticism.
Powerful languages can cause other issues, but they do enable certain things that weaker languages simply never can.
[Citation needed]
I don't see why that would be true. In my experience, the most expressive languages often produce the most impenetrable spaghetti code. Can you explain your reasoning?
In a language with lenses, you can delimit where your models are mutated. In a language that lets you treat composable effects in a generic way, you can e.g. split up your variables explicitly with ReaderWriterState, making it clearer which serves which purpose.
The kind of things you might be tempted to use "magic" or global variables for in a lesser language - the "cross-cutting concerns" - you can instead handle in normal code as a generic kind of context. E.g. an audit trail can just be Writer. Or actions that need access to a database session can just be another kind of context. I'm working on such a thing right now (see tpolecat's doobie for a public example of the same kind of thing) - whether a function accesses the database or not is visible right in its type, but it's easy to compose functions that do. The types ripple up, and in the end I'm probably going to do session-creation-in-view - but in a principled way, using the ordinary type system, visible in the code - with Spray, my web route definitions are just another ordinary bit of Scala code (whereas in most languages I would define routes in an external config file, or at best a config object a la Django - adding complexity).
Heck, error handling is a perfectly good example of this. In a less expressive language, the only way around the boilerplate of handling errors where they occur is unchecked exceptions (or effectively-unchecked exceptions, as in "throws Exception"). In a language with good generic context support, the possibility of failure is just another kind of context that we compose with the same generic tools as any other, and the control flow becomes something sensible again.
Simple languages led to complex code bases.
Many of the Enterprise Java sins were caused by the language limitations and developers trying to work around them.
Anyway Go has its use cases, and it is already an improvement if less C code gets written.
I have seen this happen in C codebases before Java took the enterprise.
Its own little macro based DSL and pointers that were actually handles for the real data.
I'm repeating myself here, but: A Haskell user and a Lisp user are both sure that they're at the top of the power curve, and they're both sure that they're looking down when they're looking at the other language, and they can both tell you precisely why they're sure they're looking down ("It doesn't even have a decent type system" and "It doesn't even have macros", respectively). But they can't both be looking down. What's wrong here?
What's wrong is the assumption that all languages can be ranked by a one-dimensional attribute called "power".
Or look at it another way: Power? Power for what? Well, for writing programs. But what kind of programs? General programs? I've never written a general program in my life; I've only written specific ones. Then "power" is whatever's going to make it easier to write the program I need to write. Whatever language does that is the "most powerful" language for the problem I'm facing.
What power is Go shooting for? It's the power to write a ten-million-line application and have it be maintainable for two or three decades. (That's not my guess; it's what Rob Pike said the language goals are.) If you face that kind of problem, Go may in fact be a very powerful language.
If you have developed software in go, and after a couple months you aren't finding its saving you time, or at least pleasant to work with, maybe its not for you.
I feel like it is similar to C, but more opinionated, with much less rope to hang yourself, and often things I would have used C or Java, I find doing them in golang saves me plethoras of time.
It is opinionated, but for me the aha moment was after I learned enough of the standard libraries to feel comfortable in the language, I find myself getting things done at lightning speed, and it has performance that is as solid as the jvm in your average use case.
I find the code is also pleasant to read, and the language lends itself to writing verbose, simple code, which I find easier to debug than overly abstracted systems.
This, to me, is what he's missing. On the continuum between readable and expressive, Go falls decidedly on the readable side. If you're working on a project by yourself for 6 months, you might not like Go. But if you work on a team or return to code you wrote 6 months ago and haven't touched since, that's when you'll appreciate Go.
Evaluating languages based on simple solo projects will always favor the more expressive languages, but it's a short-sighted evaluation.
io.Copy(dst io.Writer, src io.Reader)
It reads data from reader and writes to writer... simple. Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). The first way you will probably use it will be to copy between some stream and a file without having to eat up all the memory to store the buffer (not using ioutil.ReadAll for example)... but then you realize you can use a gzip compressor on the writer side, or a network socket, or your own code... and io.Copy works with anything that fulfills its interface.
As you build out a complex application, you start by creating your own functions that take advantage of existing interfaces foo.OCR(dst io.Writer, src img.Image). After that you start building out your own interfaces... like a MultiImage interface that has ImageCount and ReadImage methods that returns the count of images and binary data... but then you realize the images could be big, so you make the ReadImage method return an io.Reader... and now you have gone full circle and are using io.Copy to copy imageX from a stack of images to return to your OCR function that will output the data to an io.Writer which you made actually a gzip writer because text compresses well.
Beyond composition -- obviously, the concurrency and messaging is nice and when you need it vital. The other thing that will help make Go "click" is being very "data oriented" in your design... be vicious and minimal: http://youtu.be/rX0ItVEVjHc (great talk on data oriented design) and be absolutely pragmatic, focus on getting shit done, always...
I'd say it's a better C, not a better C++ (or Java/C#)
For me, most modern uses of C fall into 3 camps:
+ extreme portability
+ complete, low level resource control
+ foundational libraries
And Go doesn't really qualify for any of these. For the latter 2 largely because of the GC.
I think in practice, that its engineering bent i.e. no frills language and high quality tooling, will more likely see it being used in the server-side application/middleware space. I guess not surprisingly.
So it really is up against Java, Python, Ruby and C++ and is, therefore, interesting in that it isn't trying to compete on lingustic goodies.
Yeah, I agree with your points. Which is a shame really.
I read your comment, but this seems more like A sane standard library with proper interfaces and not a language feature per se (also composition to me sounds like the pattern where you create objects which are composed of other objects but that's not what you mean, right)? What you display here can be done in pretty much any language suporting inheritance (or I'm missing something), so your point is those languages don't have io.Copy out of the box?
This means that many standard types in Go implements either io.Reader and/or io.Writer. That's neat. The implicit interface implementation is definitely a language feature, and the libraries are making good use of it.
(That is not to say, you could not do the same in other languages, but you would have to specify the interface they implement rather than just adding a method with a specific layout.[0])
[0] I am not remembering the right term right now.
Close is a particularly good example. One need only look at C#'s IDisposable to see that it does, in fact, work well. A mock might noop it, another class might close an FD, and yet another might make an RPC call.
I agree that interfaces tend to have fairly narrow family tree. And, by this narrowness, there's little ambiguity about what T GetById(id int) means. As the tree expands, which happens with implicit interfaces, ambiguity is more likely. Nevertheless, there's a fairly large common vocabulary that we'd all largely agree on. Closer, Reader, Writer, Logger, etc. Even in more complex ones, I see little risk of confusion, say, http.ResponseWriter. And, something that I've noticed from Go (which I never did in C# or Java), is the tendency to favor very small interfaces, which ends up being pretty awesome.
That aside, consider that implicit interfaces allow the consumer to define the interface. For example, you create a library that has a concrete struct called MyStruct with a method called DoStuff(). You define no interface because you don't need one.
I, a consumer of your library, need an interface because in some cases I'm using your MyStruct to DoStuff and in other cases, I'm using my own implementation. So I create an interface, define DoStuff(), and BAM!, your structure now implements my interface. I don't have to change your code.
Sure, the workaround is to wrap your structure in my own which implements the interface. But how, in this case, is the implicit interface not a huge win?
Maybe, as you say, it'll screw over people who use it poorly. For everyone else, I see no drawbacks.
Haskell's typeclasses work around this by letting you define "how a type implements an interface" at either the definition of the interface or the definition of the type. (Or, strictly, anywhere else both are in scope - but that gets messy for a few reasons, so it's discouraged and GHC warns about "orphan instances" unless you tell it not to.)
That's not a problem with Go's module system. If someone is using your library, and wants to use your interface in a particular package, that's fine. If they want to use another library, with another interface of the same name in another package, that's also fine.
If they want to use both libraries in the same client package, they'll have to locally rename one or both of the imports.
Here's a container interface. It has a sort() method, which sorts the elements of the container.
Here's a different container interface. It's got a method that tells you what kind of concrete container you have, so you can understand how expensive actions like insert and sort are going to be. But the author was from England, and so called that method "sort".
You can see how that's going to (fail to) work out when you define a "sortable" interface...
Traditional (but even more contrived) examples include "draw" and "fire" doing unexpected things when applied to a gun as opposed to an image or an employee.
First, you really have to split this up into two distinct cases.
The most powerful/useful is when you create an interface in your package for a structure in a different package. It's been years since I've done .NET or Java, but I remember frequently cursing a library developer (often someone at Microsoft or Sun) for exposing a concrete type instead of an interface. In this case, I don't see any downside. Creating a:
type Render interface { Draw() }
And then using my (or someone else's) Gun structure, is no different than using the Gun structure directly and expecting it to render itself to the screen rather than come out of its holster. The interface buys you the level of indirection, but whether you use the interface or the concrete type, it's up to you to know WTF Draw() does.
This first approach is well explained at [1]
In the second case, where a library expects an interface, I agree there's a risk:
// 3rd party package package fastRender
type Drawable interface { Draw() }
func Render(d Drawable) { ... }
// my code: fastRender.Render(new(Gun))
I've lost some degree or type checking. Since my Gun's Draw doesn't explicitly implement fastRender.Drawable, maybe I'm trying to fit a square peg into a round hole. There's nothing the compiler can do to help either.
It sounds a bit like an academic concern to me. Is this something that's actually bitten people in the ass? How is it different than any method that takes primitives? I can pass a []byte of a bitmap to a Music player's Play(data []byte) method...
[1] https://medium.com/@rakyll/interface-pollution-in-go-7d58bcc...
There's also a subtle third case - I import two libraries. One of them defines Drawable, the other has something that looks like it implements Drawable. But it's just happened upon the same signature, and makes different assumptions. Maybe it even says it implements Drawable - but a different Drawable defined in a third library.
As I've said all along, I don't know how often these things are hit in practice. I think so far go development has been comparatively centralized, and so it might be seen less often than it would if it were used everywhere, but that might still be rare enough to not be a problem.
It doesn't seem like a high probability that this would happen on accident, though it might be possible to contrive an example.
I'll have to think about that.
One could possibly force the issue by including an unused function with a deliberately unique name (supports_interface_foo, or maybe a UUID or both) as part of the interface. Can functions added later fill parts of interfaces? If so, this approach would make the situation roughly that of Haskell typeclasses. If not, then this approach makes the situation roughly that of Java interfaces. In either case, it might be appropriate to some pickier interfaces.
You could include the name of the interface as part of the method name, though. But the downside of that approach is, if another interface wants to re-use the same method, things get awkward...
My point was implicit, exceptional simple interfaces are sorta magic. They are effortless, and because they are implicit, there is no harm in creating a 1 function interface (or 10 of them). Because your caller is never going to have to do an ... Implements ThingA, ThingB, ThingC, ThingD, ThingE, Thi... it implicitly supports an interface if it fulfills the signature.
So your interfaces end up being tiny (just what you need) and pervasive. This means the way your system ends up working tends to be far more aligned along interfaces than anything else.
When I speak of composition (in this case the composition of functions) I am speaking of the ability to use functions together rather freely and with little effort. This is a bit hard to explain, but it feels a bit like a modern shell, you can wire together lots of commands (functions), from lots of places that have no awareness of each other with the pipe | operator. In Go, simple, minimalistic interfaces act as the glue and let you compose lots of diverse functions together exceptionally quickly.
I've implemented InputStreams from byzantine transport layers in Java that work with the standard library. I don't quite understand what is special about this concept in Go (maybe it's nice for people coming from typeless, messy dynamic languages or nice languages with horribly inflexible and ad-hoc standard libraries like Python and Ruby).
I have used interfaces (or equivalent concepts) in dozens of languages and they always felt like far more of a chore, explicitly using X interface or Y interface, ugly complex declarative specs, etc. Go just makes it painless.
What people like about Go is its mix of features, not some specific one by itself.
If it had Generics that would be another thing.
However, you can wrap an interface{} using container (for example), with type-specific input and output functions, getting back compile-time type-checking. Yes, it is not optimal, and yes, you're still paying the price for type assertions.
If it had Generics that would be another thing.
I would like to see a good solution for this that integrates well with the rest of the language.
I say that because the Go designers, despite having designed a quite mediocre language, suddenly when it comes to generics the want the perfect no-compromises solution or nothing.
Say you have a type that implements the io.Reader, io.Writer, io.Closer and io.Seeker interfaces, eg. an os.File. This type would also automatically implement io.ReadCloser, io.WriteCloser, io.ReadWriter and io.ReadWriteCloser, io.ReadSeeker, io.ReadWriteSeeker, io.ReadWriteSeekerCloser, io.WriteSeeker, io.SeekCloser etc.
And how is that any different than any language with interfaces? (Besides the implicit thing?).
Imagine a close() interface in Java. There isn't one - but having a try {...} finally { x.close(); } can be very useful sometimes. But having interface graphs made of granular interfaces makes everything slow and causes a lot of complexity when you try to think about your type hierarchy. That's why interfaces always just grow and you can't use them any longer because other classes only implement part of the api. Something usable for all of awt, swing, file handling, random foreign libraries? Unthinkable. Also, adding something in a later release (like CharSequence in 1.4) can have a wide ranging impact and requires you to change a lot of code.
In Go, you just add an interface from the union set of multiple structs api - and you can use it. No matter who wrote those structs. The value is enormous. Think of it as something like dependency injection at compile time.
"Duck typing is similar to but distinct from structural typing. Structural typing is a static typing system that determines type compatibility and equivalence by a type's structure, whereas duck typing is dynamic and determines type compatibility by only that part of a type's structure that is accessed during run time."
So it sounds like "duck typing" is defined in terms of run-time semantics. I guess you might be able to have genuine "compile-time duck typing" in a dependently typed language, which could be a good reason to preserve the distinction.
Otherwise, yes, they are certainly similar.
Known as structural typing and available in most modern languages.
Well, "modern" is an ill-defined concept. As far as I'm aware, structural typing is not really that common, is it? Besides OCaml and Scala, is there any relevant (used outside of academia) language that supports it?
F# also supports it, given its ML linage.
C# tricks with dynamic, although in this case it is dynamic typing, so not really the same thing.
Concepts would have fixed this, but we don't have concepts and maybe never will!
enable_if and type traits are a workaround for the time being.
Concepts lite will definitely be in the next revision.
https://docs.oracle.com/javase/7/docs/api/java/lang/AutoClos...
You can even leave out the finally when you use an autocloseable resource.
//r will be closed no matter what
try(Resource r = getResource()) {
} catch(SomeException e) {
}What makes Go my go-to language for certain kinds of projects (I'll doubtless be using it again) is that it gets shit done. It has the brutal simplicity and hardware proximity (and raw speed) of C combined with the small handful of things that most significantly contribute to make Java better than C: A simple type system, garbage collection, usable string handling and dynamic data structures (arrays and hash maps). Go also has a fairly large, useful library.
Multiple return values often including errors make error/exception handling very explicit and in-your-face. When something can go wrong, you the programmer are forced to recognize that and deal with it as soon as the function returns. That's a Good Thing IMO. Java-style exception handling, by comparison, looks to me like an elaborate language hack for passing the buck.
There's a ruthless kind of efficiency in Go's surrounding philosophy. There's one way to format Go code, you let the utility take care of it and never worry about formating again. The compiler won't tolerate various kinds of sloppiness, such as unused imports.
As somebody else mentioned, in Go, writing elegant code is not a consideration because it's nearly impossible. Well, I'm sure there are "better" and "worse" ways to write Go code, but not so obviously that I'd be tempted to give it a lot of thought. So I tend to just sit there and write code by the bucketful until I'm done.
Finally, the tooling gets the job done, and quickly. I can compile for and across various hardware environments and ship executables that don't rely on a JVM or other external dependencies.
Being good enough, not knowing any better PL-wise, and the Stockhold Syndrome explains that.
This was totally me. I am very much a programming language aficionado (or maybe just a dilettante), and when I first read about Go, I dismissed it quickly. I'd mostly been using Lua at the time, and didn't really understand what was different with goroutines vs. coroutines.
After the initial release, it took us a while to properly communicate the goals and design ethos behind Go. Rob Pike did so eloquently in his 2012 essay Go at Google: Language Design in the Service of Software Engineering and more personally in his blog post Less is exponentially more. Andrew Gerrand's Code that grows with grace (slides) and Go for Gophers (slides) give a more in-depth, technical take on Go's design philosophy.
It was Rob Pike's essay that caused me to investigate it again.
I have been quite impressed with lots of little details that have been 'fixed' (relative to C) in Go. Such as how variables are declared, the module system, and much more. And I was and continue to be impressed with the associated tooling.
I hope that if Go has just one lasting legacy in the history of programming, it will be how it pushed forward people's expectations of what a good language ecosystem should provide.
Some people see languages as a bag of features (immutability! generic programming! laziness! operator overloading! algebraic types! hindley-miller type inference! pattern matching! exceptions! manual memory management!). See http://yager.io/programming/go.html for an example of that line of thinking.
Those people won't get Go.
Designing a language is not about cramming every feature you can think of. It's about making good trade offs.
A trade off is: you get something but you also loose something.
I use Go because it made the biggest number of good trade offs.
Or to put it differently: I program in Go because when writing code, it irritates me less than other languages.
If you want a longer explanation of that: http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
“I like a lot of the design decisions they made in the [Go] language. Basically, I like all of them.” – Martin Odersky, creator of Scala.
I don't think anyone would accuse Odersky of being a "blub programmer."
"Beating the averages" is not a very good essay, I don't think you need to drag it in here.
Do I as a Go programmer sometimes wish that Go had feature X. Of course I do! I want that feature when I want that feature. But, I find Go to occupy an extremely practical position in my personal programming language continuum do to its fairly unique mix of features. Note, it is not the features themselves that are unique many languages individually have them. Indeed, they often also include features I miss in Go. Rather, it is the particular mixture which is useful.
EDIT: To respond directly to the Blub article.
Features pg calls out for LISP:
Garbage collection, introduced by Lisp in about 1960, is now widely
considered to be a good thing. Runtime typing, ditto, is growing in
popularity. Lexical closures, introduced by Lisp in the early 1970s, are
now, just barely, on the radar screen. Macros, introduced by Lisp in the mid
1960s, are still terra incognita.
Garbage Collection [x]
Runtime Typing [p]*
Lexical Clusures [x]
Macros [ ]
* Go has some dynamic typing capabilities but nothing like Python or LISP.
Many would consider that a "good thing". It partially depends on what you
are doing.
I can't speak for pg, but Go has many fantastic features and is not a Blub. The features which are missing are not, by and large, features of LISP.
EDIT 2: To add some more fuel to this fire...
pg concludes the article with:
During the years we worked on Viaweb I read a lot of job descriptions. A new
competitor seemed to emerge out of the woodwork every month or so. The first
thing I would do, after checking to see if they had a live online demo, was
look at their job listings. After a couple years of this I could tell which
companies to worry about and which not to. The more of an IT flavor the job
descriptions had, the less dangerous the company was. The safest kind were
the ones that wanted Oracle experience. You never had to worry about those.
You were also safe if they said they wanted C++ or Java developers. If they
wanted Perl or Python programmers, that would be a bit frightening-- that's
starting to sound like a company where the technical side, at least, is run
by real hackers. If I had ever seen a job posting looking for Lisp hackers,
I would have been really worried.
Python Score Card
Garbage Collection [x]
Runtime Typing [x]
Lexical Clusures [x]
Macros [ ]*
* It is somewhat possible through black magic hackery to create an AST level
macro in Python. It is messy. It is cool. It's kinda crunky. And I am not
sure anyone has ever seriously used this ability. It certainly isn't main
stream. Checkout https://github.com/lihaoyi/macropy for inspiration.
Therefore, I believe pg would have been equally worried or almost as concerned about Go programmers as Python programmers.
Rust doesn't do that. Rust expands the macros at compile-time. Integrating the whole compiler into the runtime wouldn't make much sense considering what area Rust is targeting.
It's also recommended to not link a crate that is used during runtime with the compiler or parser because they're fairly big and would bloat your final build by a large amount.
No, that's not necessary at all, with Rust-like macros which are simple pattern->template things. Macros have zero runtime cost.
The strong typing and lazy evaluation of Haskell makes it easy for functions to take only one argument at a time. Although a function could take a tuple parameter, it is usually rewritten to take each component of the tuple as a separate parameter, which makes the strong typing and built-in currying simple, higher structures like monads possible, and a syntax to suit this style. Lisp functions and macros, on the other hand, must be variadic to enable the homoiconicity of the language. It's therefore much more difficult for parameters to be typed, or to curry them. The syntax requires explicit visual nesting.
The poster child of each style, monads and macros, are thus two peaks in language abstraction simply because of these different required foundations of each, and if you, lmm, have achieved Haskell-style enlightenment, then dynamic variadic homoiconic languages are your blub.
I recently needed to dive into a legacy Scala code base which had not been worked on in a year. The engineer who had written it had moved on from the company and no one knew how it worked. The code was extremely difficult to read and reason about. Some of this was do to the programmer who wrote it but some of it was also do to language features. Is it possible write clear and concise Scala? Absolutely! But, the language does not necessarily encourage that style at this time.
Other functional languages I have used include: Scheme and SML. I want to check out OCaml next. I have also played around a bit with F* (not F#).
But to call someone a "blub programmer" does come off as quite rude.
You may be a victim of the Blub paradox. There are many useful and powerful features missing from languages like Go, and many of them (like powerful type systems) exactly address human mistake-making.
https://web.archive.org/web/20091113154825/http://golang.org...
That looks a lot like today's Go. All of the major design decisions were made, distinctive Go concepts (slices, maps, interfaces, goroutines, switching on concrete type, etc.) are all present. Most of the code examples would compile today with only a few tweaks (if any).
Suffice it to say that Rust was not in that state in 2010. It was barely in that state by 2014. Go was released as a beta; Rust was released as a pre-alpha. That isn't a judgment of either language or community.
Rust on the other hand has been a far more ambitious project, with very lofty goals. This has meant that the Rust team has needed to do a huge amount of experimentation and iteration, culminating in the tight set of core semantics that you see in the language today. It's not been an easy journey for the them, but a great deal has been learned in the process, and even if Rust never 'makes it' into widespread usage, its contributions to the field of programming language design will be felt for years to come.
This is not to diminish the efforts of the Go team - they have produced a really tight, polished language, with an excellent set of bundled libraries. All I'm saying is that they weren't starting from scratch, and had different goals to the Rust team. That has meant they could get to a stable language much faster.
However, none of the languages I know of address psychological issues. Does type system reduce mistakes or introduce? Certainly both, don't know which one more though. But the question itself is wrong. It's not the type system who makes mistakes, humans do. And humans have brains. And brains are limited in their ability to do some thing while keeping other things in mind. And if among other things types happen to be present and mistake was made, than one could say types added to that mistake. And if types were not something programmer needed to think than type system certainly didn't add to that mistake. Things are not as simple as most programmers tend to think. Features don't matter how they think they matter. And research in language design was broken since the beginning of times and, sadly, still is.
(if you read "no silver bullet", "out of the tar pit" papers and couple of recent ones on bugs you should get the idea of how bad things are with mistake-making research)
Indeed. And the hallmark of the really good design is to examine the interactions of those features and see how well they mesh together. And what they imply about how actual programs are designed and maintained.
And remember not to equate popularity with quality. We're all using JavaScript because that's what you need to do in the browser, not because it's a particularly good language. (Not that Go doesn't deserve the adoption it's gotten. It's great to see people ditching clunky Python/Ruby/C++/JavaScript stuff for Go.)
This line of thinking serves more to call in to question the engineering and management cultures we have than it does to reflect poorly on Haskell and Erlang, and if it's true that Go's essential strength compared to them is that it is well-fitted to these cultures, that's not particularly flattering, however locally practical it may be.
Maybe Go is fitting into the cultures that succeed, and if that's the case, well it's the better choice, right?
We are. WhatsApp generated a flurry of interest around Erlang. Heroku uses it. I'm sure there are more examples.
Google is at this point already a large corporation and probably already in decline (IMO). The tools they use are optimized for interchangeability of mediocre programmers, not for high productivity from a small team. Go is a perfectly good Java 1.4.
(There's Docker using Go, but I think their whole approach is a bad idea).
We could also look at the open source world. For every riak there are 10 java sucesses of a similar kind.
We'd need to do some real statistics but my bet is that we see no benefit from those languages in terms of success of the business.
But that's not the question, is it? There are a lot of companies succeeding with ruby or node, but also a lot of companies failing with them. I'll bet the strike rate is better for Erlang companies.
(In my limited experience I've seen a 100% success rate for companies that use Haskell and a 0% success rate for companies that use Go, though as you can imagine I don't have a statistically valid sample size)
Go gives you kind of safe concurrency, Haskell gives you actual safe concurrency.
Like these?
https://www.haskell.org/haskellwiki/Haskell_in_industry
https://www.erlang-solutions.com/industries
If people disagree with you, your default assumption should be that they are looking at different evidence than you, not that they are incompetent or stupid.
This is how I feel too. There are countless styles of prose, but some styles are restricted deliberately for aesthetics or practical reasons. I prefer to write prose in plain terms, and Go enables me to write code the same way. Some languages more than others have parts that stick out in odd ways, and add unwelcome personality to my code.
Yet sometimes I wish to put higher concepts into abstract terms, and Go is less expressive here. You can't always shape things the way you want, and you can't build reusable parts with the same flexibility as in other languages. But, when it comes to tinkering and giving form to ideas, I am more productive working with a basic set of LEGO than a box of all the specialized pieces someone may have thought I might ever find a use for.
Programmers liking confortable algol like syntax, and Google pushing it?
Because Google.
In longer form, because Google is big and Go is well-enough-adapted for problems Google has (there may or may not be better solutions, and there may be some NIH factor going on in Google favoring it, but its at least good enough), and because the fact that Google is big and behind Go, that gets it lots of attention and interest and use even in places where it may not be as well suited as alternatives or what it is replacing.
* Lightweight threads with a scheduling and state overhead low enough to run hundreds of thousands of threads at a time.
* Seamless integration with the language, without any rituals or incantations needed to invoke them; you can, for instance, trivially pass closures from goroutine to goroutine.
* A data sharing scheme that makes sense with promiscuous threading ("synchronized" data structures often don't, because they'll end up serializing threads)
Lots of languages have green threads, but not all these properties.
I'm guessing Haskell does? I don't write Haskell, but my impression is that it has everything.
I don't know what "data sharing ... with promiscuous threading" is, but Erlang is functional and immutable, so data sharing only exists in the sense of passing immutable data structures around. Synchronization issues associatied with mutations don't exist for in-memory structures since it's all read-only access.
I don't know Haskell's concurrency tools very well, but I believe it can provide much of the same functionality as Erlang, but the whole OTP toolset is missing — just as it is in Go. (Certain aspects of OTP can't be implemented in Go at all without additional changes to language/runtime.)
For me, Go's big win is that I can finally bring this, the right way to do it, to work, because it's the first time this paradigm is present in a conventional imperative language, not that it is the first in general. Many other languages got it right in theory before Go, but there was always some practical stopper, involving some obscure programming paradigm that I stood no chance of getting buy-in on (from engineering or management) or an ecosystem that simply couldn't be reasonably be called production-ready across the set of tasks I needed to accomplish. Go finally gave me almost everything I wanted for work. If it isn't everything, well, that's life sometimes, you know?
Java is a blue collar language. It's not PhD thesis
material but a language for a job. Java feels very
familiar to many different programmers because we
preferred tried-and-tested things. do_stuff() ->
GetAnswer = fun() -> 42 end,
spawn(fun() -> io:format("The answer is ~p\n", [GetAnswer()]) end).
I've, been programming for 20+ years and I look at that code and say what the f*k?
Ooh, it's the functional stuff. Ok, move on.
Let me take you through it:
do_stuff() ->
function do_stuff() { ... }
do_stuff() -> a, b, c.
function do_stuff() { a; b; return c; }
GetAnswer = fun() -> 42 end,
var GetAnswer = function() { return 42; };
spawn(...)
fun() -> io:format("The answer is ~p\n", [GetAnswer()]) end
function() { return io.format(
"The answer is ~p\n", [GetAnswer()]); }
Complete version:
function do_stuff() {
var GetAnswer = function() { return 42; };
spawn(function() {
io.format("The answer is ~p\n", [GetAnswer()]); });
}
The thing is, the syntax we found nice is usually nice because it's familiar. Many languages could seem like an incomprehensible mess if you're used to C-style brace syntax. But that's purely a question of familiarity. If you don't know what all the bits and pieces mean, you're going to be alienated by it. A developer who has grown up on COBOL and Forth will not find JavaScript syntax familiar any more than you find Erlang syntax familiar.
I suggest stepping out of your comfortable protective shell and trying it out. It's not rocket science. After 30-60 minutes reading this book you'll no longer find it alien, I bet:
But in the end it doesn't really matter that much. Go and Haskell are completely different languages for different purposes (getting stuff done in regular companies vs. doing interesting PL research or more advanced development in companies with little turnover.)
We actually have transactional and non-transactional channels as well, which is pretty cool.
Also the reason for using STM instead of channels is that they compose without the possibility of deadlock. You can have deadlocks with channels.
1. Totally, definitely. The new Haskell IO manager in GHC 7.8 completely blows this out of the water. It's wonderful.
2. You fork or async IO procedures which can be considered immutable values in their own right and passed around without the slightest concern. There is a small difficulty in that Haskell's laziness makes it a small trick to ensure that work gets done in the right place, which is undoubtedly a mark against Haskell, though perhaps not a huge one.
3. Things like STM, MVars, and (now) LVish let this happen in all kinds of ways. The only problem might be picking the right option due to the wealth of choices. Fortunately, the right answer is almost always STM.
I'd be more than happy to translate a task to demonstrate these things.
Go will still outperform Haskell by a huge margin and the typical Go process will have a much smaller memory footprint.
I don't even like Go, but nobody choosing Go is realistically considering Haskell as an alternative.
7.4, last time I checked.
goroutines are certainly nice and CSP is a good mental model for solving many problems, but I don't think a feature like this should be used to justify switching to a whole new language.
Don't believe me? Make a go block in core.async and have it call another function, then have that function block. Do it 10,000 times. I'll wait. And wait. And wait. And wait...get the picture?
Clojure has this in Pulsar, which is a library...that happens to perform bytecode modification to support this (which I consider to be on the same level as special support from the underlying level). Pulsar is an absolutely amazing project and I'm not trying to take anything away from it with this comment, but merely trying to illustrate how far off you are.
If you think this isn't important, I will point out that Rust has been frantically trying to look more like Go and less like garbage in every release. Or, I will also point out that the Elixir project exists, which basically does the same thing for Erlang.
Simplicity - the main feature is all the interesting things they left out.
It's not suitable for writing an OS, hard real time, highly generic libraries, or GUI programs. Within its niche, it's far better than the alternative, which is usually C++. Just the fact that it eliminates buffer overflows without running slow is enough to justify it.
There are lots of problems with Go. The concurrency isn't safe. The lack of generics forces overuse of reflection and "interface{}", Go's all-purpose type. The lack of exceptions forces far too many lines of "if err != nil { return err}", (or worse, a goto) which takes 3 lines of text every time. The "defer" mechanism is clunky. Lots of modern bells and whistles, from functional programming to generators, were omitted. Other than the lack of safe concurrency, those things don't cause operational problems in your data center. They just require more typing by the programmers. That's an acceptable cost. It beats spending time in a debugger.
If I could go back in time, and discuss one thing with the designers, it would be to fix this.
I'd rather see some kind of Option type (like in Rust) baked deep into the language. Maybe there would be a scheme where you could use these Option types as regular values. The moment you try to use one of them that is actually an error (trying to pass it as an argument to another function without inspecting it first for example), it causes your current function to return an error.
Or something like that. Maybe that's a language design change that isn't going to be worked out in a social media post.
The "defer" mechanism is clunky.
I like defer. Open a file? Defer close it right afterwards in the code. Bam, done! That's nice, and works even if there was a panic deeper in the call stack somewhere.
The idiomatic way to do that in Go, however, can mask errors, like say if Close() returned an error, you might not see it if you just did a 'defer foobar.Close()' Those errors should go somewhere... somehow.
You can, of course fix that, by wrapping your Close() in an anonymous function that logs an error if Close() had a problem. But I don't see that often in other people's code, and it is cumbersome. There ought to be a better and more concise way to do this.
I've seen another way to do it, that works with current Go, in a redis client [1]:
- Function 1 returns rawarg, error where rawarg can be anything
- You want to transform arg into some type, so you create a function that takes a rawarg and an error and returns your type and an error
- In the implementation of your 2nd function, if err != nil, return it directly
This way, as a library user you can just chain your calls without the tedious if err != nil (it will be taken care of in the library).
This might not scale to huge programs, but there certainly is a way to reuse this idea.
[1] https://github.com/garyburd/redigo/blob/master/redis/reply.g...
The golang team has done a fantastic job. It is now my primary language of choice to get things done.
2 years ago I started playing with it moderately, and now in the past 12 months or so it has made its way into my normal workflow and have been delivering completed projects in golang.
I am excited for the next chapter in golang. Keep up the good work!
Most of my work involves building server applications. I have deployed 4 golang apps this year. One is a pre-caching system that concurrently queries a bunch of mysql servers and caches data into redis. Another is a replication system from couchdb to postgresql, and the other two are slim restful api applications that sit in front of elastic search.
The tooling is excellent. A lot of thougt has been put into making things simple. From the folder structure to the final binary, everything is smooth.
It's just a shame that the language design itself is quite behind the times. Older languages had a lot to offer to a new one. The day it launched it was already old. And I don't see a lot of goodwill to change the language to fill the glaring omissions.
Python in this respect is quite an example : iterators, generators, ABC were carefully added without making any less approachable. It prooves it is possible, but that the kind of things the Go leaders apparently simply don't consider.
They have a long way to go on tooling; however, getting to say that is a luxury, due to just how "right" golang has been for systems work. Golang has been amazing to work with, and has just been stupidly productive. I miss debugging (gdb) and generic compile tools like tup, but that's about it!
[0] https://github.com/derekparker/delve
[1] https://groups.google.com/forum/#!topic/golang-nuts/bmsFE3dQ...
A convenient way to do that is ask people to type 'make'.
Platform examples: Host (Cobol, PL/1), Unix (C), Embedded (C), classic Windows (C++, VB), .NET (C#, VB.NET), Java EE (Java), Android (Java), ... Rails (Ruby), PHP (PHP), Browser (JavaScript).
The choice is always between platforms, not between languages. Languages without linking to a platform (Go, Python, Scala, D, Rust, ...) have little chance to succeed.
No, because a language is not (just) a technology, it's a community, and as such, people invest their identities in it. If possible you make an enlightened choice about joining a community that shares your ideas and values and is doing similar kinds of work to you, so they are producing libraries and documentation and hosting relevant and interesting conferences. I often feel that people who lash out at other languages, are people who have come to regret their own choice of community.
In practice is not like I don't have space for 1MB
But I still want proper linking to a shared "golib"
However for Go's current platforms, I would call it a non-issue. Static builds, something seemingly long forgotten though supported in other compiled languages, make deployment and distribution that bit easier.
I would support static builds by default, optional dynamic builds.
And maybe in another 5 years, people will stop bickering over whether that description is/was appropriate. :)