101–110 of 192 posts
I'm primarily a mobile dev, so the biggest impediment to me adopting Go over Node is the fact that converting and manipulating my data models to send as JSON documents is considerably harder on Go - there's no Go equivalent to Gson yet, nor will there likely ever be due to the nature of the language.
I'e been writing my first production-sized Go app over the last few months, and really enjoy it. Some observations: - The standard library is solid, and I was surprised how well-rounded and mature the third-party library support it. Coming from a Python/Ruby background, that was nice to see. - I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see…
> I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system. I've found it to be practical and easy to use. Go doesn't have generics. To someone coming from a language like Rust, saying that your type system doesn't have generics is like saying your car doesn't have wheels. It's just considered non-negotiable.
However, I still think the out of the box performance is great and for problems that don't require generics it is a very good option. I especially like the static compiling feature that makes deployments more straightforward. Handling HTTP requests and performing routing, dispatching requests to other services reliable async way is the biggest use case for me using Go. It can totally be written in any other language(Rust), if using generics is a must.
Earlier quoted context omitted.
> I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system. I've found it to be practical and easy to use. Go doesn't have generics. To someone coming from a language like Rust, saying that your type system doesn't have generics is like saying your car doesn't have wheels. It's just considered non-negotiable.
> saying that your type system doesn't have generics is like saying your car doesn't have wheels. To overburden an analogy, it'd be more like complaining that your tank doesn't have wheels[0], or your hovercraft. Go takes a different approach to the same problem (in this analogy, getting from point A to point B). But really, this is a rather tired flamewar that gets beaten to death literally every time a post about G…
Go doesn't take any approach to writing generic code at all.
For me the single biggest disadvantage of Go against Node.JS is the lack of a decent dependency management solution. NPM is awesome and Go doesn't even have a "meh" answer to that.
NPM is only awesome until you need to do something with it on Windows.
I'm primarily a mobile dev, so the biggest impediment to me adopting Go over Node is the fact that converting and manipulating my data models to send as JSON documents is considerably harder on Go - there's no Go equivalent to Gson yet, nor will there likely ever be due to the nature of the language.
Would you mind if I ask what did you find lacking in Go's json package when compared to Gson?
[1] http://golang.org/pkg/encoding/json/ [2] http://www.attilaolah.eu/2013/11/29/json-decoding-in-go/
I'e been writing my first production-sized Go app over the last few months, and really enjoy it. Some observations: - The standard library is solid, and I was surprised how well-rounded and mature the third-party library support it. Coming from a Python/Ruby background, that was nice to see. - I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see…
> - Go is a minimal language and has been called boring. [2] I don't claim to be an expert yet, but I don't think I've reached this level of productivity with a language this quickly before. I was drawn to Go initially because of its promises around concurrency, but this is why I stayed. Within less than a month, I was as productive in Go as I was in Python, despite the fact that I had been programming in Python for…
Earlier quoted context omitted.
Or just build your furniture without using screws, like in Japanese carpentry. When people are already having a decent time building things using the tool, it looks pretty stupid to tell them they've done it all wrong for years in all the decent products they made.
Parametric polymorphism gives safety guarantees that you can't easily obtain without language support. For example if you have a function typed "forall a . a -> a" you know it has to be the identity function (or something that bypasses the typesystem, like infinite loops or a runtime exception).
1) Methods with names that indicate the parameter types. 2) Method calls on objects to convert some internal struct data from one type to another. 3) Something I haven't thought of that doesn't involve losing a handle on your type.
So there is certainly a loss in convenience, but if you use the type system it can be just as safe as a functional language as far as I can tell. So, yeah, it isn't as intellectually elegant, but it also isn't really that hard to deal with.
Theres a lot of good stuff, created by good people, in those languages and while the solutions are great, the fact that they are in those languages, make them unfit for a lot of cases.
I wish a language with advanced types like Haskell or OCaml would have the same tooling and ease of distribution around it that Go does. I haven't built anything in Haskell/ML in a while, so if anyone has any updates on this please chime in.
OCaml is usually statically compiled with ocamlopt, so distribution is pretty easy. As long as build/deploy platforms match, then you're good to go. Shared libraries only come into the picture for unusual cases, eg FFI. OCaml tooling has also gotten a lot better over the past few years, mainly because of OPAM. The library count has exploded, and the language still gets regular point-releases with improvements designe…
(My favorite example is when in #ocaml I asked what testing tools people used; the most positive answer was along the lines of "there's OUnit, but I don't know anything about it".)
There seems to be three awkwardly coexisting OCaml communities: the old academic crowd, the Jane Street people, and a crowd of clueless newbies like myself. It's a really great language, but the ecosystem is going through some growing pains right now.