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

231–240 of 367 posts

Re: Why Go Is Not Good

#231

Post by axaxs »

coldtea wrote: post #222
axaxs wrote: post #219

Earlier quoted context omitted.

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 kn…

> Rust...with its arrows, angle brackets, pattern matching, etc. seemed just so complex to fit in my brain. It's 2014 already. Angle brackets, arrows, and pattern matching are 1990 level language technology. Heck, even a dynamic front-end language like Coffescript has these kind of things nowadays.

I'm not saying you're wrong nor will I argue about it as in the end it really comes down to taste I feel. To me, and perhaps to others, these things make a language harder to read/use, regardless of how pervasive...

Re: Why Go Is Not Good

#232

Post by Peaker »

habitue wrote: post #217
Peaker wrote: post #184

Earlier quoted context omitted.

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 p…

It does not mean "memory safe" in general. It means different things in different contexts.

Also, I wasn't making a point about the word "safe". I was making a point that if go is "safe", then the word "safe" is useless.

There is a problem here. Don't want to call it "unsafe"? Ok. Call it crashy, instead.

Re: Why Go Is Not Good

#233

Post by Peaker »

briantakita wrote: post #213
Peaker wrote: post #202

Earlier quoted context omitted.

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…

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

So what does this have to do with Go or type systems?

> I usually use guard clauses to protect against nulls. I rely on my tests & production monitoring systems to prove that the implementation is incorrect.

And that's a bad thing. There are better tools for this job. What's the downside of encoding nullability into the types?

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

Every good type system lets you "opt out".

Therefore, it is a bit silly to look at dynamic typing, where you cannot "opt in", as more flexible.

Re: Why Go Is Not Good

#234

Post by dbaupp »

bjz_ wrote: post #218
dbaupp wrote: post #170

Earlier quoted context omitted.

> 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

To be clear, I just meant in the context of

> I know off the top of my head that Haskell's Cabal takes care of at least 4 of them

from the post I was replying to.

Re: Why Go Is Not Good

#235

Post by Peaker »

coldtea wrote: post #225
Peaker wrote: post #187

Earlier quoted context omitted.

You seem to be brushing this off as a minor nuisance, when in many cases it is a showstopper. Need it for floats, duplicate it again. This is a solved problem -- the fact Go doesn't have the solution reflects very poorly on Go.

There are some batshit crazy "solutions" offered from Go fans, like "no biggie, just use a templating engine to generate the code for the types you want and compile it".

I actually use that solution in c (we have some reasons to avoid c++).

Of course it sucks, but at least c has the excuse of being from the 70's.

Re: Why Go Is Not Good

#236

Post by jules »

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…

This is incorrect. Generics in C++ are zero cost, since they are specialized at compile time. On the other hand if you want to write generic code in Go you have to use Object types everywhere. That means that objects have to be tagged, those tags checked with run time checks, additional pointers everywhere, bad memory layout, etc. So generic code in Go is significantly slower than in C++.

Re: Why Go Is Not Good

#237

Post by aktau »

logicchains wrote: post #161
mustpax wrote: post #66

Earlier quoted context omitted.

That's true. It's not just GC actually. Slices and goroutines don't have a direct analogues in C either. But it is fairly easy to reason about the runtime complexity of these conveniences. But like I said, if I didn't care about GC or concurrency, I'd be writing C.

Isn't the C equivalent of a slice just a struct containing a *T, a length and a capacity?

And some methods for manipulating it (slicing it), and reference counting. And macro's for automatically ref'ing/unref'ing.

Re: Why Go Is Not Good

#238

Post by pjmlp »

coldtea wrote: post #225
Peaker wrote: post #187

Earlier quoted context omitted.

You seem to be brushing this off as a minor nuisance, when in many cases it is a showstopper. Need it for floats, duplicate it again. This is a solved problem -- the fact Go doesn't have the solution reflects very poorly on Go.

There are some batshit crazy "solutions" offered from Go fans, like "no biggie, just use a templating engine to generate the code for the types you want and compile it".

They suffer from a strange distortion field effect.

Re: Why Go Is Not Good

#239

Post by lmm »

plainOldText wrote: post #99

Reading this article and the HN comments made me realize, how people want to use the same language for everything. Unfortunately, this is not possible, since each language was design with certain use cases in mind. I too, am guilty of wanting a language to do everything, to be fast, memory efficient and also easy to program in. Perhaps our ultimate quest in terms of designing languages is to design one smart enough t…

I'd make the case for Scala for almost anything (nothing so low-level that you need to avoid GC, and I guess not command-line utilities (JVM startup time), but other than that). Haskell or OCaml could probably make a case for being suitable for just about anything. There are big advantages to using a single language in terms of code reuse, deployment tooling and so on.

Re: Why Go Is Not Good

#240

Post by lmm »

pcwalton wrote: post #80
Silhouette wrote: post #78

Earlier quoted context omitted.

If Go has a slogan that slogan is "Frictionless Development". It's easily the simplest, least annoying, and most "get out of your way" language I've ever used. I suspect this is where many philosophical differences in these discussions originate. I appreciate the value of having quick and easy tools, but for production software where I care about quality, I don't want the language to get out of my way if I'm doing so…

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.

What if e.g. a programmer calls some normalize function on data before hashing it? Then if the normalize function sometimes returns null and the programmer hasn't handled this case, an attacker could use this to generate collisions.
Post reply on HN