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

Go 1.6 is Released

blog.golang.org

Post reply on HN
Print view View original

321–330 of 367 posts

Re: Go 1.6 is Released

#321

Post by grey-area »

iofj wrote: post #317
grey-area wrote: post #275

Earlier quoted context omitted.

What are you using generated code with lots of types for out of interest? I haven't felt the need as yet but would like to try it out. Re handlers, you really don't have to use the http handler. I use one which accepts a context, and returns an error (for rendering), which simplifies the boilerplate somewhat as errors are rendered by the router. I'd look into using your own interfaces before generating standard http…

> What are you using generated code with lots of types for out of interest Firstly, for data access methods (think load struct type X from offline storage). It's like gobs or encoding/*, but it blasts those away when it comes to speed. Secondly, for searching through data (given a list of struct type X, and some number of indexes of the data (essentially listing what the sorting order is according to one of the field…

If it has been generated as boilerplate (e.g. To build out an API) with the explicit purpose of being extended, I think it's fine. It just saves a lot of typing. It's only inappropriate if you'd be better to adjust the template, not the code generated; if you're adding unique code (which you should be), it's fine IMO.

Re: Go 1.6 is Released

#322

Post by pcwalton »

_0w8t wrote: post #239
sinatra wrote: post #5

Go checks a lot of boxes for my ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports concurrency very well, is opinionated, is small/simple, its community prefers to just use standard lib for most work, etc. Yes, Generics is an issue and so is debugging. But, overall, I can't think of many other options that check so many boxes. EDIT: I must h…

Go tools support code generators. So just use those for advanced data structures. As auto-generated it can support more features than even an advanced generics could provide. For me the big minus of Go is that it is memory unsafe language when it runs with GOMAXPROCS>1 (default since 1.5). It is not that bad like in C as opportunities for bugs are not common, still this is an issue as consequences of such bugs is arb…

> As auto-generated it can support more features than even an advanced generics could provide.

No, it can't. There are patterns that no monomorphization strategy (including code generation) can express. For example:

    func MakeList(x T) List {
        ...
    }

    func Foo(x T) {
        if ... {
            Foo(MakeList(x))
        }
    }
This is a contrived example, but this shows up from time to time in functional data structures.

Re: Go 1.6 is Released

#323

Post by d4rkph1b3r »

autoreleasepool wrote: post #276
d4rkph1b3r wrote: post #210

Earlier quoted context omitted.

>For better or worse, CS departments across the US produce Java programmers more than anything else. Do you think this large pool of programmers are good? >This makes it very easy to hire Java developers. Yes, if you are looking for sub-par developers. I don't think Google thinks to itself "oh man we're so glad we use java, otherwise hiring would be challenging". No, they have just as much difficultly hiring as anyon…

> Do you think this large pool of programmers are good? Yes, why not? I have yet to see evidence that Java programmers are not good. Seems like a discriminatory mindset. The large pool also makes them easy to replace. I think Facebook has had an ad for an Erlang developer for a few months now. I don't think a startup needs that kind of stress. Also, I'm sure there are Java Devi who are absolutely fantastic. That is,…

Eh, most of my post was an emotional response because of my hatred of the java language. Your reasoning I mostly agree with.

I do agree, the JVM is a solid language choice. I also don't think going with too esoteric of a language is a good thing. Probably a little early to bet a company on Idris or Ceylon.

Still, I apologize for my tone. Let me give you purely anecdotal information about me, so you can at least see where I'm coming from with regards to my anti-java stance.

After doing java/C# for many many years, I will not do it again. I'm much more productive in Scala/F#/ML, it's more pleasant to use, and I believe the average programmer using those languages ends up being a different caliber than the java programmers.

There are absolutely good Java programmers. They just probably work at Google or Facebook and you'll be competing with Google. I would take less money (and have, though not too much less) to not work at Google because I get to use a functional language.

shrug

If a startup is using java, I think to myself 'why java? why not Scala, F#, or C# at the very least?'. Usually the answer is 'scala/F# programmers are too hard to find', but that's not really true, what they mean is they're not willing to pay the 20% premium for them. That's a strong indicator that a start up doesn't value talent.

Re: Go 1.6 is Released

#324

Post by jjnoakes »

Goopplesoft wrote: post #315
jjnoakes wrote: post #274

Earlier quoted context omitted.

This didn't directly answer my question, but it implies that you just periodically update all of your dependencies to the latest versions and pray your tests pass with minimal changes required. Yes?

The tools essentially causes that to happen (its a bad thing). When someone installs your package (and you don't pin them somehow with something like godeps, path management, http://labix.org/gopkg.in , etc) you recursively retrieve the deps from some source at HEAD and that package is now updated for every other package using that GOPATH.

Oh, I misread the parent I replied to. I thought he was saying he downloads a copy of his dependencies and commits them to his repository without any tooling.

But he was only saying he uses the tools (which auto-update as your run them), and commits the result as a poor man's pinning arrangement.

Makes sense now. My questions are moot.

Re: Go 1.6 is Released

#325

Post by steveklabnik »

pori wrote: post #306
cies wrote: post #283

Earlier quoted context omitted.

> It seems the landscape for functional alternatives are mainly Scala and Clojure Cannot talk about functional alternatives without mentioning Haskell. OCaml (when abstaining from the "O", as many OCaml'ers do; similarly Scala'ers often abstain from the "O" in Scala) is also an interesting option. Finally there's Rust, which is besides being a bit more functional also more low-level than Go. While being fairly young,…

Well, I was tempted to mention Haskell. Problem is, I haven't found a practical use for it. Of all the FP languages, this is actually the one I am most tempted by. I had forgotten about Rust. Are there major projects being used for this yet? I've heard it's picking up quite a bit.

Depends on how you define "major". Dropbox is currently running Rust in production, at the core of their product. Has been for about six weeks now. That's probably the largest, most serious use. There are also tiny bits in Firefox, that will be included starting with the next release.

There's a lot of other usage too, it all depends on how you define "major".

Re: Go 1.6 is Released

#326

Post by tumdum_ »

protomyth wrote: post #296
tumdum_ wrote: post #121

Earlier quoted context omitted.

1) Was this static C library? Then you need to recompile. If it was dynamic then the question is did abi change? If yes, you need to recompile, otherwise you don't (but security updates usually don't break abi). 2) Always. 3) Yes, Go runtime is linked in to executables build with Go.

Does Go include external libraries (stuff not written in Go) as dynamic links or static?

It's up to you to decide how/what you want to link, just like in C. I've prepared simple example at https://github.com/tumdum/go_libs that you can use to see how exactly it's all working.

Re: Go 1.6 is Released

#327

Post by dilap »

randallsquared wrote: post #320
dilap wrote: post #308

Earlier quoted context omitted.

A reasonable attitude for client-side code, perhaps, ('oh it blew up, I'll reopen the app and try again/rerun the script'), but I think not so reasonable for server-side code.. There's element of personal preference here. The longer I program the more I favor systems and styles that minimize unexpected problems; explicit error handling is very much in that vein. Another complication is that the word "error" actually…

> A reasonable attitude for client-side code, perhaps, ('oh it blew up, I'll reopen the app and try again/rerun the script'), but I think not so reasonable for server-side code.. This seems like a response to something that wasn't my comment. I even went out of my way to state what I thought might be obvious: "pay as much attention as required to make things work". Handling errors is a given in this thread. The quest…

Well, ultimately all I can say is that my personal experience is it's easier for me to build software to the level of quality I want using an explicit error handling regime (like Go) than an implicit, exception-throwing regime (which I've used with Python and C++). YMMV.

Re: Go 1.6 is Released

#328

Post by _0w8t »

pcwalton wrote: post #322
_0w8t wrote: post #239

Earlier quoted context omitted.

Go tools support code generators. So just use those for advanced data structures. As auto-generated it can support more features than even an advanced generics could provide. For me the big minus of Go is that it is memory unsafe language when it runs with GOMAXPROCS>1 (default since 1.5). It is not that bad like in C as opportunities for bugs are not common, still this is an issue as consequences of such bugs is arb…

> As auto-generated it can support more features than even an advanced generics could provide. No, it can't. There are patterns that no monomorphization strategy (including code generation) can express. For example: func MakeList (x T) List { ... } func Foo (x T) { if ... { Foo(MakeList(x)) } } This is a contrived example, but this shows up from time to time in functional data structures.

Code generation can do type erasure starting, for example from List>.

Re: Go 1.6 is Released

#329

Post by protomyth »

tumdum_ wrote: post #326
protomyth wrote: post #296

Earlier quoted context omitted.

Does Go include external libraries (stuff not written in Go) as dynamic links or static?

It's up to you to decide how/what you want to link, just like in C. I've prepared simple example at https://github.com/tumdum/go_libs that you can use to see how exactly it's all working.

Thank you, its much appreciated.

Re: Go 1.6 is Released

#330

Post by munificent »

prodigal_erik wrote: post #309
munificent wrote: post #55

Earlier quoted context omitted.

> Is there a reason why one of these hasn't emerged/been adopted by the community? Personally, I believe package management is one of those things that really does need an official blessed solution. Otherwise, you have a nasty bootstrapping problem: if there are ten competing package managers, how do you install them, and how do package developers know which one to put their packages in? Collection types have the sam…

Use the platform's blessed solution (rpm or dpkg). It's ridiculous for a language to consider a solution worthy of blessing when it doesn't interop with the one my platform was already using or even the ones other languages have.

> Use the platform's blessed solution (rpm or dpkg).

Most languages are cross-platform. No language maintainer is going to say, "sorry, Windows, Mac, or user, you don't get to use our language."

Likewise, you can't require every package maintainer to just publish their package to every single OS and distro's package repository every time they want to release a new version. Well, you can, you just want have any users if you do.

Post reply on HN