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?
Half a decade with Go
161–170 of 257 posts
Re: Half a decade with Go
#162I 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"
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
#163The 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
#164Earlier 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…
Known as structural typing and available in most modern languages.
Re: Half a decade with Go
#165Earlier 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.
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
#166Earlier 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…
Re: Half a decade with Go
#167Re: Half a decade with Go
#168Earlier 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.
Re: Half a decade with Go
#169Sometimes 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."
Re: Half a decade with Go
#170> , we were calling Go a "systems language" And maybe in another 5 years, people will stop bickering over whether that description is/was appropriate. :)