Everyday hassles in Go
crufter.com
Everyday hassles in Go
1–10 of 297 posts
Re: Everyday hassles in Go
#2Although i'm still very unsure about rob pike's argument that go don't need generics since it has interface, a recent experience :
After having implemented a mini web services in go and being fed up with its limited type system, i decided to stop coding in go and start recoding my project in java using what is often advertized here as the most minimal framework : dropwizard.
Well, i downloaded the framework, configured maven, started the hello world tutorial, and quickly found myself dealing with 2 xml files, 1 yaml file, multiple classe files ecerywhere, and couldn't get the whole stuff work immediately.
Then i realized that my golang implementation was already working, and that i completely understood my code and its potential performance characteristic, without having to have deep knowledge about the jvm internals, things like sevlet containers, or how the whole stack would deal with my global variables in a multi-threaded context. All my code was just one simple program.
My temporary conclusion right now is that golang type system is indeed extremely shite, but that if what you need is to develop simple yet efficient web services, it doesn't matter that much.
Re: Everyday hassles in Go
#3"Every computer language is an imperfect way of describing a potential solution
to a poorly understood problem" -- Me
I find it interesting when people wax poetic about how one language is better than another and how if we just did x, y or z then we'd have this perfect solution.
That said I appreciate the author's write-up of some challenges with Go. In the end the reality of any "product" is building what the user's need not what they ask for. That said I do worry that the Generics argument seems to be slowly approaching a religious war that will distract people from the other enjoyable aspects of Go. Worse yet it may calcify the Go development team in a way that will keep them from addressing the basic issues that generics might help solve. Either way Go is just another computer language and I'm happy to use it often to solve problems I'm working on. That said I use a lot of computer languages every week when I'm working on stuff, none of them are perfect and my solutions to the underlying problems are fragile and constantly evolving as the problems unfold. This is the nature of our business, to constantly do battle with poorly understood problems using imperfect tools in a world where we are fooled into thinking everything is black and white because at the core of our technology everything is a 0 or a 1.
"One Computer Language to bring them all and in the darkness bind them".. LOL
Re: Everyday hassles in Go
#4Agree with a lot of this, but I find the lack of any punctuation one of the most confusing things about Haskell code.
Map String Any
map[string]interface{}
Re: Everyday hassles in Go
#5"Every computer language is an imperfect way of describing a potential solution to a poorly understood problem" -- Me I find it interesting when people wax poetic about how one language is better than another and how if we just did x, y or z then we'd have this perfect solution. That said I appreciate the author's write-up of some challenges with Go. In the end the reality of any "product" is building what the user's…
Languages may not be perfect, but language features can be compared, and some features are strictly more powerful than others.
There is scope for legitimate criticism of language design based on the expressive power^1 of their features.
In this case, generics would make Go strictly more expressive, as, without it you must write O(n) more code or perform a global refactoring to simulate it.
1. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4...
Re: Everyday hassles in Go
#6Agree with a lot of this, but I find the lack of any punctuation one of the most confusing things about Haskell code. Map String Any Is that a function call? A type declaration? What's a parameter to what? The go style map[string]interface{} is, much as I love to hate on all things go, much clearer.
The reason Map String Any does not contain any special symbols specific to that certain type is because it is not a built in special type like the Go map[string]interface{}.
It is just a regular type parametrized over two other types. And kinda that is the point - being expressive enough to describe a map type without explicit support.
Re: Everyday hassles in Go
#7Agree with a lot of this, but I find the lack of any punctuation one of the most confusing things about Haskell code. Map String Any Is that a function call? A type declaration? What's a parameter to what? The go style map[string]interface{} is, much as I love to hate on all things go, much clearer.
There's nothing a priori clear about punctuation like [ ] { }, you're just used to seeing lots of syntactic markers.
Re: Everyday hassles in Go
#8Although i'm still very unsure about rob pike's argument that go don't need generics since it has interface, a recent experience : After having implemented a mini web services in go and being fed up with its limited type system, i decided to stop coding in go and start recoding my project in java using what is often advertized here as the most minimal framework : dropwizard. Well, i downloaded the framework, configur…
I don't think Java will get many defenders here. But try that in Scala, with Spray. There're a couple of lines of boilerplate to create the actor system, but that's about all. And you get a system that's flexible enough to let you write route definitions that look like a config file, but everything's typesafe. Your routes are just functions, you can refactor them like ordinary code. So too are the kind of "cross-cutting concerns" like authentication or async calls that you'd have to either have built into your framework, or use some kind of "magic" (AOP, monkeypatching) to add to all the methods where they were needed. https://github.com/spray/spray/tree/release/1.1/examples/spr...
Re: Everyday hassles in Go
#9Although i'm still very unsure about rob pike's argument that go don't need generics since it has interface, a recent experience : After having implemented a mini web services in go and being fed up with its limited type system, i decided to stop coding in go and start recoding my project in java using what is often advertized here as the most minimal framework : dropwizard. Well, i downloaded the framework, configur…
I have to say that I am tempted by Go precisely because I see a lot of comments like yours, namely, it seems just to "work" in a very simple way. I find myself somewhat overwhelmed by the avalanche of new language opportunities I am supposed to invest time in. Most seem to have this huge kitbag of functionality and they seem to merge into each other making it quite confusing which I should go to, and with technologies such as the LLVM it seems to me we're only at the beginning of the new language storm, where every CS postgrad wants to create a new language that does everything. Go seems to have a very clear and unique proposition in this environment: sparsity. This seems to me to be a very good differentiator, and to the extent that the language were to move towards all the other languages and try to add features, I personally would be disappointed. This is not spoken at all as an expert in Golang, quite the opposite. I simply love the clean imperative aspect which Golang seems to have and is why I am very tempted to learn it.
Re: Everyday hassles in Go
#10Agree with a lot of this, but I find the lack of any punctuation one of the most confusing things about Haskell code. Map String Any Is that a function call? A type declaration? What's a parameter to what? The go style map[string]interface{} is, much as I love to hate on all things go, much clearer.
There's nothing a priori clear about punctuation like [ ] { }, you're just used to seeing lots of syntactic markers.
Sure. But many languages have a standard way of defining what's a function declaration, what's a function definition, what's a type definition, what's a function parameter, what's a type parameter, what's a function call, what's a type instantiation; it doesn't really matter what the specifics are, what matters is that there are standard indicators that stand out from the code (and I think there is a sense in which []{} are a priori more visible in the middle of a paragraph than letters are).
Haskell doesn't seem to have that; any piece of Haskell code tends to look like a smooth surface of words separated by spaces. Function? Words separated by spaces. Type? Words separated by spaces. Instance? Words separated by spaces. There are no visual handles to latch onto, nothing to help you realise how this stream of words separated by spaces forms a tree structure (AST).