Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is amazing, period.

poincare101.blogspot.com

Post reply on HN
Print view View original

171–180 of 241 posts

Re: Go is amazing, period.

#171

Post by JulianMorrison »

karterk wrote: post #113
amattn wrote: post #85

Earlier quoted context omitted.

Nothing in go is silly. There are multiple reasons why it's required. The answer usually given is faster compile times and the removal of semicolons from the language. I don't know the details, but someone new complains about it on the mailing list fairly frequently. Also having a tool enforced brace style is just plain practical. Less silly arguments/bikeshedding. I was also a brace on its own line kinda guy, but be…

What about using two characters for assignment? a := 1 vs a = 1

"a := 1" means "var a int = 1" which is not the same as "a = 1"

Re: Go is amazing, period.

#172

Post by JulianMorrison »

alok-g wrote: post #119
canop_fr wrote: post #116

Earlier quoted context omitted.

You don't read only your code, but also code from other people. Go make it really easy, in my opinion, to fast decipher foreign code, due to shortness, clarity, and conventions. Convention help you recognize in that case the structure of the function without having to make your mind around the habit of the other coder.

I do not care who wrote the code -- It should be shown to me using my formatting preferences, just as I can use my own visual theme in the editor. Those themes do not affect the code as it is saved into the file, and those formatting preferences should not either.

Formatting is semantic in Go, newlines are significant, so a brace across a newline is quite reasonably different from a brace on the same line.

Re: Go is amazing, period.

#173

Post by enneff »

fs111 wrote: post #169
enneff wrote: post #72

Earlier quoted context omitted.

It's really nice. You can build your Go program, deploy it as a single binary and it just runs. No need to hide it behind nginx or some other dedicated web server. The Go http package is DoS hardened and very fast. It's refreshing how little mechanism there is.

Well, even if I like go, I would not run a go program as root to listen on port 80. Can you drop the privileges from within go like apache or nginx are doing it?

You sure can: http://golang.org/pkg/syscall/#Setuid

Re: Go is amazing, period.

#174

Post by adgar »

lusr wrote: post #170
adgar wrote: post #166

Earlier quoted context omitted.

But apparently you consider "no generics" a deal-breaker without seeing why generics haven't been added yet, and why it isn't an issue for the many developers writing real-world production Go code.

I'm confused. I never called it a deal-breaker, just a surprise. The language designers, in their FAQ, acknowledge it as an opinionated gap where their own opinion hasn't been fixed, so I'm not imagining it as a gap either. Your comment about "real-world" code is even more puzzling, as if all "real-world" code is somehow equivalent in abstraction needs. There are guys who've written serious code running in billions o…

> In the space I work in - enterprise applications integrating large, disparate systems where you have zero control over interfaces and data formats but somehow need to get everything talking together nicely, generics are invaluable in structuring your code and making it reusable.

Luckily for you, Go already solves these problems incredibly naturally! Unfortunately, you haven't looked into how Go solves those problems, primarily through its interfaces and type embedding, plus its slices and so on are already generic.

It's true they aren't sure if they need it or not, but you clearly haven't looked into many feel they are unnecessary and that the present language is more than sufficient for solving many needs. In fact, Go is almost explicitly designed to handle the production cases you tackle. But it seems you've said in other threads that learning new approaches isn't really worth it for you, in which case, it's unsurprising that new languages aren't offering you much.

Re: Go is amazing, period.

#175

Post by JulianMorrison »

jkn wrote: post #135
ek wrote: post #84

I really like most things about Go, and was even going to use it for a bytecode interpreter project I was working on. A problem that I ran into, however, was that in interpreting a dynamic language with a stack machine, we needed a way to be able to store arbitrary data in stack values, which in C/C++ would be done using a struct with a type flag and then a union of various types. Go doesn't have unions, though, and…

Couldn't you use an empty interface to store arbitrary values? From the tutorial: Every type implements the empty interface, which makes it useful for things like containers. Unions are on the roadmap: http://golang.org/doc/devel/roadmap.html but it's a list of ideas rather than features promised.

C people: think of interface {} as roughly the same as void*, except that values pointed to preserve information about their type which can be extracted and used later.

Re: Go is amazing, period.

#176

Post by pjmlp »

jkn wrote: post #152
pjmlp wrote: post #105

Earlier quoted context omitted.

Go routines + CSP are easily done in all mainstream languages. Java: java.util.concurrent .NET Task Parallel Library C++ Parallel Patterns Library Threading Building Blocks Click Cilk Plus D Actors + std.concurrency Erlang Actors Scala Actors Haskell STM Clojure STM There are good things about Go, but people should learn other programming languages properly, before doing comparisons.

Threads are different from goroutines. A Go program can create 100'000 goroutines, if it makes sense for the algorithm. Try doing this with threads... Super-cheap threads open many possibilities, it's a significant change in how you think and design programs. Among your examples, those that are comparable to goroutines are all for functional languages. There's nothing wrong with functional languages, but it's far fro…

Yes there are, they are known as user space threads or fibers.

Re: Go is amazing, period.

#177

Post by CamperBob »

jbarham wrote: post #87
FreakLegion wrote: post #81

Earlier quoted context omitted.

void func() { } vs. void func() { } Does Go really enforce the latter? That would be incredibly silly.

It's a FAQ: http://weekly.golang.org/doc/go_faq.html#semicolons

From that page: "At the moment, all implementations use 32-bit ints, an essentially arbitrary decision. However, we expect that int will be increased to 64 bits on 64-bit architectures in a future release of Go."

So, in other words, it's Amateur Hour. All righty, then.

/backs toward door, reaches for doorknob, still smiling and nodding

Re: Go is amazing, period.

#178

Post by dsymonds »

ootachi wrote: post #117
enneff wrote: post #109

Earlier quoted context omitted.

Java requires a powerful, sophisticated garbage collector because it is extremely difficult (and in many cases impossible) to write Java programs that don't generate a lot of garbage. Even many of the core APIs are allocation heavy. It's a pain. Go data structures tend to be much smaller than the Java equivalents, and it is much easier to track down and eliminate unnecessary allocations in Go code. When you have bett…

Go gives you slightly better control over allocation than Java (in that you have a choice to allocate on the stack and inside other data structures -- but keep in mind that escape analysis can give you this too, see the optimizations in the Jikes RVM). However, in Go, you still have no choice but to allocate on the heap in many instances (for example, when returning a data structure from a function, or when using map…

We don't bet, we experiment, measure and analyse. So far, I have found memory allocation in Go to be extremely predictable and controllable, and the GC behaviour likewise predictable.

I don't know why you claim that "having all the data on the stack doesn't help you". That makes no sense. If data is on the stack, any references starting there disappear as soon as that stack frame is popped, so there's no lingering work for the GC to do; the GC arena is unchanged.

Your comments strongly imply that you have no practical experience with Go's GC. I suggest you stop claiming that it has certain performance characteristics or behaviours when you have not experienced it yourself.

Re: Go is amazing, period.

#179

Post by ootachi »

jbarham wrote: post #159
ootachi wrote: post #110

Earlier quoted context omitted.

"There are few real world programs that are improved by code generation micro-optimizations" I don't know how to convince you of the fact that this statement just isn't true. Consider the rasterization software you're using right now in your web browser. Micro-optimizations hugely matter for blitting and tessellation. Consider video decoding (or encoding!). Using SSE instructions instead of going word-by-word or byte…

> Read Dark Shikari's blog posts about x264 if you want to see how much good use of SSE matters for video encoding. Like http://x264dev.multimedia.cx/archives/486 ? "Now that I’ve written a thousand or two lines of assembly code..." etc. Programmers who know and care about these processor-level micro-optimizations use assembly code, for which by definition you do not need a compiler. Then again if you really care abo…

C compilers can and do generate SSE. Programs do rely on this code generation for performance. They fall back on assembly when codegen fails. That doesn't mean that they aren't relying on the optimizations in other places.

And a huge amount of graphics processing is always done on the CPU. Unless you're using Direct2D or something, rasterization is always done there (and even if you're using Direct2D, a lot of rasterization is still done there).

Re: Go is amazing, period.

#180

Post by 4ad »

adgar wrote: post #138
karterk wrote: post #113

Earlier quoted context omitted.

What about using two characters for assignment? a := 1 vs a = 1

Having both := and = goes back a long, long, long way. Go isn't even the 100th language to differentiate them.

:= and = don't do what you probably think they do, the meaning is not the same as in Pascal. If you need to compare two variables, you use ==

    if a == b {}
= is the usual assignment, := declares and initializes a variable inferring the type.

    var a int
    a = 42
vs.

    a := 42
That means you'll see explicit types in variable declarations rarely.
Post reply on HN