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

211–220 of 367 posts

Re: Why Go Is Not Good

#211

Post by Mr_P »

zimbatm wrote: post #139
Mr_P wrote: post #69

Earlier quoted context omitted.

These two statements made me cringe: > But, for systems programming, abstractions suck. They always, always have a cost. > Generics? Here's another if statement, put it inside your for loop. If you care about speed (and many systems programmers do), this is exactly the opposite of what you want to do. Unlike your proposal of putting potentially-costly if-statements inside of for loops, generics/templates in c++ provi…

If you truly care about speed you'll have different optimizations for int32 and int64. Depending on who you are working with, the lack of generics is a blessing. Some developers can't restrain themselves and create over-complex abstractions that are used only once.

> If you truly care about speed you'll have different optimizations for int32 and int64.

This is exactly why c++ allows template specialization, and if you don't care for hand-optimizing, you can get both implementations almost for free.

> Depending on who you are working with, the lack of generics is a blessing. Some developers can't restrain themselves and create over-complex abstractions that are used only once.

I can't comment on the competency of your coworkers, but I certainly see how Go could be useful in situations without the kind of performance-constraints which demand a language like c++.

Re: Why Go Is Not Good

#212

Post by masklinn »

zimbatm wrote: post #139
Mr_P wrote: post #69

Earlier quoted context omitted.

These two statements made me cringe: > But, for systems programming, abstractions suck. They always, always have a cost. > Generics? Here's another if statement, put it inside your for loop. If you care about speed (and many systems programmers do), this is exactly the opposite of what you want to do. Unlike your proposal of putting potentially-costly if-statements inside of for loops, generics/templates in c++ provi…

If you truly care about speed you'll have different optimizations for int32 and int64. Depending on who you are working with, the lack of generics is a blessing. Some developers can't restrain themselves and create over-complex abstractions that are used only once.

> If you truly care about speed you'll have different optimizations for int32 and int64.

I'm pretty sure that's what C++ templates specialisation is for...

Re: Why Go Is Not Good

#213

Post by briantakita »

Peaker wrote: post #202
briantakita wrote: post #121

This article presumes that everybody wants an elaborate type system. I'm not sure that is the case. I still see an elaborate type system as incidental complexity. I may be in the minority and I may not have worked in domains which benefit from such modeling. Maybe I'm stuck in a blub paradigm. Here's my reasoning. I'm a fan of human language & domain ontologies. Word definitions are quite flexible & do not have an el…

I recommend Dijkstra's paper: "On the foolishness of "natural language programming" [1]. It explains how natural language is a very poor way to express programs, and how it held back science and progress for many centuries. Strong types describe your code precisely. If your code doesn't match the model yet, that's fine. But your code has invariants in it. Things like: "this variable can never be nil, that variable ca…

> It explains how natural language is a very poor way to express programs, and how it held back science and progress for many centuries.

I'm not interested in using natural language to implement the software (write code). I'm interested in using natural/technical language to create an ontology for the architecture. This is where things get gray.

When I think of an architecture, I think of something that evolves over time. I think of architecture as a tool to facilitate communication between programmers, designers, project management, domain experts, & users.

This ontology evolves over time as the software, understanding of the domain, & the domain itself changes.

I see this fuzziness as an accurate model of the conceptual domain, which is ultimately based on the understanding of multiple humans. This understand is fuzzy and heavily dependent on context. And yet, the ontology attempts to coral this fuzziness into more strongly defined concepts, which map to the implementation. The implementation should not be fuzzy at all.

> Other invariants are similar. Instead of documenting them or keeping them in your head, you let your compiler worry about them.

I usually use guard clauses to protect against nulls. I rely on my tests & production monitoring systems to prove that the implementation is incorrect. When there is such proof, I correct the system. In environments that support rapid feedback & deployment, like the web, this works well. In environments that don't support rapid deployment, iteration, and where lives are at stake, not so well.

> But Go is extremely inflexible. It has a very primitive set of tools to do everything, clumsily. A language like Haskell, for example, lets you have Go-like coroutines and channels. But it also lets you program with software transactional memory, or use other parallelism constructs.

That sounds good to me.

> Also, the inability to specify invariants of your program isn't flexibility.

That mostly sounds good. I would want invariants to be optional, which sounds like is the case.

Re: Why Go Is Not Good

#214

Post by ChikkaChiChi »

Posting articles about how Go sucks because it lacks generics and operator overloading has become the "I'm going to be different and grow a moustache" of the programming set.

Go is a tool in your kit like any other language. You can't blame the architects for not providing an end all be all solution for every person's needs 100% of the time.

Re: Why Go Is Not Good

#215

Post by masklinn »

runT1ME wrote: post #153
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 the…

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

More than thirty years (at the time it was released), the first language with "modern" generics was ML in 1973.

Re: Why Go Is Not Good

#216

Post by bjz_ »

dualogy wrote: post #58
mustpax wrote: post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. 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." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

> Generics? Built-in slice and map types cover most real-world needs quite neatly anyway.

For some applications. But once you start venturing into the realms that Rust is targeting, having user defined generic data structures is very important.

Re: Why Go Is Not Good

#217

Post by habitue »

Peaker wrote: post #184
Dewie wrote: post #89

Earlier quoted context omitted.

Not if you just throw something like an exception when the program tries to do it instead of actually accessing that memory location.

Programs that crash with null pointer dereferences are not very useful. Considering that "safe" removes most of the usefulness of the word "safe".

Specifically, the word safe, when referring to type systems means "memory safe". Meaning the compiler or runtime either prevents bad memory accesses by construction or ensures dynamic checks are in place that throw an exception or halt execution in case a bad memory access was about to occur. It means the program isn't accessing uninitialized memory and isn't vulnerable to buffer overflows etc. It doesn't mean your program won't ever crash.

I agree it's better to avoid null dereference errors by not putting null in your language, but by the normal meaning of safe here, go is safe.

Re: Why Go Is Not Good

#218

Post by bjz_ »

dbaupp wrote: post #170
wyager wrote: post #149

Earlier quoted context omitted.

>See languages like C++ and Scala Of the 4 you mentioned (Constraint based generics and parametric polymorphism, operators as functions, algebraic types and type-safe failures, and pattern matching/compound expression) C++ really only has 1 (operators as functions). >with hundreds of features and language specification that run into the thousands of pages. This describes neither Rust nor Haskell. >Go is "as simple as…

> Rust probably has similar tools * Testing Built-in: http://doc.rust-lang.org/master/guide-testing.html * Documentation Built-in: http://doc.rust-lang.org/master/rustdoc.html * Sharing code and specifying dependencies The newly released 'cargo': http://crates.io/ https://github.com/rust-lang/cargo/ (alpha, but quickly improving). This will be Rust's cabal equivalent, almost certainly with support for generating docu…

I would be very wary about promoting Cargo as a 'cabal equivalent'. :P

Re: Why Go Is Not Good

#219

Post by axaxs »

pcwalton wrote: post #118
eloff wrote: post #93

I just spent the weekend learning Go and writing a single writer multi-reader hashtable for threadsafe access. I picked it deliberately because it's against the philosophy of the language, which is to share by communicating instead of sharing data structures directly. It was painful to write: // Do NOT reorder this, otherwise parallel lookup could find key but see empty value atomic.StoreInt32((*int32)(unsafe.Pointer…

> Rust, C++, Haskell, Scala will never be good at that because they're too damn complicated (although each of them make the nasty parts a little less painful!) Why is Rust too complicated to allow you to do low-level hacking?

I don't think it's bad, but to me(and only to me), disappointing. I'm a long time mozilla fan...heck a Netscape fan really. Go was a pleasure to learn, there were no 'gotchas' initially...just a small, easy to reason about language. Rust...with its arrows, angle brackets, pattern matching, etc. seemed just so complex to fit in my brain. I'd love to be proven wrong and try again, but the docs aren't the best. And I know Rust isn't 'released' yet. But if you are defending it, I feel like it should be at a very learnable state. Do you have plans for a 'tour', for a play by play like Go offers that can bring others up to speed? Further(and this is really reaching while I got you)... my favorite part is cross compilation and being able to deploy a single binary anywhere. I tried to compile something in rustc once, but when I moved it to an older box, it failed to run. Will rust offer such stable static compilation in the future?

Re: Why Go Is Not Good

#220

Post by codygman »

mp8 wrote: post #33
s_kilk wrote: post #3

This was a good read. Can anyone comment on whether they find the problems outlined in the article to really be painful in day-to-day go development? From my initial dabblings with the language, it feels like its constraints may not actually be a big deal in practice, and may even be more of a help than a hindrance in large projects. It would be nice to get some commentary from more experienced go users.

I chose between Go and Haskell for a project some time around 2012. I was a beginner to both, but came from a background of imperative languages (C, C++, Java, etc.) Initially I felt the same as you: Go was much easier to get things done in, and I could be reasonably productive quite quickly (moreso than Haskell, which I found very difficult to learn). However, after some time I found many of the same problems mentio…

This sounds strikingly similar to my experience! Though my imperative language experience was mostly with dynamic and/or scripting languages aside from C#.
Post reply on HN