Go is great and all, but I'm really only using it until Rust is ready.
What are your criteria for "ready"?
A year with Go
61–70 of 235 posts
Re: A year with Go
#62Earlier quoted context omitted.
Other languages like Clojure, Python and even Javascript are catching up to Go and are adding decent support for concurrency too. But I would definitely prefer a functional language for a project that involves a lot of concurrency. "not a functional language" is a weird requirement.
Are you talking about Clojure? :) I am not sure what is the fuss about functional vs. imperative, you can do both in Clojure, both ways have a place in the programming toolkit. I think about functional programming as a philosophy. Nobody is going to despite me if I use swap! in Clojure or I use a mutable variable. On the other hand even when I am in an imperative environment I tend to use functions that keep the stat…
Yes Clojure, sorry about the typo! The difference is that with Haskell or Erlang you get hard guarantees about side effects, but access to imperative libraries is very difficult. So you are kind of locked in a small ecosystem.
With Clojure, Scala or F# you need to be disciplined and don't really get many guarantees, but you can reuse lots of imperative code.
It kind of depends what your priorities are, if it's correctness or development speed.
Re: A year with Go
#63Earlier quoted context omitted.
HN was the same about Node too. In a year we will see the same articles about Rust.
See also: AngularJS, Rails, etc. A lot of this is just because things that a technology makes convenient fade into the background after awhile because you know longer feel the pain you felt before you had them, but you are actively reminded of the things that annoy you about a technology multiple times a day. For example, with Go, fast static compilation and "just works" deployment fade, while the copy-paste-tweak pa…
The thing you want is called "getting old". You realize the benefits of certain things and know about the weaknesses before they are even brought up. Sadly this can't easily be taught - it is just slowly learned. And yet us old farts continue to be shunned in many parts of the industry (perhaps because we are grumpy old curmudgeons who have seen it all before).
Re: A year with Go
#64Earlier quoted context omitted.
It's an upgrade in terms of compile times, deployment simplicity, conciseness, concurrency, etc. Some people care about such things.
Compile times are largely irrelevant if you use something like JRebel, Play, Tomcat or the many other frameworks that support hot reloading. And Java is far broader and more flexible at concurrency than Go with libraries like Quasar, LMAX Disruptor and the many HFT contributed ones. Let's also not forget that Java is significantly faster, has every library under the sun, has a dependency system that actually makes se…
Adrian Cockcroft does and I don't disrespect his opinion even though I'd far rather functional languages won the developer mindshare myself.
We shouldn't be under-selling how light the Go footprint is. In the long run it may be one of the few languages to compete with unikernels.
Re: A year with Go
#65I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…
In some ways, this is correct. Go is much more simple and consistent than Ruby or Java, has a better deployment story, and better tooling in some ways. As a language, it's much less enjoyable to write. Yes, the concurrency primitives are much better, and that's a good programming tool. But to a developer coming from Ruby, code is often needlessly repetitive and obtuse to write. It ends up being overly verbose, full o…
"code is often needlessly repetitive and obtuse to write."
I think it helps to remember that Go's use case is a lot of teams interacting to produce fairly large code bases, i.e., at Google. I'm getting into it for my job because it has the same use case, and I find it hits a nice sweet spot in what you can do, vs. what you can't do, and I happen to be in a position in which I am routinely hit hard by other people's "clever" code. I don't do my personal coding in it, though.
Part of the problem with the "clever" code is that it often uses the clever features, but, wrong. Like, all the pain of seeing someone do something "clever"... and you'll note how I keep scare-quoting that... and none of the benefits. If the clever code was actually more concise and performant than my generally-non-clever replacements, I wouldn't mind so much, but it's amazing how often I rip out a "fluent" API or something and replace it with something simpler, faster, and still results in several hundred negative lines on the commits.
I've developed a theory that it isn't even because the developers are "dumb" or something, especially since in many cases they manifestly are not. I think it's that once you pass a certain size of organization, but are still sharing some code bases, you encounter an increasing number of instances where a developer has to fix something in the shared code, parachutes in to make the minimum possibly change that might work with the minimal cognitive effort, and gets out and back to their own code as quickly as possible. The net effect in such situations is that even if your code is being written by nothing but senior devs with decades of experience, from the point of view of the code being developed on it might as well be being bashed on by a series of above-average gorillas bashing away on keyboards.
Languages that tend to point you at a single right answer, and confine the very busy, very distracted gorillas from beating on the code too hard, and make it obvious when that's happening, can be advantageous in those cases.
No, that's not every case, but it's a useful one.
Re: A year with Go
#66Earlier quoted context omitted.
Or because it does satisfy much of the Kay criteria for OO and encourages such programming styles.
Nobody follows Kay's definition of OOP. And I bet you're going to say "But he coined the term!". Yes. He's still making up his own definition twenty years after the industry gave its own, so whatever he says on the topic is moot.
Several things to note here.
Firstly, I don't know at what exact point did Kay come out in demystifying OO (1998 or so?), but the design principles of Smalltalk and messaging date back to publishing in 1974, with many references to it afterwards.
Secondly, the idea that there is one singular definition of OO that the industry has standardized on is absurd. Object models differ semantically from language to language, even if some general motif of "encapsulation/inheritance/polymorphism" is present (though again, important subtleties abound - is encapsulation enforced or merely convention, how structural and nominal subtyping are modeled [mixins], etc.).
But would you say that's the definition of OO? In fact, Kristen Nygaard who was the creator of the Simula language, an ALGOL extension, and now considered to be the first OO language (semantically in that it beefed up structs and other procedural nuances) considered object orientation to be a property of any system in general as opposed to language constructs. Thus, Erlang definitely does count as OO under that, too.
So what definition do we follow, then? Who do we trust?
Apparently this is a difficult problem: http://c2.com/cgi/wiki?DefinitionsForOo
But by all means, Erlang embodies many OO design principles by certain important taxonomies - both Nygaard's and Kay's. If you're going to reject both, then you're going down murky waters.
Re: A year with Go
#67I always find it's difficult to navigate Go repositories on GitHub. Because there can be several source files under a package it's difficult to look for an implementation of a function or method. For Java, I can easily guess where the methods are by looking at import statements.
I friend of mine wrote a tool to fix that. See http://gotools.org/github.com/kjk/fofou for example (just prepend http://gotools.org/ to any Go import path).
Then you can use Ctrl-f (Cmd-F on mac) search built-in browser to look for things.
It doesn't work for large repositories but most of them aren't.
Re: A year with Go
#68Earlier quoted context omitted.
> IDE's Lack of an IDE is a feature not a bug. Edit: or it is a symptom of a feature. No one has written one yet because they are happy with what they have. > tooling Do you mean you need an IDE that speaks the language to write anything efficiently? Do you mean your first day on the job is spent setting up tools? Wrong philosophy in my opinion; I could imagine something better.
Having tools that can spot errors early, help you track them down quickly and help you comprehend, organize and refactor your code can be very useful with a large codebase, and I don't think it's fair to characterize that as "you need an IDE that speaks the language in order to write anything efficiently."
Like gosublime?
Re: A year with Go
#69Earlier quoted context omitted.
Are you talking about Clojure? :) I am not sure what is the fuss about functional vs. imperative, you can do both in Clojure, both ways have a place in the programming toolkit. I think about functional programming as a philosophy. Nobody is going to despite me if I use swap! in Clojure or I use a mutable variable. On the other hand even when I am in an imperative environment I tend to use functions that keep the stat…
Yes Clojure, sorry about the typo! The difference is that with Haskell or Erlang you get hard guarantees about side effects, but access to imperative libraries is very difficult. So you are kind of locked in a small ecosystem. With Clojure, Scala or F# you need to be disciplined and don't really get many guarantees, but you can reuse lots of imperative code. It kind of depends what your priorities are, if it's correc…
> The difference is that with Haskell or Erlang you get hard guarantees about side effects, but access to imperative libraries is very difficult.
In my experience creating Haskell bindings to say imperative c libraries is pretty easy. What imperative libraries have been hard to access for you personally?
Re: A year with Go
#70> I also, apparently, don’t understand Go’s pointers (C pointers I understand fine). I’ve literally had cases where just dropping a * in front of something has made it magically work (but it compiled without one). Why the heck is Go making me care about pointers at all if it is a GC’d language? Well, sorry, but if that's your level of understanding after one year of Go, I'm furious I wasted time to read your article…
As I understand it, GO makes it so you can use both a pointer or the object itself to access it methods. And when you define an object method (or I don't know how it's called when you do this:) func (*string) uppercase(){ // make uppercase } Then by saying you use a pointer means you will modify the value when you do this: mystring.uppercase() So it's not really pointers, it's more an idea of pointers.
Things get ugly when your code grows. I had cases where I started with passing pointers to structs around directly, but at some decided that having dedicated interfaces would be better.
But as soon as you're talking interface, pointers don't work as expected anymore, because Go (at least that's how I'm explaining it in my head) passes magic interface values to functions. So you can't just change `func foo(s MyStruct)` to `func foo(s MyInterface)`, but rather you probably want `func foo(s MyInterface)`. Even though you are still explicitely passing a pointer when calling foo() and whatever you're doing with s inside of foo() is working on a pointer -- which your own function declaration doesn't even tell you anymore.
This is one of the things that confuses the hell out of me when using Go.