New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Do you code in Go?
raindog308
Administrator, Veteran
in General
I looked at Go when it first came out but the libraries were immature...that was several years ago though and now that I check back it looks like it's at a "batteries included" level.
The multithreaded model looks awesome...and of course pissing away days of time learning yet another programming language is fun. Then again, it's not like I have needs that Python/perl/php can't satisfy.
I'm more interested in server programming than anything desktop or mobile, which I think is Go's strength.
Thanked by 1Chronic
Comments
I feel very strongly about Go the same way I feel about Erlang: it seems to be popular because other people tell you it should be popular. I'm sure there's a reason for it, but then again, I'm also not sure why C wouldn't fill the void either.
It's neat, but why reinvent the wheel?
What wheel do you think it has re-invented?
It feels like someone took a few different langs, mashed them together to make one hell hole.
Indeed, that's the point of it. One of the stated goals is to be "powerful without the complexity of C++". We already have things for that:
Web apps: Python/PHP
System apps: C, or python/perl, depending on your mindset.
I can think of a company that has Erlang in their "stack" image on their page, only because it's what RabbitMQ is written in. A company that at their size should really be using bespoke daemons instead of mangling other people's work into what they need. I guess it's working for them, but it would just be best to scale smarter, not scale harder.
Anyway, the point here is that instead of going with a single language and hiring a single team of people to maintain things in that language, there seems to be a strong accordance in modern development to use pre-packaged things, even if having N-level of languages means you then have to hire N-range of team members to be able to effectively manage your mess. The alternative is enjoying a pipe dream and hoping that out 7+ billion people on the planet, you're going to find enough people to effectively manage your range of glued-together packages.
Go is a decent compromise of the fast prototyping of Python and the performance of Java without the ridiculous memory usage that Java uses.
But I am passing on learning Go for Nim (http://nim-lang.org/) which feels like Python but compiles to C (gcc), C++, and Javascript. It's far more portable than Go is since gcc is available virtually everywhere. Plus Nim is way more prettier/pythonic.
I like Go quite a bit, and we use it at MNX.io. I found the transition from Python to Go very intuitive.
We still use both Python and Go -- but sometimes Go makes more sense for our usage.
If you are not frustrated by dynamic typing, multithreading, and dependency management in Python/Node.js in the types of applications you are developing, then I don't think Golang will help you much (although learning another language is always helpful to some extent, you can get a sense of a different paradigm). To me the biggest benefits of Golang are:
IMO the closest thing to Golang is Node.js. The languages themselves are very different, but they are both well suited for writing higher-level systems applications. So if you are coming from Node.js background, you'll find it easy to understand lots of the design decisions in Golang. Correspondingly, if you haven't touched Node.js (practice of server-side JavaScript programming is older than Golang, although interestingly Node.js itself is not), then there's a good chance that Golang won't be what you're looking for.
What makes you feel that way? Golang is an extraordinarily simple language compared to Java, JavaScript, PHP, Python, or C++. Each language feature is carefully considered before being introduced. This is why for example they haven't provided generics functionality yet, they say they haven't found a good way to implement it and don't like how it is done in other languages. It can be pretty much summed up as: interfaces, structs, functions bound to arbitrary types, goroutines, channels.
Also, how much experience do you have with programming in Golang? Before you've written a few small applications in a language, I don't think you can get a good feel for it.
gccgo exists. Nim does look cool though.
I have to confess that one of the most appealing things about Go is that I'll never ever have to read code with opening braces on their own line. God I hate that...and I know half the world hates it the other way and I realize there are arguments but, still, I hate it.
Really compared to Javascript? That's one of the lowest level languages you have in that list.
Might need to check this out, but I love Nodejs so much..
That's true, there are not that many language features in JS. I'd say it's comparable then, but only if you don't count built-in stuff like JSON/Math/etc. Also prototype is a bit convoluted, Golang instead has you declare functions on pointer types (there's no support for inheritance though, instead should wrap the functionality, but I don't think people use prototype for inheritance in JS much either; but Golang interfaces are still very useful).
I like Node.js too. But still, it won't hurt to play around with Golang, you can love multiple things
With python, I simply use gevent/greenlets. Without this library, I probably would have been looking to move to golang too. Now the only thing that would make me move from python to golang would be if I want the static typing for performance.
There's is inheritance in Go... you just can declare another structs as anonymous fields at the beginning of your struct and it inherits.
Why people talk about things they know so little about.
Inheriting encapsulated fields and methods is not inheritance. It is just a shortcut for implementing it as an actual field, which Golang calls embedding. For example, a parent struct cannot delegate some functionality to be implemented by a child struct. I agree it's similar in some ways and probably a better design though.
You have to understand the origins of Erlang (telecom) to understand it's true usefulness. There are specific scenarios where it's superior to just about anything out there. While it's a bit of a stretch to position it as a "general" programming language, there are frequently good reasons it's used for scenarios where other languages could also technically fit. Size of the company or "difficulty" are generally not reasons you do or do not use Erlang.