101–110 of 466 posts
A very informative article though, thanks!
Earlier quoted context omitted.
This is a well-written objection and I completely agree. Operator overloading is consistently one of the worst ideas I see in programming languages, C++ being the prime offender. Programmers think they're being clever when they write crap like boostfs::path path("/some/path"); path /= "yourfile.txt"; Meanwhile, reading your code without being familiar with boostfs::path, my brain grinds to a halt while I try to under…
It's funny. I know very little about C++ and my first thought was that this was, essentially, a shortcut for something like: path += '/' + 'yourfile.txt'; It's also entirely possible that I'd already subconsciously read ahead and so knew that it couldn't have possibly been division.
Earlier quoted context omitted.
Then it needs to stop calling itself a 'systems programming language.' Or maybe it doesn't, but others need to stop calling it that. To me, it's a replacement for Java, not C++. I think that's a reasonable target. Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.
C doesn't have generics, and is certainly a systems language. I don't think you have a strong point here. Systems != embedded.
Earlier quoted context omitted.
What do you think about goroutines and channels?
Using go for goroutines and channels is a bit like using Perl for regular expressions. The features have been added in a way that makes them easy to use and serves as a nice idiomatic platform, but fundamentally it's functionality other languages can provide via library support.
Anyway, there's a reason the phrase "tacked-on" has such negative connotations.
I've used Go for a few projects and I think that people who point out all of the things that Go doesn't have and Go doesn't support misunderstand the language. The problem is that most big languages today are hammers, and they can are used to hit all sorts of nails to fasten all sorts of unholy planks together. Go is a screwdriver. Still good for construction, but you need to be using it in the correct way and you ca…
This is the argument that's always thrown out. The OP obviously understands the language very well. Saying someone just "doesn't understand" belittles those that are voicing genuine criticisms. A language shouldn't be based solely around ideology.
Earlier quoted context omitted.
Without operator overloading, it's hard to make generic numeric algorithms palatable. Compare (fake Go-with-Swift-generics syntax): func Distance (x N, y N) N where N Number { return x.Mul(x).Add(y.Mul(y)).Sqrt() } Versus: func Distance (x N, y N) N where N Number { return Sqrt(x * x + y * y) } If your reaction is "well, Distance doesn't look too bad like that", I can replace it with matrix multiplication or point-in…
Wouldn't breaking it down into components instead of using a one liner be an appropriate response for readability's sake?
(It's totally fine for a language to be not interested in that domain. But that doesn't mean operator overloading is bad. Overloaded operators are essential for some domains.)
Earlier quoted context omitted.
Using go for goroutines and channels is a bit like using Perl for regular expressions. The features have been added in a way that makes them easy to use and serves as a nice idiomatic platform, but fundamentally it's functionality other languages can provide via library support.
+1 on this. Clojure's core.async[0] is the perfect example of an implementation of CSP as a library. Even JS can be used to implement such concepts via the use of generators[1]. [0] https://github.com/clojure/core.async [1] https://github.com/ubolonton/js-csp
With the added convenience that shared mutability is pretty much nonexistent.
I've used Go for a few projects and I think that people who point out all of the things that Go doesn't have and Go doesn't support misunderstand the language. The problem is that most big languages today are hammers, and they can are used to hit all sorts of nails to fasten all sorts of unholy planks together. Go is a screwdriver. Still good for construction, but you need to be using it in the correct way and you ca…
I've used Go for a few projects and I think that people who point out all of the things that Go doesn't have and Go doesn't support misunderstand the language. This is the standard Go defense. 'It's not Go, it's you.' I have written some larger projects in Go, and I am in full agreement with the article - Go is a relatively weak and repetitive language, similar to pre-generics Java. So, why does Go gain so much tract…
I've used Go for a few projects and I think that people who point out all of the things that Go doesn't have and Go doesn't support misunderstand the language. The problem is that most big languages today are hammers, and they can are used to hit all sorts of nails to fasten all sorts of unholy planks together. Go is a screwdriver. Still good for construction, but you need to be using it in the correct way and you ca…
I've used Go for a few projects and I think that people who point out all of the things that Go doesn't have and Go doesn't support misunderstand the language. This is the standard Go defense. 'It's not Go, it's you.' I have written some larger projects in Go, and I am in full agreement with the article - Go is a relatively weak and repetitive language, similar to pre-generics Java. So, why does Go gain so much tract…
I like other languages like Haskell (haven't looked at Rust), but I can't use it on the projects for a variety of reasons.
Go's biggest strengths for me around the tools and ecosystem, and code readability. I very rarely find myself wanting generic code, and when I do using empty interfaces make the code difficult to read. I don't want to start an imperative-vs-functional war or anything, but I've noticed many of the people complaining about Go seem to be functional programming aficionados. Is this because of how much they like embedding…
Now that structures based on Category Theory (generic types, lambdas, monads, futures/promises...) are being adopted by most mainstream programming languages, side effects can be described in a declarative way that is thread-safe and thus amenable to parallelism, will still allowing developers to write in a mostly imperative style.
It's a rare instance where we can really get the best of both worlds. I'm optimist about future developments of PLs.