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

71–80 of 241 posts

Re: Go is amazing, period.

#71

Post by drivebyacct2 »

ootachi wrote: post #62
gukjoon wrote: post #42

Earlier quoted context omitted.

Wow. 1. Have you written or debugged C sockets code? Because if you have, I doubt you would be dinging him on not wanting to do that. 2. He doesn't want to handle C/C++. I would say that most people who write application code are with him. 3. Yeah... I'm pretty sure Python, an interpreted language, is slower than Go, a compiled language. Even with the progress PyPy is making, I doubt it's going to beat Go. The author…

PyPy is an optimizing JIT compiler; 6g/8g is not an optimizing compiler. I'm pretty sure one could construct examples in which PyPy beats Go for this reason (try something that relies on loop-invariant code motion, for example). Additionally, PyPy has many garbage collection algorithms, while Go has a stop-the-world mark-and-sweep collector.

Not to downplay these criticisms or to imply that Python isn't a great choice for many of these requirements, but the things you've mentioned of Go's compiler and garbage collectors are (as I understand the intent of the language designers) simply the current stating of being and I believe are both known (and planned) targets for future improvement.

Re: Go is amazing, period.

#72

Post by enneff »

firefoxman1 wrote: post #47
dhaivatpandya wrote: post #23

Earlier quoted context omitted.

I've used web.go successfully before; its quite nice.

What's it like to use a compiled language for a web server?

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.

Re: Go is amazing, period.

#73

Post by jvm »

tpsreport wrote: post #50
dhaivatpandya wrote: post #20

Earlier quoted context omitted.

I usually wouldn't respond to mean comments, but, this one really throws me off (I'm the OP). There is a very strong difference between "cannot write" and the need for something to be simple. I can definitely handle C/C++, and I don't think writing something in a higher-level language changes that. If something is doing processing with 4000 threads with around 10 years worth of by-the-minute data, it sure as hell wil…

I simply summarized your article. There is nothing wrong with not being up to handling C++'s error messages. I don't feel up to that task myself most of the time. But your arguments for Go rang hollow. I'd urge you to go through the "pro-Go" arguments point by point and describe why, say, they apply to Go but not to Python 3.0. And I'm not a Python zealot by any means; I mention it as a comparison point mostly becaus…

"why, say, they apply to Go but not to Python 3.0"

That's sort of a terrible example since python is ill-suited to many (might I dare say a clear majority of?) production environments. The field of general-purpose production languages is actually pretty narrow. I somewhat agree with your point that the reasons were on the superficial side. Nevertheless, people are dissatisfied with the C/C++/JAVA trio and efforts to replace them have so far failed to stick (D comes to mind).

Re: Go is amazing, period.

#74

Post by jbarham »

firefoxman1 wrote: post #2

Is there currently a good web framework for Go? Edit: web.go looks pretty sweet: http://www.getwebgo.com/ Edit2: As does app.go: https://github.com/georgenava/appgo ...There's a large list of Go projects here: http://godashboard.appspot.com/project

Note that there is experimental support for Go on App Engine (http://code.google.com/appengine/docs/go/overview.html) and the beta versions are tracking the Go 1 changes pretty closely.

Re: Go is amazing, period.

#75

Post by shadowsun7 »

rian wrote: post #51
jshen wrote: post #38

Earlier quoted context omitted.

I completely disagree. My goal is to build better systems, and if an evolutionary change helps this, then that's where I'm going. You seem to value "breaking the mold" for the sake of "breaking the mold" Or, you didn't give a good reason to value it. "that stuff is already more than 40 years old.". Is this the fashion industry? Or do you believe that quality is a function of age?

people who program actually have a lot to learn from the fashion industry. trends are fine as long as trends are iterated on quickly. in comparison, it's taken programmers 15 years to make the half-assed-jump from java to go. and even then, the conceptual differences between java and go are minimal , superficial at best. the fact is that go touts itself as a C++/java alternative but i see no significant/non-superfici…

Two things. 1) Have you used Go? Your comments indicate to me that you have little Go experience - thinking in Go is quite different from thinking in C.

2) One line counter-example to disprove your negative-work argument: goroutines. Also known as: CSP-style concurrency in a procedural language.

I urge you to read up on goroutines. There are quite a few examples on the golang site of how you can use this feature to good effect, examples that would require you to think very differently than if you were in C.

Also, I'd like to point out that the Go project got started because Rob Pike and Ken Thompson grew tired of long build times while working with C++ while at Google. One of Go's objectives is fast compilation times. They are willing to stick to this goal at the expense of complex type systems. This is, if it is anything, not negative work.

Re: Go is amazing, period.

#76

Post by enneff »

ootachi wrote: post #66
drivebyacct2 wrote: post #64

Earlier quoted context omitted.

Maybe I'm mistaking terminology but that doesn't seem like a type issue you're describing.

There's no one definition of type safety. It ultimately depends on what your type system is trying to enforce. I strongly suspect, however, that most programmers expect "type-safe" languages to enforce memory safety, and that Go's lack of memory safety is surprising in this context.

That is a very unusual definition of "type safety." What you're describing is more commonly known as "thread safety," in my experience.

By your definition, is Java type safe? You still need to guard against concurrent mutation of shared data in Java and in most other languages that support shared mutable state.

We typically describe Go as "memory safe," in that you can't address uninitialized memory (unless you import package "unsafe", which clearly demonstrates your intent).

Re: Go is amazing, period.

#77

Post by enneff »

ootachi wrote: post #55
brnstz wrote: post #25

Earlier quoted context omitted.

Go has the advantage of being developed by Rob Pike and Ken Thompson. It also potentially has the marketing muscle of Google behind it, although the most I've seen so far is free stuffed Gophers at OSCON. Type safety, easy concurrency, static checking, C-like syntax, fast compilation time, concise syntax, etc. Java is ripe for replacing as the default language for (new) large systems. The replacement could be another…

Depends what you mean by type safety. If by type safety you mean free from segfaults, Go is very much type-unsafe (send a map over a channel, access it concurrently, and it will segfault).

> send a map over a channel, access it concurrently, and it will segfault

Not exactly. Go's maps may safely be read from multiple threads simultaneously, but writing at the same time as reading or writing will yield undefined behavior.

Go programs don't segfault like C programs. They typically panic, providing a descriptive stack trace of where the problem arose.

As I mentioned in my other thread, what you're describing are "thread safe data structures," which Go doesn't provide by default. We provide the fast and non-thread-safe data structures and let the programmer build the concurrency mechanisms around them (easily done with a lock or using goroutines/channels).

Re: Go is amazing, period.

#78

Post by CamperBob »

georgemcbay wrote: post #36

As someone who is 38, and has programmed in everything from 6510/68k/MIPS/ARM assembler to C/C++ to ActionScript/haxe/JavaScript to D to Python, et al, I also think Go is pretty great. In addition to the cool things in the language, I really love what they are doing with the build system. The Go programming I've been doing has been on Windows but targeting an ARM CPU (the PXA168 in the Chumby 8 device) and cross-comp…

I'm historically a braces-on-their-own-line guy, so getting used to the strict enforcement of the other style was a pain for me

Wait, what?

Re: Go is amazing, period.

#79

Post by dsymonds »

ootachi wrote: post #60
srean wrote: post #34

I have'nt managed enough time yet to familiarize myself with Go, but the little that I have glanced at, it seems a nice enough language for scientific computation. The syntax and semantics of arrays are nice and binding to C is purportedly simple. Ease of binding with Fortran would have been nice too. So I find it a bit strange that I never hear of Go in the context of array based computation, that is the stuff peopl…

The concurrent stop-the-world garbage collector is a performance issue. Additionally, the Plan 9-based compiler is not an optimizing compiler.

Have you found the GC to be an actual problem? Or are you assuming it is? It's a very different situation to other GC-based languages.

Re: Go is amazing, period.

#80

Post by enneff »

ootachi wrote: post #62
gukjoon wrote: post #42

Earlier quoted context omitted.

Wow. 1. Have you written or debugged C sockets code? Because if you have, I doubt you would be dinging him on not wanting to do that. 2. He doesn't want to handle C/C++. I would say that most people who write application code are with him. 3. Yeah... I'm pretty sure Python, an interpreted language, is slower than Go, a compiled language. Even with the progress PyPy is making, I doubt it's going to beat Go. The author…

PyPy is an optimizing JIT compiler; 6g/8g is not an optimizing compiler. I'm pretty sure one could construct examples in which PyPy beats Go for this reason (try something that relies on loop-invariant code motion, for example). Additionally, PyPy has many garbage collection algorithms, while Go has a stop-the-world mark-and-sweep collector.

PyPy is an amazing project, but it is my understanding that the Python language makes certain guarantees (particularly around thread safety) that will hamper the speed of any implementation for a long time.

Go is still really young, yet it's plenty fast. There's plenty of room for it to get much faster.

Post reply on HN