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

131–140 of 367 posts

Re: Why Go Is Not Good

#131

Post by pcwalton »

thinkpad20 wrote: post #128
[deleted] wrote: post #115

Earlier quoted context omitted.

[deleted]

> Haskell is a research language; Rust is designed to be a practical language. It makes a lot of concessions to practicality, C-like syntax and imperative control flow being high among them. Perhaps I wasn't clear in the post you're responding to: my point was that both Rust and Haskell are fairly "simple" programming languages which seem more complicated, because they introduce a lot of features which are likely to…

> In my fuzzy recollection, it would be something like where I had written `match foo { a => b; c => d}` and I would get some error message which would be fixed by writing `let foo1 = foo; match foo1 {a => b; c => d}`. Unfortunately I don't remember the specifics, but long story short: compiling Rust code produces a lot of very strange error messages to someone unfamiliar with the language.

Ah, sounds like you were using a value after it the destructor on it ran, which was fixed by moving it to a separate variable (so that the destructor ran later). This kind of error is familiar to C++ programmers, so I wouldn't say it's unique to Rust, although it's a runtime error (actually, undefined behavior) in C++ and not in Rust. A good static analysis package for C++ would emit the same error that the Rust compiler did.

Re: Why Go Is Not Good

#132

Post by zemo »

pilif wrote: post #2

>I like Go. I use it for a number of things (including this blog) and yet it goes down once it is posted on HN. I have had some articles of mine end up on HN and I never went down, even when my blog was still WordPress hosted on a machine of mine. This is probably more of a shortcoming of the various cloud providers than of the language/environment itself I guess.

programming language semantics and server availability are distinct topics. If you write a beautiful Haskell program that generates n+1 queries on a database, it will fall over. That doesn't make Haskell bad. Nine times out of ten, making a blog survive the heavy traffic of something like being on HN front page just means knowing how to cache things.

Re: Why Go Is Not Good

#133

Post by pcwalton »

DonnaConners wrote: post #130
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.

You might want to google dereference null pointer code execution. Go regresses language design, because it allows constructs that have been proven to fail and are already fixed in other languages. This has nothing to do with shiny features of the newest language or whether language A or B is someone's favorite. This has to do with program correctness.

Those have to do with the undefined nature of null pointer dereference in C. In Go, accessing a null pointer is guaranteed to produce a panic on every architecture.

Re: Why Go Is Not Good

#134

Post by thinkpad20 »

pcwalton wrote: post #131
thinkpad20 wrote: post #128

Earlier quoted context omitted.

> Haskell is a research language; Rust is designed to be a practical language. It makes a lot of concessions to practicality, C-like syntax and imperative control flow being high among them. Perhaps I wasn't clear in the post you're responding to: my point was that both Rust and Haskell are fairly "simple" programming languages which seem more complicated, because they introduce a lot of features which are likely to…

> In my fuzzy recollection, it would be something like where I had written `match foo { a => b; c => d}` and I would get some error message which would be fixed by writing `let foo1 = foo; match foo1 {a => b; c => d}`. Unfortunately I don't remember the specifics, but long story short: compiling Rust code produces a lot of very strange error messages to someone unfamiliar with the language. Ah, sounds like you were u…

Yeah that's probably right. And yes for sure I'm not only talking about things which are unique to these languages, but just things for which there might be large groups of users who are not familiar with them. Similarly, users of ML (or category theoreticians) are going to be less confused by many of Haskell's idiosyncrasies. :)

Re: Why Go Is Not Good

#135

Post by burntsushi »

jamesmiller5 wrote: post #107
tjholowaychuk wrote: post #59

I also don't get why the for-loop uses a "range" keyword at all, isn't that what typing is for, can't it just figure out that the type is enumerable? I like most of Go so far, but interface{} is possibly the ugliest artifact of a programming language that I've seen, next to pretty much all of c++ Rust and Go should have a baby

There is a subtle yet key difference between range and for. Ranges will only start execution on input of known size and guarantee termination. Regular for loops do not require a terminating state.

> Ranges will only start execution on input of known size and guarantee termination.

`range` can be used to receive values on a channel, which is certainly not a known size and doesn't have guaranteed termination.

Re: Why Go Is Not Good

#136

Post by randallsquared »

Artemis2 wrote: post #40
mholt wrote: post #22

Earlier quoted context omitted.

In practice, Go has caused me less frustration than any other language I've used. I feel like the author's complaints here aren't really grounded in much experience, or maybe he's trying to use the wrong tool for the job. The author's conclusion: · Go doesn't really do anything new. · Go isn't well-designed from the ground up. · Go is a regression from other modern programming languages. is hardly sustainable. Go was…

Go packs together a lot of nice things that previously existed in other languages. It still has room for improvement though, as IMHO the language is pretty basic ATM - but exhaustive enough to cover most needs (whether they require stuff like generics or not) in a very painless way. I love Go, because it fits in my head.

> it fits in my head.

This. I love Go's simplicity. Coming back to Go code I wrote months ago, I can immediately understand what it does virtually every time, which required lots of discipline I didn't always have in other languages. Lots of languages have obscure corners that allow you to do really cool things that aren't obvious, but for the most part, Go doesn't have these; what you see is what's happening.

Are there things that would make Go a better language? Sure! Should the type system be improved? Yup! One thing that makes me cringe is when I open up library code and see interface{} and calls to the reflection package all over the place, but general solutions often require that in Go, and that's a problem. In practice, though, this is almost a feature: if you see that stuff in code you're reading, it's a giant red flag that this code is tricky and possibly slow, and care is needed.

Edit: speeling

Re: Why Go Is Not Good

#137

Post by jamesaguilar »

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…

> to be fast, memory efficient and also easy to program in.

I think the issue Go detractors have is that it is none of those things, nor is there any pair of those things for which there is no better alternative than Go. If you want fast and memory efficient, you could pick C++ or C. If you want something a little easier to program in, you could pick C#, which dominates Go in all three categories. If you want to go easier to program in, there are plenty of languages like Python that are more powerful than Go.

Re: Why Go Is Not Good

#138

Post by dbaupp »

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…

> However, the non volatile, non unsafe parts of the code were an absolute joy. Testing was a joy, compiling was a joy, and benchmarking was a joy. I was impressed that it allowed me to bypass the type system completely and do nasty, nasty things in the pursuit of performance. I want a language that lets me do nasty things where I must, but that makes the other 95% of the program, and the job of compiling, testing, and maintaining that program easy. Go excels here. Rust, C++, Haskell, Scala will never be good at that

FWIW, I actually think that Rust positively excels at this sort of isolated low-level work due to explicit `unsafe` blocks. Furthermore, the type system is more expressive meaning the need for this is rarer[1].

In my experience, the rest of the language (i.e. non-`unsafe` things) works very well for maintenance and testing, also in part due to the more expressive typesystem, and things like algebraic data types with exhaustive matches by default (I've done some huge bug-free refactorings to the standard library and compiler, mostly due to the compiler automatically catching all the places that need updating).

On the other hand this comes with the cost of making the "job of compiling" more difficult: the compiler complains about more things.

Re testing: there's unit testing and microbenchmarking built-in: http://doc.rust-lang.org/master/guide-testing.html

[1]: in this case, the type system positively designed with making this sort of concurrency safer.

Re: Why Go Is Not Good

#139

Post by zimbatm »

Mr_P wrote: post #69
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…

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.

Re: Why Go Is Not Good

#140

Post by frowaway001 »

tshadwell wrote: post #27

For fear of disagree downvotes: I would say that many of the qualms brought up in this article are problems that are encountered fighting the language. The problem of 'summing any kind of list' is not a problem that is solved in Go via the proposed kind of parametric polymorphism. Instead, one might define a type, `type Adder Interface{Add(Adder)Adder}`, and then a function to add anything you want is fairly trivial,…

> put anything you want in it, then assert the type of what comes out

... which is exactly what the article mentions and criticizes?

Post reply on HN