Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go Is Not Good

yager.io

Post reply on HN
Print view View original

151–160 of 367 posts

Re: Why Go Is Not Good

#151

Post by dsymonds »

frowaway001 wrote: post #141
mustpax wrote: post #64

Earlier quoted context omitted.

By systems programming I mean writing the code that applications and distributed systems run on top of. Raft ( https://github.com/goraft/raft ) and groupcache ( https://github.com/golang/groupcache ) come to mind as examples. That's a good point though. A lot of people mean different things by systems programming.

> A lot of people mean different things by systems programming. Actually, no. It meant one thing until Go proponents tried to market their language and realized that their target audience didn't actually care.

Several of the initial Go designers were doing "systems programming" in the 1960s under the exact same meaning.

I'd also s/didn't actually care/got confused/ in your last sentence too.

Re: Why Go Is Not Good

#152

Post by stcredzero »

wyager wrote: post #98
stcredzero wrote: post #96

Earlier quoted context omitted.

So why not just use Haskell? Why didn't Haskell take over Go's niche?

Because Go is pretty good at its niche, and it has a huge amount of corporate support (from Google), which can make even a mediocre language seem very attractive.

I was around for the Java vs. Smalltalk keruffle. I have to say that Go is less hype and more good, pragmatic design than Java. Go also started out with quite respectable speed and a pleasant development experience, which wasn't true for Java.

Also, as for a "huge amount" of corporate support, if we see the equivalent of "Enterprise Java Beans" then I'll concede that Go is "another Java."

Similar to Java: The barriers to outreach are small because the language is in many ways familiar. I think that's a wise and pragmatic choice.

Re: Why Go Is Not Good

#153

Post by runT1ME »

dcposch wrote: post #144

> A Good Solution: Constraint Based Generics and Parametric Polymorphism > A Good Solution: Operators are Functions > A Good Solution: Algebraic Types and Type-safe Failure > A Good Solution: Pattern Matching and Compound Expressions People have tried this approach. See languages like C++ and Scala, with hundreds of features and language specification that run into the thousands of pages. For an unintentional parody…

You seem completely ignorant of the things you're attempting to talk about. Scala doesn't have "hundreds' of features, nor is the language specification thousands of pages. It's just an outright fabrication to say so.

>Go was created by the forefathers of C and Unix.

Yeah, and it's obvious (and sad) they ignored the last twenty years of PL research and progress.

>They left out all of those features on purpose

Did they? I don't believe this is the case, as I've heard from the creators many times that they want to add generics but haven't figured out the details yet.

Are you really going to sit here and argue that static typing is important EXCEPT for when working with collection? That parametric polymorphism doesn't make things simpler?

Re: Why Go Is Not Good

#154

Post by fpgeek »

mustpax wrote: post #114
pcwalton wrote: post #56

Earlier quoted context omitted.

> When abstractions break, you not only have to deal with a broken system but the broken abstraction itself too. (Anyone who has ever seen a gcc compiler error for C++ knows how this feels.) Using C++ template error messages to attack generics in Rust and Haskell is pretty weak, because typeclasses were explicitly designed to avoid the problems of "ad-hoc" templates in languages like C++. Error messages are in fact w…

There's no question that Rust and Haskell have better tools than C++ for abstracting code. Go is just demonstrating that you can write great software without the aid (and cost) of generics.

What is Go demonstrating about programming without generics that Lisp, Java (pre-2004), Python and tons of other languages haven't already demonstrated?

Re: Why Go Is Not Good

#155

Post by waps »

mustpax wrote: post #114
pcwalton wrote: post #56

Earlier quoted context omitted.

> When abstractions break, you not only have to deal with a broken system but the broken abstraction itself too. (Anyone who has ever seen a gcc compiler error for C++ knows how this feels.) Using C++ template error messages to attack generics in Rust and Haskell is pretty weak, because typeclasses were explicitly designed to avoid the problems of "ad-hoc" templates in languages like C++. Error messages are in fact w…

There's no question that Rust and Haskell have better tools than C++ for abstracting code. Go is just demonstrating that you can write great software without the aid (and cost) of generics.

Note that the cost of interface{} is, essentially the same cost java imposes.

Luckily it's used less, but that doesn't change it really. Anything becomes a double pointer indirect.

And just for completeness : even java has better tools for abstractions.

Re: Why Go Is Not Good

#156

Post by codygman »

Silhouette wrote: post #82
wyager wrote: post #31

Earlier quoted context omitted.

>I'd rather be stuck with a language whose designers are very resistant to change vs one that gets features haphazardly bolted on every few years (PHP comes to mind). I absolutely agree! However, I don't think Rust will continue to go through wild changes for much longer. My guess is that it will settle and become pretty fixed. And Haskell certainly doesn't introduce breaking changes very often.

And Haskell certainly doesn't introduce breaking changes very often. Actually, I'd say instability is one of the significant challenges with adopting Haskell for long-lived production code. For example, there have been a few discussions in various forums and blogs recently about how much of Real World Haskell no longer even compiles on the latest GHC and current versions of libraries. RWH is a book that rapidly becam…

To be fair Real World Haskell was written in November 2008, and IIRC that syntax was valid up to GHC 7.6.3 (needs citation) or 21 April 2013.

Re: Why Go Is Not Good

#157

Post by waps »

cjbprime wrote: post #127
wyager wrote: post #54

Earlier quoted context omitted.

>But, for systems programming, abstractions suck. Could you clarify what you mean by "systems programming"? To me, that means working with embedded systems, which Go is certainly not appropriate for.

> Could you clarify what you mean by "systems programming"? To me, that means working with embedded systems, which Go is certainly not appropriate for. The blunt but approximately correct version is that embedded means that you're running on hardware that isn't powerful enough to run a Linux kernel. Systems programming just means you're working below the application layer. So if you take your laptop and write a devic…

Just curious : how does one run go without a linux kernel ? (without a kernel at all, please, I know about the freebsd port)

Re: Why Go Is Not Good

#158

Post by jeremyjh »

personZ wrote: post #145

We've seen this same article re-written countless ways. Seriously, this is (intentionally or not) a rewording of every existing criticism of Go, by people who complain that it isn't a language that it isn't. No, Go's solution to generics is not interface{}. The moment you say that, you have lost . You are trying to fight Go and make it a language that it is not. Always remarkable that such critiques always focus on t…

Since concurrency and composition are important, why doesn't Go have support for immutable variables and monitoring/linking ? These are features proven to make it easier to reason about concurrent systems and to manage failures in a distributed system. From what I can tell it is completely impossible to implement supervisors in Go.

Re: Why Go Is Not Good

#159

Post by jerf »

oscargrouch wrote: post #74
Dewie wrote: post #63

Earlier quoted context omitted.

> These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." They also tell me "now you don't have to wait for the language designers or compiler writers in order to 'implement another feature'." Not that _I_ would necessarily be this "brilliant" guy that implements these features. Most likely I will just find some third…

The problem is when you have to maintain your code with millions of lines, and hundreds of abstractions.. those "features" will hunt you in your nightmares at night This is the "The Curse of C++" and some languages pointed in the article while beautiful and correct at first sight are going down in the same road.. Do we use a programming language to look smart, to create correct code or to efficiently solve problems i…

To understand a language, one must know what problem it was designed to solve. It isn't always obvious, or what it initially looks like it was designed to solve, or even what the community thinks it was designed to solve.

Erlang, for instance, isn't about concurrency. It's about reliability.

Go, I think, is also not about concurrency. It's about building a language that can be sanely used by reasonably large groups of people of varying levels of skill, yet still produce fairly good software even so, without the language forcing a complexity explosion to deal with it.

Consequently, this does not appeal to a lot of relatively skilled programmers used to programming alone. It isn't my personal pick of favorite language, for instance. However, if I could push a button for free, I would convert my workplace of a couple hundred developers to it in a heartbeat, whereas I probably wouldn't actually do that with my favorite language. It is not, of course, a magical fountain of code quality, but it would give me the best tools and best foundation to clean up code bases that in all the other candidate languages I know are one or another sort of mess.

If I were starting a new startup right now and Go were even remotely appropriate, I'd use it. But in my hobby projects? Not really. Except maybe to smash out a microwebsite, it's pretty good there.

So, you know, a lot of the question is what exactly are you looking for in a language? I like Haskell, but the idea of even proposing to change a project at work to it is laughable... and this is important... nor would I expect to enjoy the result two years later if I won. The mess of code that would result from people hitting Haskell with a stick until it did what they wanted it to do would be an unstoppable torrent of ill-conceived code. On the other hand, Go would almost certainly produce much cleaner code, because that's where it really shines. Maybe it isn't "good", but it's the best choice right now in a lot of places.

(It's interesting to contrast Go's approach to this problem with the other major language to tackle this problem space, Java. Despite attacking the same problem, the approaches are significantly different, and I think Go's way better. I'd hesitate to actively predict this, but Java could definitely be feeling some heat from Go in three to six years in a way that very few languages have actually managed to provide any challenge to Java in a long time.)

Re: Why Go Is Not Good

#160

Post by Silhouette »

Silhouette wrote: post #85
pcwalton wrote: post #80

Earlier quoted context omitted.

I doubt that null pointers lead to security vulnerabilities. Panics, yes; worse performance, yes; vulnerabilities, unlikely. Null pointers are not dangling or wild pointers, which are the problematic ones.

I suppose that depends on how broadly you define a security vulnerability. Almost anything that can crash a process on a server -- either literally at OS level or figuratively by requiring something to reset itself before it can continue to do its job -- is probably a DoS attack waiting to happen. That might or might not be as dangerous as something like a remote root vulnerability, but I would argue that it is a ser…

Interesting response... Do the multiple people downvoting not realise that even in Go a null dereference might trigger some sort of automatic reset in your server process (if the unexpected panic is only recovered by some high-level generic error handling logic) or even crash the program entirely (if you didn't have anything up the stack that recovered at all)? Or maybe not realise how these kinds of behaviours might allow denial of service attacks?
Post reply on HN