Statically typed languages impose unnatural hardware-oriented constraints on your business logic - It forces you to spend extra time and effort to make sure that your logic is in a format which the compiler can understand. Yes, this can sometimes help you to find silly errors in your code at compile time (and thus occasionally save you a bit of time) but, unfortunately, that occasional benefit doesn't make up for the…
Everyday hassles in Go
141–150 of 297 posts
Re: Everyday hassles in Go
#142I couldn't agree more with this article. I did some Go a year ago and liked it. Then coming back to it a year later after having done some functional programming in Clojure, it's not just the lack of generics that disrupt my flow but also having to think about all sorts of imperative programming details like naming and creating variables and scope placements in cases that would otherwise be unnecessary in a functiona…
Re: Everyday hassles in Go
#143"Why Go is not Haskell"
While I understand your comment, I have to disagree. Programming languages should be kind of boring, and support the average developers' work. That is why Haskell will ultimate fail and fade away - most of the developers on this planet are simply not skilled enough to touch any of that stuff. Attempting to add all Ninja concepts to a language will just lead to a massive failure. Go does a very good job on forcing eve…
Furthermore ... Go ... succinct ... elegant ... using reflection as an alternative to generics ...
In my experience Go is neither succing (if err { ... } one-statement if err { ... } one-statement if err { ... } one-statement). It is extremely inelegant because due to the confused sequence of statements it isn't possible to keep your thoughts on what the method is doing, as there are constant error handling concerns everywhere (or regrets/TODOs about error handling to be completed in the future ...)
Is this
(if this doesn't refer to itself or the sentence it's in, return that information to the caller manually so he can ignore it)
somewhat
(if the above statement is not and adjective you have a problem with your understanding of english, report to the relevant authorities)
unclear
(if un doesn't result in the reversal of the meaning of the word clear, we have a problem and should inform the main sentence interpretation routine that understanding is flawed)
perhaps
(missing error checking)
?
(if the above is not punctuation, report back that your browser is probably not using the correct character set)
Using reflection as an alternative to generics is horrible in lots of ways, but just mentioning a few : no type safety (not even a decent verification you're passing the correct number of arguments). It's extremely long code, full of edge cases (such as arrays being a value type and slices being a reference pointer despite differing only in a single character). And it's sloooooooooooooow. As in ruby slow.
And you forgot Go crashes. If you think C++ error messages are long, you haven't seen a nil-pointer dereference in Go.
Re: Everyday hassles in Go
#144Earlier quoted context omitted.
You know you could replace "Go" with "Java 1.0" and your comment would still be accurate. Funny that.
This is old and tired. Go has a ton of features java 1.0 didn't. Hell, go has features java 1.7 doesn't (possibly 1.8, but I'm not as familiar with it).
A couple of areas where it really falls down though are that Java 1.0 lacked the emphasis on tooling which is golangs greatest strength and added a goal of "write once/run anywhere" which at the time seemed very important but now adds a lot of baggage.
Re: Everyday hassles in Go
#145type JSON map[string]interface{}
Go ahead and use the json.RawMessage type instead:
http://golang.org/pkg/encoding/json/#RawMessage
Not even going to wade into the lack of generics war, still very happy without them and going on a full year of Go usage.
Re: Everyday hassles in Go
#146Earlier quoted context omitted.
Best joke in the industry: "Code reuse!" Cracks me up every time. ;-) We fall for those words over and over again. But in reality, sadly, reuse almost never happens. Maybe one day, maybe even in the next project...
Like c's 'libc', or C++ boost, or pythons 'requests', or... Lots of code reuse there that depends on generics.
Re: Everyday hassles in Go
#147Earlier quoted context omitted.
Ridiculously simple and wordy . Exactly the stuff the computer should do for me.
I think editors solve that problem pretty well. I usually only have to type something like "fo" part of my collection name and another or 2 before I get down to business, no matter what language I'm using.
The longer the piece of code one has to read, the easier it is to read it incorrectly, miss a bug, or introduce a bug.
Re: Everyday hassles in Go
#148Earlier quoted context omitted.
The majority of the programs do not really need to guarantee latency. That being said, it is well known that Golang's present GC performs poorly. It presently fails to free memory in certain cases, and has pretty high overhead. There is work done on improving the GC to be fully concurrent, but that is still probably still 2-3 major versions away.
Where does it fail to free memory? As of 1.4 the GC is fully precise. Concurrent GC is in the works, and is scheduled to be in 1.5 (August of this year).
Re: Everyday hassles in Go
#149Earlier quoted context omitted.
> I am looking for a replacement programming language to solve small problems for which Python/Ruby would have traditionally been used, good file system, stream and networking APIs, but concurrency as a first class citizen, garbage collected, fast startup time. You just described Go, mostly. I can't think of a more fitting language given your stated requirements. To your first point: I don't know what Go has to do wi…
Yes, I did describe what Go is good at, that's because I am trying to find something to put it against for what I use it for currently. Let's say I prefer Haskell's syntax/approach. Coming from Go, what could I be missing in Haskell?
Also, you get the full power of Visual Studio (they recently changed it to be completely free), which can really help with productivity in my experience.
Re: Everyday hassles in Go
#150Wanted to say, you can potentially do better than this in go for arbitrary JSON: type JSON map[string]interface{} Go ahead and use the json.RawMessage type instead: http://golang.org/pkg/encoding/json/#RawMessage Not even going to wade into the lack of generics war, still very happy without them and going on a full year of Go usage.
If it doesn't, then you just use json.RawMessage to defer unmarshalling, but you can still dispatch to a finite number of structs that represent the universe of possible responses.
[0] And no need to write it all out by hand - if you have a single example JSON response, you can generate it automatically: https://github.com/ChimeraCoder/gojson