21–30 of 297 posts
"Why Go is not Haskell"
"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…
Because generics are important.We're not talking about crazy C++ templates here but a more rigid feature that would still make Go language more expressive.
Or why expose this interface {} feature and allow people to use it in a statically typed language?
People who chose Go obviously want type checking (along with CSP that makes go so awesome), or they would be using something else.
One thing that is perhaps counter intuitive is how you do a lot of for loops compared to other languages (Compiled/Statically typed included). Once you let go your previous expectations, Go gets a lot nicer to use. The amount of for loops you will write will also makes it obvious when you start doing O(n^2) operations in your methods. Same can be said with variables declaration and error verifications in Go. They are…
Yeah, it seems like a lot of the criticisms of go boil down to "I don't like writing simple loops".
One thing that is perhaps counter intuitive is how you do a lot of for loops compared to other languages (Compiled/Statically typed included). Once you let go your previous expectations, Go gets a lot nicer to use. The amount of for loops you will write will also makes it obvious when you start doing O(n^2) operations in your methods. Same can be said with variables declaration and error verifications in Go. They are…
This compiles:
package main
import "errors"
func main() {
f()
println("hello erroneous world")
}
func f() error { return errors.New("boo") }"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…
I think this is a mistake. A lot of business is run this way, though.
Although 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…
1. Dropwizard is not a minimal web service library, it's a minimal web service framework. You could've used just a library, for example this[0] one, and be done in 10ish lines boilerplate that you fully understand.
2. That would also mean you wouldn't need Maven or any XML configuration. Just a bash script or a Makefile that invokes your compiler.
3. There's 3 ways to deal with global variables in the world. The first is plain allow them, and let everything go to shit when two threads access them at the same time. That's how most languages, including Java, do it. The second is allow them, but never allow more than one line of execution at the same time, this is how many scripting languages like Javascript and Ruby do it. The third is 'not' allow global variables at all, and instead only expose shared state through mechanisms that explicitly deal with concurrency like pipes/messages/locks, this is how Haskell and other pure languages do it. (There's also STM, but that's a bit more complex)
Once you know which of the three your language does, you'll know exactly how to deal with it. No need to be uncertain about it.
0] http://docs.oracle.com/javase/7/docs/jre/api/net/httpserver/...
Earlier quoted context omitted.
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 technologie…
Go is the most boring language I have ever coded in, and that is why I love it. Sure, it doesn't have some fancy bells and whistles people seem to want, but when you can sit down and write something functional, portable, and readable fairly quickly, I'd say that is a huge win.
One thing that is perhaps counter intuitive is how you do a lot of for loops compared to other languages (Compiled/Statically typed included). Once you let go your previous expectations, Go gets a lot nicer to use. The amount of for loops you will write will also makes it obvious when you start doing O(n^2) operations in your methods. Same can be said with variables declaration and error verifications in Go. They are…
One thing that is perhaps counter intuitive is how you do a lot of for loops compared to other languages (Compiled/Statically typed included). Once you let go your previous expectations, Go gets a lot nicer to use. The amount of for loops you will write will also makes it obvious when you start doing O(n^2) operations in your methods. Same can be said with variables declaration and error verifications in Go. They are…
> ... error verifications in Go ... you understand by reading your code the places where error can occur or where you decided to ignore errors (By using _) This compiles: package main import "errors" func main() { f() println("hello erroneous world") } func f() error { return errors.New("boo") }