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

101–110 of 367 posts

Re: Why Go Is Not Good

#101

Post by stcredzero »

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

>The correct solution is for people to implement languages like Haskell and Clojure in Go, making them execute as fast as possible. Uh, what? Haskell already compiles to native code, and is faster than Go in many cases. Also, if you were implementing a programming language, there are much better languages to do it in than Go.

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

Re: Why Go Is Not Good

#102

Post by pornel »

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 has `unsafe` blocks in which you're allowed to do all nasty hacks you want.

Rust actually isn't that complicated. Don't get discouraged by comparisons to Haskell — it's still a C-family language where you can play with pointers and mutable state.

To me Rust still feels like a "small" language (similar size as Go or ObjC, not even scratching complexity of C++). It's mostly just functions + structs + enums, but they're more flexible and can be combined to be more powerful than in C.

Re: Why Go Is Not Good

#103

Post by kryptiskt »

pcwalton wrote: post #56
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…

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

Re: Why Go Is Not Good

#104

Post by wyager »

stcredzero wrote: post #101
wyager wrote: post #83

Earlier quoted context omitted.

>The correct solution is for people to implement languages like Haskell and Clojure in Go, making them execute as fast as possible. Uh, what? Haskell already compiles to native code, and is faster than Go in many cases. Also, if you were implementing a programming language, there are much better languages to do it in than Go.

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.

Re: Why Go Is Not Good

#105

Post by dllthomas »

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…

"But, for systems programming, abstractions suck. [...] But for tools that only need to do one thing and do it extremely well, it's either that or C."

C and Go are just two particular piles of abstractions. The tools work better for some problems, but that's not because "abstractions suck" for those problems.

Re: Why Go Is Not Good

#106

Post by wyager »

platz wrote: post #100

For robots, Haskell is not used directly, but can be used as a DSL to generate the appropriate C code. Here's one example: http://smaccmpilot.org/languages/index.html

True! Embedded programming DSLs are a very cool area of research. I figured they might be a bit beyond the scope of the article.

Re: Why Go Is Not Good

#107

Post by jamesmiller5 »

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.

Re: Why Go Is Not Good

#108

Post by dbaupp »

xkarga00 wrote: post #92

"Go does not support immutability declarations." Doesn't Go have constants (const) which are immutable? What am i getting wrong here?

Those are just compile time constants, you cannot have a value computed at runtime stored in an immutable variable (i.e. one the compiler will complain about if you attempt to mutate it, to assist with program correctness).

Re: Why Go Is Not Good

#109

Post by ScottBurson »

jacquesm wrote: post #88
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?

> Yes there are GCs for C, but is anyone successfully doing "systems programming" (whatever that may be) in C with GCs? Actually, yes. But it's hackish (relies on some pretty complex macros) and requires you to adapt certain conventions. Still, it's doable and a whole lot safer than managing your memory directly in terms of leaks and re-use after free. The cost to me really is that macro magic, that should not be req…

You rolled your own? Why not use the Boehm conservative collector?
Post reply on HN