Live data from Hacker News

Half a decade with Go

blog.golang.org

161–170 of 257 posts

Re: Half a decade with Go

#161

Earlier quoted context omitted.

Because of the implicit thing! The api designer doesn't have to write the interface, you can do it yourself. As long as naming conventions are kept to and the signature matches, you can apply this anywhere. Imagine a close() interface in Java. There isn't one - but having a try {...} finally { x.close(); } can be very useful sometimes. But having interface graphs made of granular interfaces makes everything slow and…

Like duck typing?

I suspect this is like duck typing with some verification before compilation : the compiler checks that the object sent as parameter implements the correct interface.

Re: Half a decade with Go

#162

I would really like to see go binaries that is not like a 1mb in size. In practice is not like I don't have space for 1MB But I still want proper linking to a shared "golib"

Binary sizes are a concern, particularly with a move to mobile devices and later embedded systems.

However for Go's current platforms, I would call it a non-issue. Static builds, something seemingly long forgotten though supported in other compiled languages, make deployment and distribution that bit easier.

I would support static builds by default, optional dynamic builds.

Re: Half a decade with Go

#163
Go is an average language but it's a solid product.

The tooling is excellent. A lot of thougt has been put into making things simple. From the folder structure to the final binary, everything is smooth.

It's just a shame that the language design itself is quite behind the times. Older languages had a lot to offer to a new one. The day it launched it was already old. And I don't see a lot of goodwill to change the language to fill the glaring omissions.

Python in this respect is quite an example : iterators, generators, ABC were carefully added without making any less approachable. It prooves it is possible, but that the kind of things the Go leaders apparently simply don't consider.

Re: Half a decade with Go

#164

Earlier quoted context omitted.

> It reads data from reader and writes to writer... simple. Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). The first way you will probably use it will be to copy between some stream and a file without having to eat up all the memory to store the buffer (not using ioutil.ReadAll for example)... but then you realize you can use a gzip compres…

Because of the implicit thing! The api designer doesn't have to write the interface, you can do it yourself. As long as naming conventions are kept to and the signature matches, you can apply this anywhere. Imagine a close() interface in Java. There isn't one - but having a try {...} finally { x.close(); } can be very useful sometimes. But having interface graphs made of granular interfaces makes everything slow and…

> Because of the implicit thing!

Known as structural typing and available in most modern languages.

Re: Half a decade with Go

#165
post #30

Earlier quoted context omitted.

Neat. You can start an Erlang process (or whatever they're called) with an anonymous function, and pass it another anonymous function that closes over another lexical environment?

Absolutely: do_stuff() -> GetAnswer = fun() -> 42 end, spawn(fun() -> io:format("The answer is ~p\n", [GetAnswer()]) end). Here, GetAnswer is a closure, as is the anonymous function given to spawn() function.

And here is why these functional langauges will never make main stream.

I've, been programming for 20+ years and I look at that code and say what the f*k?

Ooh, it's the functional stuff. Ok, move on.

Re: Half a decade with Go

#166
post #137
post #126

Earlier quoted context omitted.

If languages like Haskell and Erlang gave a competitive advantage, wouldn't we see companies which used them succeeding over those that don't? Maybe Go is fitting into the cultures that succeed, and if that's the case, well it's the better choice, right?

> If languages like Haskell and Erlang gave a competitive advantage, wouldn't we see companies which used them succeeding over those that don't? We are. WhatsApp generated a flurry of interest around Erlang. Heroku uses it. I'm sure there are more examples. Google is at this point already a large corporation and probably already in decline (IMO). The tools they use are optimized for interchangeability of mediocre pro…

[deleted]

Re: Half a decade with Go

#167

Earlier quoted context omitted.

Like duck typing?

I suspect this is like duck typing with some verification before compilation : the compiler checks that the object sent as parameter implements the correct interface.

It's called structural typing.

Re: Half a decade with Go

#168
post #130
post #42

Earlier quoted context omitted.

What weaknesses of Pascal are being repeated in Go?

There is no escape. The language thinks it knows better than you. The standard library is allowed to do things that your code isn't.

Like what? The standard library is no more special, other than where it resides in the filesystem. You can write C and assembly code as well and link it to your Go code. And I'm not talking about cgo, I mean [568][ac], the Plan 9 C compiler and assembler that come with Go.

Re: Half a decade with Go

#169
post #103
post #93

Sometimes I wonder: if Apple's new language had been Go, and Google's new language had been Swift, how would reaction by developers and adoption have differed? (You can also run this thought exercise with Go and Rust, if you prefer a different competition between self-proclaimed systems languages.)

I'm not totally sure how a non-optionally garbage-collected language with a runtime could ever be called a "systems language."

The "systems" in the term "systems language" the Go team used shortly after initially releasing Go refers to systems like Google has them running.

Re: Half a decade with Go

#170
post #4

> , we were calling Go a "systems language" And maybe in another 5 years, people will stop bickering over whether that description is/was appropriate. :)

If only people would not willfully ignore the implicit "at Google" or "for Google" that a lot of things said about Go carry. Go may be a terrible language from the PLT POV, but it's meant to solve problems Google has.
Post reply on HN