Live data from Hacker News

Six years of Go

blog.golang.org

261–270 of 327 posts

Re: Six years of Go

#261

I have a bit of a love-hate relationship going on with Go. On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library. On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using up…

I'm in the same boat. Go's simplicity is initially refreshing, then a huge pain once you find yourself writing the same thing over and over again. A good example is errors being values — which is a great idea. But then you realize every single function needs to be littered 1-10 cases of if err != nil { return nil, err } It's an extremely common pattern. It's tiring to write, over and over. Tiring to refactor, too: If…

I agree, but i create Fatal and not fatal functions.

func checkErrPanic(err error) { if err != nil { panic(err) } }

func checkErrNonFatal(err error) { if err != nil { fmt.Println(err) return } }

Re: Six years of Go

#262
post #64

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few: 1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusi…

> It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. (...) The reason for the move were few: 1) Ambivalence on Java roadmap So, because there was some "ambivalence for the Java roadmap", a language with multiple implementations, a huge community (including open source), and so entrenched in the industry that will be there in 2100 too, you switched to a 3-4 yea…

> a language with multiple implementations,

Yeah, where the owner is suing one of those multiple implementations, and playing silly buggers with J2EE certification. That really lends a fuckton of conifidence.

Re: Six years of Go

#263
post #169

Earlier quoted context omitted.

Voice of dissension here. I switched from: * Mysql to MongoDB * PHP to Python * Javascript to Coffeescript All because I was bored of the old tech. and it made the site unmaintainable. I mostly blame the MongoDB and Coffeescript for that. Now to be fair, I learned a ton and I am so glad for that experience, but I lost my website.

Oh, you switch to MongoDB if you are bored with your current job ;) Otherwise PostgreSQL is what you switch to.

What's the problem with document databases, really? To be honest, for 80% of the projects I've ever worked with, fixed-schema rdbms's fitted just like... a square peg in a round hole!

Heck, even for advanced analytics, I find mongo aggregates and mongo map reduce 10x more intuitive and SQL that inevitably ends up using zillions of non-portable tricks, stored procedures and god knows what. And atomicity and whatever else transactions guarantee you in theory can be easily emulated with some good db structure design tricks and app design tricks in practice.

And the smarter a RDBMS is, like Postgres, the more dangerous it becomes for maintainability: it's a zillion times easier to maintain 'logic expressed in app code' (because you have basic stuff like version control, tests and so on), than 'logic trapped in the db' (good luck explaining to a new developer how "X automagically happens because of trigger Y and stored procedure Z, so there is no app code for X that you can instantly tweak to change how it works"). This is why I at least have some respect for mysql: it's retarded enough that it forces you to put the login in the code, where it f belongs!

Really, give me a dumb document db like mongo any day! And if I want something "less dumb" there're things like arangodb and rethinkdb that can also do joins and graphs. And there're also "true graph-dbs" for index-less "joins"/traversals, like neo4j and orientdb, for when the relationships for when you actually end up doing more than 3 to 4 levels deep joins...

Imho the development of "high-end rdbms" like postgress and oracle has been a huge waste of human brainpower and all the benefits supposedly provided by these pieces of technology were actually from the clever app-level code that mostly worked around their inappropriateness...

Re: Six years of Go

#264
post #92

Earlier quoted context omitted.

You based a business decision to switch language on "boredom"? What size team are you working with, that you were able to switch from Java to Go?

Yeah odd choice in that Go is a very boring language (and its enthusiasts consider this a feature).

What's "boring" about it? I'd argue that the possibilities for crazy concurrency patterns make it exciting.

Re: Six years of Go

#265

I have a bit of a love-hate relationship going on with Go. On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library. On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using up…

You really should check out vibed. It meets most of hte requirements of slinging JSON around, being easy to build and deploy, has a powerful and consistent library. And it's not terrible to work in: http://vibed.org

Re: Six years of Go

#266

Earlier quoted context omitted.

It's funny that you mention Java because I have always avoided learning Java. Even from afar it grosses me out as a language. I actually think comparing Go to Java is silly because a lot of motivation behind Go's design came out of avoiding what was done to Java and C++. The point is, plenty of companies manage to create very good production software with Go, without generics. I didn't mean to rest my argument on my…

> It's funny that you mention Java because I have always avoided learning Java. Even from afar it grosses me out as a language. May I guess you're either some old Lisp/Smalltalk etc veteran, or, much more probably, someone who entered IT after, say 2005? Because back in the day very few thought of Java as "gross" -- it was greeted as a welcome change from the existing landscape which at its best was something like C+…

I'm 23, I haven't been around that long :)

Re: Six years of Go

#267

Earlier quoted context omitted.

Curious your opinion on what you would advise if not Martini or Gin? I love martini (and lately gin) and definitely love and use go every day. What about these frameworks is not idiomatic go? Is there another framework that is? Or you suggest just rolling your own using net/http by itself? Cheers

I remember awhile ago Martini used to have a large performance hit that Gin didn't. I think it had something to do with the url multiplexer, wouldn't be surprised if it's since been fixed but it was the reason I initially chose Gin when I first started writing Go.

> I think it had something to do with the url multiplexer

"Slow" in the case of a router/mux is entirely relative though. There's been this strange focus on routing speed/allocations, when its the smallest slice of your total request-to-response performance. Martini's router won't make your application noticeably slower than any other.

Re: Six years of Go

#268
post #103

Earlier quoted context omitted.

Yes, every language/framework is good at something and bad at some other. They are just tools. What matters is what one builds. A lot of technical news these days are about tools, not products.

Sure, I can run with that analogy. So a master woodcarver works with chisels, his "tools", for his entire life...30 years, and with them he turns bare wood into incredible works that the world recognizes as valuable art. Someone hands him a chainsaw, which by all measurable metrics should allow him to do the work 10x faster because, of course, it is more powerful, modern, and designed by "superior minds" whom underst…

Yes, of course. Chainsaws are an ideal tool for large scale wood carving. https://www.youtube.com/watch?v=tPJ9t3jIBjA

Re: Six years of Go

#269
post #214

Earlier quoted context omitted.

Ha. I built my first company on Java back in 1996. It was a terrible decision. Very buggy, lots of BS from Sun & Oracle that was really more about Ellison and McNealy envying Bill Gates. Netscape made a similarly bad decision when they tried to create a pure Java version of the browser. I'm sure Java is 10x better now, but I'm not convinced it will be here in 2100.

It will be, because there is now more Java running business processes than there is Cobol, and Cobol is surprisingly still with us. Profitable code dies hard.

I don't think there's any 85 year old Cobol though. Most of the S&P 500 is less than 50. It's entirely conceivable the companies that embrace new technologies starting today will, within 50 years, extinguish or acquire most of the of the companies using technologies from 1995.

Re: Six years of Go

#270

Earlier quoted context omitted.

Ha. I built my first company on Java back in 1996. It was a terrible decision. Very buggy, lots of BS from Sun & Oracle that was really more about Ellison and McNealy envying Bill Gates. Netscape made a similarly bad decision when they tried to create a pure Java version of the browser. I'm sure Java is 10x better now, but I'm not convinced it will be here in 2100.

What ? Of all the languages Java is the most likeliest to be around in 2100. It is the lingua de franca of enterprise software development. In every sense it is the modern day Fortran/Cobol.

Cobol was the modern day Cobol in 1995, and that was just 20 years ago. 85 years is a long time.
Post reply on HN