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

161–170 of 367 posts

Re: Why Go Is Not Good

#161

Post by logicchains »

mustpax wrote: post #66
MartinMond wrote: post #61

Earlier quoted context omitted.

Doesn't Go have a GC? How can you then "picture what the C equivalent would look like"? Yes there are GCs for C, but is anyone successfully doing "systems programming" (whatever that may be) in C with GCs?

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?

Re: Why Go Is Not Good

#162

Post by kyrra »

vorg wrote: post #76

I've recently tryed out Go for its Unicode integration. What I liked at first sight... * the indexing makes a map[something]boolean act like a set. Sets and maps are so similar it always felt wrong for them to be two separate constructs. * making exported functions/vars/etc begin with a capital letter. When naming important stuff, it's a relief not worrying about naming conflicts with keywords. When naming locals, ju…

FYI, to create a set in Go you can also use struct{} for the value. map[something]struct{}. The value takes up zero space then.

Re: Why Go Is Not Good

#163

Post by fpgeek »

kryptiskt wrote: post #103
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…

Type classes are so good at error messages that they were proposed as the solution to the error message mess in C++ in the form of Concepts.

As someone who's spent more time than I'd like to remember improving type class error messages, this sentence boggled my mind. Then I remembered what C++ template error messages are like and it all made sense again.

Re: Why Go Is Not Good

#164

Post by liveoneggs »

mholt wrote: post #22
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.

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…

> I can deploy my app by copying a single, self-contained binary.

I don't think golang invented static linking. ;)

Re: Why Go Is Not Good

#165

Post by dbaupp »

richo wrote: post #147
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.

that's what mapping an -rwx page at 0x0 does, and as a result it segfaults, which is an access violation.

There is some subtlety about dereferencing a null pointer. Many languages (C, C++, Rust) state that *NULL is undefined behaviour, that is, the compiler can assume that it never happens and optimises based on this. This can lead to a "misoptimised" program that doesn't actually segfault when the source suggests it should.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

Re: Why Go Is Not Good

#166

Post by jjnoakes »

richo wrote: post #147
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.

that's what mapping an -rwx page at 0x0 does, and as a result it segfaults, which is an access violation.

No, you are wrong.

First, mapping that page doesn't cause all null pointer dereferences to segfault.

And second, the language doesn't require a segfault. In fact, it explicitly permits the implementation to do whatever it likes.

That is the difference between safe and unsafe. It is in the language definition.

Re: Why Go Is Not Good

#167

Post by stcredzero »

wyager wrote: post #104
stcredzero wrote: post #101

Earlier quoted context omitted.

Depends on your particular value of "better." If you're optimizing for programmer time, writing a language in Go is not a bad tactic. You get out of having to write your own GC, you can incorporate a few nice concurrency features with little effort, and you still get pretty good performance. (Admittedly, far from the best performance, though.)

>You get out of having to write your own GC You also don't have the ability to write a GC-less language, because there is no practical way to write non-GCed Go code. >you can incorporate a few nice concurrency features with little effort You also can't implement any custom OS-level concurrency features.

You also don't have the ability to write a GC-less language, because there is no practical way to write non-GCed Go code.

True, so you probably don't want to do that.

You also can't implement any custom OS-level concurrency features.

True. But for "journeyman" level language implementation, the toolset is quite good.

Re: Why Go Is Not Good

#168

Post by dbaupp »

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…

> 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.

What is the solution?

Re: Why Go Is Not Good

#169

Post by codygman »

oscargrouch wrote: post #6

Go, Rust, Haskell, come from diffent ways of thinking about how to solve problems using programming languages.. Go aims to be more simple and concise, in the end you write less code to do the same thing, as you would in C++, Haskell or Rust.. because those 3 languages decided to "cover everything" and are worried about other things, creating more burden to the programmer, but with something else to gain Go is more of…

You made the claim that "in the end you write less code to do the same thing, as you would in C++, Haskell or Rust". Can you provide any examples where the Haskell equivalent isn't more concise than the Go equivalent?

As a data point, here are links to the Haskell and Go implementations of the TechEmpower benchmarks:

Haskell (78 sloc)

https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

Go (164 sloc)

https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

Re: Why Go Is Not Good

#170

Post by dbaupp »

wyager wrote: post #149
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…

>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 documentation and cross-compiling (it already has basic support for running the tests described above).

* Formatting

Missing at the moment, but very wanted: https://github.com/rust-lang/rust/issues/3195 .

(Well, to be precise, the compiler has the '--pretty normal' option, but it's not so good. https://github.com/pcwalton/rustfmt is the work-in-progress replacement.)

* Cross compiling

Already supported, although it requires manually compiling Rust with the appropriate --target flag passed to ./configure, to cross-compile the standard library.

Post reply on HN