5 ms·
Perhaps I've never hit the problems that go solves? I just don't understand why I'd learn it when it offers nothing new or unique and feels even more clunky to
by jimktrains2 9y ago
Perhaps I've never hit the problems that go solves? I just don't understand why I'd learn it when it offers nothing new or unique and feels even more clunky to work in than alternatives.
Specifically for me, I know enough poorly-typed lanagues that I want to be learning and using languages that offer me a good type system to express my program in, and not just jump through hoops to get things to work with no large benefit or reduction in code (and do when I get a chance).
I get coroutines are cool, but they don't really seem to solve the problems I have with concurrency. They feel like baked-in message queues.
- systems 9y agowell, the ecosystem is usually the answer, Go is a simple language, which attracted many developers, which resulted in a large ecosystem but there is also the issue of complexity developer used Go to create complex systems, because it is a simple language, it allowed them to focus on the solution while, complex systems, might be simpler if they were built using complex languages, it seems most developer prefer to build complex systems using simple languages, rather than build simple systems using complex languages complexity doesn't disappear you can only spread it around, to make it more manageable .. using a simple language and moving complexity to the solution, seems like a trade off many are willing to make .. so this is not necessarily a bad thing .. its a preference if Go starts adding complex features, many developers will move or chose another language ..
- systems 9y agoand today on xkcd https://xkcd.com/1987/ https://xkcd.com/1987/ Python is another example of a simple language + complex everything else or at least a language that started simple
- parenthephobia 9y ago> it seems most developer prefer to build complex systems using simple languages, rather than build simple systems using complex languages According to TIOBE, 1% of programmers are using Go, whilst 23% are using Java or C++. If that is to be believed, developers do not appear to prefer simple languages. Or, Java and C++ are simple languages. Or, language selection is not based on preference.
- systems 9y agowell while many question TIOBE, i believe a lot fewer will question the empirical observation that C# and Java are bigger in the job market than C++ C# and Java both are a lot simpler than C++ i would even argue that by adding more features into Java and C#, a door was opened to PHP, Python, Ruby and now GO i still stand by conclusion, that most developer prefer to move complexity to the solution and away from the language and to be clear, i saying that this is a preference and taste issue, i am not saying that one is better than the other, i am not even saying that developers who prefer complex languages have bad taste ... it is just the way it is ... others have expressed it in more length https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html
- pjmlp 9y agoSimple languages like Go just put the burden of complexity on the shoulders of developers, that end up implementing ad-hoc solutions for what other languages support natively. Hence how we end up with factory-factory classes, aspect oriented programming, patterns and stuff. On Go's case, how we now have n variants of code generation libraries or multiple solutions to sort out dependencies and vendoring. GoSpring and GoEE, similar to Java 1.2 days, should be quite interesting to see.
- deleted 9y ago[deleted]
- dilap 9y agoGo is my favorite language; it started out seeming unimpressive, but the more I used it the more I came to appreciate it. For me the charm is it's a very simple yet well-chosen set of features, combined with a very high level of engineering quality. I find myself spending more time solving the problem at hand when using Go than ecosystem or language BS. My 2-most used languages prior to Go were C++ and Python, for reference. I've played with things like Haskell, but never to a high degree of proficiency. I imagine if you are a fan of fancier, stronger type systems you might find Go unimpressive. (I've also done a lot of personal elisp, as an emacs addict....)
- bmaupin 9y agoIn my case the advantages were that it was statically-typed, faster, and had better concurrency than my go-to language at the time (Python). But in the end, while Go had many advantages, there were too many factors that made writing Go frustrating and discouraged me from using it. So if you don't need Go, I think the only reason to try it would be because it happens to be trendy at the moment. And that doesn't seem like a sufficiently compelling reason on its own.
- vram22 9y ago>But in the end, while Go had many advantages, there were too many factors that made writing Go frustrating and discouraged me from using it. What factors?
- JepZ 9y agoGo is mostly an answer to the problems of C. Sadly Go is not able to replace C as the introduction of the Garbage Collection makes it unsuiteable for many use cases of C. Besides that, Go has solved a lot of issues you had with C and as a result the code is much easier to read, write and understand. At the same time, C is most likely not the only language in the universe and the fact that Go can not be used for all the use cases you can use C for, makes it even more important to compare it to other languages. And while I like Go very much, I can understand that language wise, there are mightier wizards out there. But Go's strength is not the language itself. The language is just a cleaned up version of C which many people appreciate, because they know the C syntax already. But the real streght of Go is its enforced simplicity in syntax and file structure combined with a more or less complete, cross platform toolkit and a nice performing build and execution process. The builtin concurrent execution is a bonus on top of that. How many compiled languages do you know that ship by default with a cross platform compiler and compile with the speed of Go?
- pjmlp 9y agoBasic, Pascal, Modula-2, C using Amsterdam Compiler Toolkit during the 80s. There are other examples if you like.
- unoti 9y ago> they don’t really seem to solve the problems I have with concurrency. They feel like baked-in message queues. You’re right about the baked in message queues. But that’s actually one of the key ingredients to designing simple scalable concurrent architectures. Once you get the message queues right, it factors away the concurrency primitives you normally would have to work with, such as critical sections and mutexes. This is demonstrated in the two references below. The message queue design is simple and yet crucial to making the simple scalable designs. Alan Kay said “The key in making great and growable systems is much more to design how its modules communicate.” The two references below explain how Go approaches concurrency in a way that makes it easier. 1. Don't communicate by sharing memory. Share memory by communicating. 2. There’s an amazing video with Rob Pike explaining how to produce concurrent designs that are simple and scale. Message queues is one of the 3 major components. [1] https://blog.golang.org/share-memory-by-communicating https://blog.golang.org/share-memory-by-communicating [2] https://youtu.be/cN_DpYBzKso https://youtu.be/cN_DpYBzKso
- brudgers 9y agoGo solves a very specific problem: the limitations of Python, CPP, and Java within Google. That's it. Google maintains control over the constructs within it in order to standardize its (Google's) code. When only Google's code matters, there's no rationale for things like including generics and or consensus standardization via ISO. That's not to say Go is bad. There can be a lot of overlap between the type of problems Google designed Go to solve and the types of problems other people and organizations often have. A lot of people write systems code. A lot of people experience the limitations of Python, CPP, and Java. Not everyone of course. I mean to me, the Go ecosystem looks so much like an "enterprise" decision that it would be mocked by the very people using it if Go came from IBM or Oracle.
- riku_iki 9y ago> the limitations of Python, CPP, and Java within Google What Java's limitations Go solves exactly?
- palerdot 9y agoAt the minimum, the verbosity problem. We can argue that any language is less verbose and more concise than Java. Go is inherently not a OO language and has some excellent functional constructs which makes it easy to approach and solve certain set of problems whereas in Java you are forced to do the OO way even if the problem at hand does not require that way of solving stuffs. Finally, Go compiles to machine code and I guess it should be way faster than Java.
- riku_iki 9y ago> Go compiles to machine code and I guess it should be way faster than Java. Java is also not interpreted for 20 years already. JIT compiler compiles jvm bytecode into machine code.
- nostalgeek 9y ago> At the minimum, the verbosity problem I don't believe a single second that Java is more verbose than Go. It's just that Go hasn't been buried under layers and layers of EE ...yet. In fact the whole "if err!=nil" boilerplate is the very definition of verbosity. > Go is inherently not a OO language Everytime you use interfaces you are doing OOP. And there is no choice but using interfaces when dealing with streams, which is 99% of what people use Go for. > has some excellent functional constructs No more than the latest Java. In fact Java has something Go definitely doesn't have which is pretty useful for functional programming: generics. > Finally, Go compiles to machine code and I guess it should be way faster than Java. AOT compilation is coming to Java.
- cdelsolar 9y agoIt's basically better and allows you to be more productive with fewer bugs than any other language.
- pyrale 9y ago> allows you to be more productive with fewer bugs than any other language. If I got a dollar for everytime someone had said that without any solid ground to stand on...
- deleted 9y ago[deleted]