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

A year with Go

vagabond.github.io

Post reply on HN
Print view View original

91–100 of 235 posts

Re: A year with Go

#91

Post by ascendantlogic »

sanderjd wrote: post #46
baudehlo wrote: post #29

Earlier quoted context omitted.

HN was the same about Node too. In a year we will see the same articles about Rust.

See also: AngularJS, Rails, etc. A lot of this is just because things that a technology makes convenient fade into the background after awhile because you know longer feel the pain you felt before you had them, but you are actively reminded of the things that annoy you about a technology multiple times a day. For example, with Go, fast static compilation and "just works" deployment fade, while the copy-paste-tweak pa…

As I get older and I gain more perspective, I can't stress enough how true this is. Listening to younger programmers bemoan Ruby and Rails is humorous to me because they don't remember the world of Java web dev before Rails. Miles of XML configs everywhere, factories, impls, proxies, beans. So. Much. Boilerplate.

It's easy to bitch about things the way they are now, but understand there are people and technologies who were around before you arrived on the scene and in general, things are consistently getting "better", for all subjective interpretations of "better".

Re: A year with Go

#92

Post by chc »

neoyagami wrote: post #68
chc wrote: post #41

Earlier quoted context omitted.

Having tools that can spot errors early, help you track them down quickly and help you comprehend, organize and refactor your code can be very useful with a large codebase, and I don't think it's fair to characterize that as "you need an IDE that speaks the language in order to write anything efficiently."

Like gosublime?

Yes, Gosublime is a good example of how tooling can be helpful, though from what I can tell it is somewhat less helpful than what you'd expect in a decent IDE (e.g. no refactoring support, the interface is mainly dropdowns, weak support for finding definitions and usages).

Re: A year with Go

#93

Post by ascendantlogic »

felixgallo wrote: post #44
nickysielicki wrote: post #31

> "I just don’t understand the point of Go. If I wanted a systems language, I’d use C/D/Rust, if I wanted a language built around concurrency I’d use Erlang or Haskell." Agreed. C and Rust are systems langauges, Go is not particlarly great in that category. That is okay. I will say, I hope you have fun getting an average CS graduate to properly write and maintain a Haskell or Erlang program with concurrency. Go is st…

> But the fact remains, an average programmer can sit down today with no knowledge of Go, and by the end of the day create a concurrent program using Go. If there's any benchmark more pointless than the alioth benchmarks game, it's the 'what can a novice programmer do with the language in the course of 8 hours' benchmark. There are zero businesses that operate by giving novice programmers 8-hour tasks in unfamiliar l…

The first company I was at prided itself on the "sink or swim" method of hiring. You'd be surprised how many developers out there judge new hires by how quickly they show they can start shipping code.

Re: A year with Go

#94

Post by seanmcdirmid »

pcwalton wrote: post #54
nemothekid wrote: post #27

> Adding proper mutexes to some of our code in production slowed things down so much it was actually better to just run the service under daemontools and let the service crash/restart. Can the author explain this bit some more? If adding mutexes slows down your code to the point where you would rather just deal with data corruption/races it seems to me that there are issues with your code, not the language.

Yeah, that seems weird. A properly implemented mutex is one atomic instruction in the uncontended path to lock and one more to unlock. And if you remove the mutex, you're turning "the contended path" into "the path that blows up your program". Atomic instructions can be painful on, for example, ARM (where they turn into load linked/store conditional loop + memory barrier) but they shouldn't be too bad on x86 servers.…

It is not unprecedented, e.g. see:

http://en.wikipedia.org/wiki/Crash-only_software

Martin Rinard at MIT has done a lot of work in this area. It can be safe if you can rollback to a good state to avoid data corruption.

Glitch, my current project, does not bother with reader locks for multi-core execution; instead it can rollback and retry when a write-after-read is detected effects are logged (dependencies are traced so write-after-reads can be detected). It has performance benefits if you can amortize the book keeping overhead, and we need to do it anyways to support live programming (see: http://research.microsoft.com/en-us/people/smcdirm/managedti...).

Re: A year with Go

#95

Post by crimsonalucard »

codygman wrote: post #84
eloff wrote: post #7

Earlier quoted context omitted.

Or just a practical concurrent language with strong libraries that lets you be productive quickly. I'm aware of many of the theoretical benefits of Erlang and Haskell over Go. But Go is still a much better choice for getting things done.

As someone who used Go in the past for work and now uses Haskell, I can say that the advantages of Haskell over Go are more than "just theoretical". In my day job I use Haskell to "just get shit done". However when it comes time to refactor I can do it much faster and safer in Haskell. The ease of refactoring creates an incentive to improve code.

Seems like Go and other imperative languages are easier to start a project off with, but functional languages really shine when the code becomes really large and complex.

Re: A year with Go

#96

Post by Skinney »

andrepd wrote: post #73
twic wrote: post #72

Earlier quoted context omitted.

> And compared to Java, the fact that Go compiles to a native binary is a huge benefit. I'm baffled by this. I've been deploying Java applications for years, and this has literally never been a problem. You build a WAR (or EAR, or uberjar, or distzip, or whatever). You install a JRE on the machine. You deploy. You're done. It's never been a problem for me, and it's not something that's talked about as a problem in th…

I think you must agree that no matter how painless it is, binary < JAR + JRE, in terms of deployment effort.

Depends. For me, creating an uberjar with my default project/package manager is easier than to setup cross-compilation with Go. YMMW.

Re: A year with Go

#97

Post by Skinney »

falcolas wrote: post #82
twic wrote: post #72

Earlier quoted context omitted.

> And compared to Java, the fact that Go compiles to a native binary is a huge benefit. I'm baffled by this. I've been deploying Java applications for years, and this has literally never been a problem. You build a WAR (or EAR, or uberjar, or distzip, or whatever). You install a JRE on the machine. You deploy. You're done. It's never been a problem for me, and it's not something that's talked about as a problem in th…

> You deploy. You're done. Then you set your memory parameters. Then you tweak them, to make it more performant. Then you increase them some more to make the GC work less. Then you hook up to the JMX port so you can profile what's going wrong, and identify some XML library as allocating megabytes of strings when it then dumps. Then... Yeah.

Setting memory parameters and tweaking them would be similar to deciding what compilation flags to use when compiling your program. I also much prefer profiling over JMX than re-compiling the application with the profile flag activated and re-deploying.

Re: A year with Go

#99

Post by crimsonalucard »

ascendantlogic wrote: post #93
felixgallo wrote: post #44

Earlier quoted context omitted.

> But the fact remains, an average programmer can sit down today with no knowledge of Go, and by the end of the day create a concurrent program using Go. If there's any benchmark more pointless than the alioth benchmarks game, it's the 'what can a novice programmer do with the language in the course of 8 hours' benchmark. There are zero businesses that operate by giving novice programmers 8-hour tasks in unfamiliar l…

The first company I was at prided itself on the "sink or swim" method of hiring. You'd be surprised how many developers out there judge new hires by how quickly they show they can start shipping code.

It's the wrong approach, but it does happen.

Re: A year with Go

#100

Post by ffn »

If backend programming was epic fiction, then right now, the world is divided into the following countries: The Kingdom of Java, The United Languages of .Net, and the Confederacy of the Scripting Tongue (where racial tensions are crackle under the temporary truce between Ruby, Python, Javascript, Lua, etc.). For the past decade, these three kingdoms constantly struggled against each other for the most precious resource of all: developer mind-share.

But what they didn't know and couldn't prevent, was that their world would soon become (neigh, has already become) the battle ground of 3 ultra-advanced warring alien species: Go, Rust, and Elixir. Backed by unimaginably powerful forces (except Elixir, which is just open-source by Poland's own Jose Valim), the upstart alien languages threaten to herald in a terrifying future for the current 3 powerhouses.

OP's article, and the fact that lots of people are agreeing, is a sign that one of the invading aliens is weakening.

Post reply on HN