GopherCon 2014 Videos(confreaks.com)
confreaks.com
GopherCon 2014 Videos
http://confreaks.com/events/gophercon2014
8 comments
From the first link:
Finally, the relative numeric success of Gopher over WWW was discussed (there are orders of magnitude more Gopher servers than WWW servers out there): Gopher seems to have won out primarily because of the ease of entry (it's much harder to put up a WWW server than a Gopher server), although another factor may be that a hierarchical presentation is more appropriate than hypertext for the broad-based audience of a CWIS.
:)
Finally, the relative numeric success of Gopher over WWW was discussed (there are orders of magnitude more Gopher servers than WWW servers out there): Gopher seems to have won out primarily because of the ease of entry (it's much harder to put up a WWW server than a Gopher server), although another factor may be that a hierarchical presentation is more appropriate than hypertext for the broad-based audience of a CWIS.
:)
When I started my CS degree we still used mostly Gopher, the WWW browsers started to appear on campus AIX, DG/UX terminals around one year later.
I was pretty disappointed when Mozilla dropped native Gopher support from Firefox.
There's still plugins for it though.
There can be overlap here with Gopher servers written in golang like https://code.google.com/p/gogopherd/.
I've been meaning to extend a Hakyll backend for Gopher sites, and then to set up a RPi gopher server and duplicating my site to it.
Or actual gophers for that matter.
cuervocon > gophercon
> Ken: lary and sergey came by tonight...
> Ken: p.s. one of larrys comments was "why isnt function spelled func?
> Rob: fine with me. seems compatible with 'var'
> Rob: anyway we can always say, "larry said to call it 'func'"
> Ken: p.s. one of larrys comments was "why isnt function spelled func?
> Rob: fine with me. seems compatible with 'var'
> Rob: anyway we can always say, "larry said to call it 'func'"
I really enjoyed the keynote.
The joke about the profound error of using whitespace just shows how partisan these discussions are. In go, with the semi-colon insertion rules and with gofmt, there is an implicit whitespace rule all over again.
Personally, I like whitespace because its how my mind reads code. Its nice in Python, mostly because of how concise Python is to read. Its a bit of a bind in Java, where you don't trust tools to roll-up functions but on the other hand they all seem so long and full of boilerplate. With gofmt, the go world lives in a significant whitespace world they just don't want to admit it :)
The joke about the profound error of using whitespace just shows how partisan these discussions are. In go, with the semi-colon insertion rules and with gofmt, there is an implicit whitespace rule all over again.
Personally, I like whitespace because its how my mind reads code. Its nice in Python, mostly because of how concise Python is to read. Its a bit of a bind in Java, where you don't trust tools to roll-up functions but on the other hand they all seem so long and full of boilerplate. With gofmt, the go world lives in a significant whitespace world they just don't want to admit it :)
> The joke about the profound error of using whitespace just shows how partisan these discussions are. In go, with the semi-colon insertion rules and with gofmt, there is an implicit whitespace rule all over again.
Other than lisps, most languages have significant whitespace -- treating, for instance, newlines as having an important distinctions from other whitespace.
Other than lisps, most languages have significant whitespace -- treating, for instance, newlines as having an important distinctions from other whitespace.
> In go, with the semi-colon insertion rules and with gofmt, there is an implicit whitespace rule all over again.
So this is technically correct (and I had never though about that before, so thank you for pointing that out!). However, I think '\n' and '\r' are not directly comparable to '\t' and ' ' characters.
All whitespace is only visible by its boundaries (kinda like certain 70s minimalist sculpture, actually). Newlines affect vertical structure, whereas tabs and spaces affect horizontal structure. So far it's the same.
However, we don't read text vertically, we read it horizontally (I know there are exceptions, but not in any significant programming languages that I know of). As a result we don't group characters by vertical whitespace the same way as we group characters by horizontal whitespace: in most natural languages, the difference is paragraph separation vs word/sentence separation. Programming languages also follow this coarse/refined level. Think about how we construct indented text in programming languages: relative to the vertical position.
So I would say that while both cases have the problem that we can only observe whitespace by the characters that surround them, in the vertical whitespace that happens at a coarser, less ambiguous level than horizontal whitespace. And I think that's why using significant newlines should be less failure prone than significant tabs/spaces.
So this is technically correct (and I had never though about that before, so thank you for pointing that out!). However, I think '\n' and '\r' are not directly comparable to '\t' and ' ' characters.
All whitespace is only visible by its boundaries (kinda like certain 70s minimalist sculpture, actually). Newlines affect vertical structure, whereas tabs and spaces affect horizontal structure. So far it's the same.
However, we don't read text vertically, we read it horizontally (I know there are exceptions, but not in any significant programming languages that I know of). As a result we don't group characters by vertical whitespace the same way as we group characters by horizontal whitespace: in most natural languages, the difference is paragraph separation vs word/sentence separation. Programming languages also follow this coarse/refined level. Think about how we construct indented text in programming languages: relative to the vertical position.
So I would say that while both cases have the problem that we can only observe whitespace by the characters that surround them, in the vertical whitespace that happens at a coarser, less ambiguous level than horizontal whitespace. And I think that's why using significant newlines should be less failure prone than significant tabs/spaces.
> However, we don't read text vertically, we read it horizontally (I know there are exceptions, but not in any significant programming languages that I know of).
I think we do read code vertically and it is significant in all programming languages, and I think that it is a core problem with acceptance of Lisps, because they unusually strongly avoid leveraging the two-dimensional nature of typical code editing environments in favor of having pretty much the perfect purely-horizontal syntax.
> So I would say that while both cases have the problem that we can only observe whitespace by the characters that surround them, in the vertical whitespace that happens at a coarser, less ambiguous level than horizontal whitespace.
I do think there is an ambiguity difference, but its not because we read horizontally but not vertically, but because horizontal whitespace in common use -- i.e., that people are used to using on a keyboard in the context of programming -- is limited to newlines (and, while there are different means of expressing newlines, they are mostly driven by platform rather than personal preference and are, in any case, easy to account for), whereas tab/space holy wars are as old as line oriented PLs that allow indentation (whether they are sensitive to it or not).
I think we do read code vertically and it is significant in all programming languages, and I think that it is a core problem with acceptance of Lisps, because they unusually strongly avoid leveraging the two-dimensional nature of typical code editing environments in favor of having pretty much the perfect purely-horizontal syntax.
> So I would say that while both cases have the problem that we can only observe whitespace by the characters that surround them, in the vertical whitespace that happens at a coarser, less ambiguous level than horizontal whitespace.
I do think there is an ambiguity difference, but its not because we read horizontally but not vertically, but because horizontal whitespace in common use -- i.e., that people are used to using on a keyboard in the context of programming -- is limited to newlines (and, while there are different means of expressing newlines, they are mostly driven by platform rather than personal preference and are, in any case, easy to account for), whereas tab/space holy wars are as old as line oriented PLs that allow indentation (whether they are sensitive to it or not).
> I think we do read code vertically and it is significant in all programming languages
Of course it is significant, I was agreeing with you there! But my point was:
d
o
_
y
o
u
_
e
v
e
r
_
w
r
i
t
e
_
c
o
d
e
_
l
i
k
e
_
t
h
i
s
?
But maybe I should have worded it differently: we read text in "row-major order", not "column-major order". That's basically the difference I talk about.
Also, there is another difference between newlines and indentation: newlines only go "forward" (next line), whereas with indentation you go back and forth into levels of indentation. It's not the same. The closest thing I can think of is that one language where you could write the exponent of a formula on a line before, faking superscript, or the index of a formula on the next, faking subscript. Making mono-typed source code look like math formulas basically (and probably a pain to type out). That's the only programming context I can think of where newlines are actually significant in a similar fashion to indentation.
Of course it is significant, I was agreeing with you there! But my point was:
d
o
_
y
o
u
_
e
v
e
r
_
w
r
i
t
e
_
c
o
d
e
_
l
i
k
e
_
t
h
i
s
?
But maybe I should have worded it differently: we read text in "row-major order", not "column-major order". That's basically the difference I talk about.
Also, there is another difference between newlines and indentation: newlines only go "forward" (next line), whereas with indentation you go back and forth into levels of indentation. It's not the same. The closest thing I can think of is that one language where you could write the exponent of a formula on a line before, faking superscript, or the index of a formula on the next, faking subscript. Making mono-typed source code look like math formulas basically (and probably a pain to type out). That's the only programming context I can think of where newlines are actually significant in a similar fashion to indentation.
> In go, with the semi-colon insertion rules and with gofmt, there is an implicit whitespace rule all over again.
Can you explain what this means?
Can you explain what this means?
It means that you have to be careful about how you treat whitespace (mostly newlines and how they relate to curly braces), otherwise a semicolon could be inserted where it shouldn't or gofmt could format your code in a way you didn't mean to. So, the whitespace is significant in Go too.
Newlines are important, but that's true of pretty much every language. Go does have more stringent requirements on where open braces are placed, but it's not a hard rule to remember (they always go on the same line as the code that opens the new scope). Also, this rule makes your code significantly less prone to breakage from errant edits and merges, since inserting a line can never separate your brace from the line it goes with. In this way, Go is actually more robust with respect to whitespace than almost any other language.
Note that in languages that don't mandate the open brace be on the same line as the code that opens the new scope, this can happen during a merge:
Gofmt will never change the behavior of your code, so you don't have to "worry" about what it will do. It only makes cosmetic changes to code, never functional.
Note that in languages that don't mandate the open brace be on the same line as the code that opens the new scope, this can happen during a merge:
// original code
if (foo)
{
printf("foo is true!")
}
// after the merge
if (foo)
someFunction()
{
printf("foo is true!")
}
Gofmt will never change the behavior of your code, so you don't have to "worry" about what it will do. It only makes cosmetic changes to code, never functional.
I think the way Go treats coding styles is great. I don't have any problems following a one true convention enforced by the language and being aware about the minute details of code structuring in order to avoid problems in translation. Funnily, the language that taught me all that was Python.
As willvarfar points out, I feel Rob Pike is being disingenous when he talks about this. Golang uses less significant whitespace than Python, but it exists, the difference is in degree. If he prefers to minimize the impact of whitespace in Go code, that's fine. But why does he have to talk about it as an error or misjudgment?
If significant whitespace is such a bad idea, why do exist keywords that require whitespace around them in Go (package, func, type, etc.? Why can't I use whitespace in names in Go? This didn't happen in good old FORTRAN ;)
As willvarfar points out, I feel Rob Pike is being disingenous when he talks about this. Golang uses less significant whitespace than Python, but it exists, the difference is in degree. If he prefers to minimize the impact of whitespace in Go code, that's fine. But why does he have to talk about it as an error or misjudgment?
If significant whitespace is such a bad idea, why do exist keywords that require whitespace around them in Go (package, func, type, etc.? Why can't I use whitespace in names in Go? This didn't happen in good old FORTRAN ;)
This seems like a logical fallacy. Of course you have to separate your language's tokens with something. This is not "significant" whitespace. It's token delimiters, and they don't generally need whitespace. for example func(){return 1} has no whitespace between func and the open paren, also
Whitespace is not significant in Go.
The difference between significant whitespace and requiring "some" whitespace is that if you did something like that in Python, you could end up with a program with different logic depending on which spaces were flipped to tabs. This is why mixing spaces and tabs in Python is verboten.
In go, you can mix spaces and tabs all you want, wherever you want in your code and it will never ever change the logic of your code, period. (obvious exceptions for changes inside string literals)
So, it's not really a matter of degrees, and Python's method is completely broken if you ever mix tabs and spaces, which as Rob Pike points out, are completely indistinguishable in the default views of most editors.
func (){
a := 1
return a
}
Whitespace is not significant in Go.
The difference between significant whitespace and requiring "some" whitespace is that if you did something like that in Python, you could end up with a program with different logic depending on which spaces were flipped to tabs. This is why mixing spaces and tabs in Python is verboten.
In go, you can mix spaces and tabs all you want, wherever you want in your code and it will never ever change the logic of your code, period. (obvious exceptions for changes inside string literals)
So, it's not really a matter of degrees, and Python's method is completely broken if you ever mix tabs and spaces, which as Rob Pike points out, are completely indistinguishable in the default views of most editors.
Did you know that almost all your example is perfectly doable in Python? Try this:
The Python coding style guideline (PEP 8) is very specific in that it recommends the use of 4 leading spaces per level. You can use a very simple program with regular expressions to solve any problem you could have in the mix of tabs and spaces in your files.
Now, try this example in FORTRAN.
def my_func ( ) :
a = 1
return a
The Python coding style guideline (PEP 8) is very specific in that it recommends the use of 4 leading spaces per level. You can use a very simple program with regular expressions to solve any problem you could have in the mix of tabs and spaces in your files.
Now, try this example in FORTRAN.
parameter(x=2)
print*,"The parameter is ",x
I didn't specifically take the time to make code that would break in python, obviously, I could, and it would be trivial to do so.
Yes, it's just leading spaces that are different in Python, I know. I actually like python, but the space indenting is fragile.
Yes, it's just leading spaces that are different in Python, I know. I actually like python, but the space indenting is fragile.
It's similarly trivial to make syntactically correct code that breaks in Go.
Example:
My point is, there isn't such a big difference between Go and Python. Significant whitespace doesn't mean "whatever Python does differently", it means that whitespace is syntactically meaningful. Any whitespace in any part of your program has the potential for changing the meaning of it. If it does, then it's significant.
It's trivial to make a text editor show tabs and insert spaces even if you press tab. It's trivial to make a program that will switch leading tabs for the number of spaces that you want from a file. I don't say it's trouble-free, but it isn't such a big issue; and automatic semicolon insertion isn't trouble-free either, as you can see. You won't have problems with any of them if you take a little care.
In Python, leading whitespace and newlines are syntactically significant. In Go, newlines are in many cases syntactically significant. In both of them space around many keywords is significant (try to write packagemain in Go, see how it goes), and you can't put whitespace in names.
if (a == 1) {
return a }
else { return b }
My point is, there isn't such a big difference between Go and Python. Significant whitespace doesn't mean "whatever Python does differently", it means that whitespace is syntactically meaningful. Any whitespace in any part of your program has the potential for changing the meaning of it. If it does, then it's significant.
It's trivial to make a text editor show tabs and insert spaces even if you press tab. It's trivial to make a program that will switch leading tabs for the number of spaces that you want from a file. I don't say it's trouble-free, but it isn't such a big issue; and automatic semicolon insertion isn't trouble-free either, as you can see. You won't have problems with any of them if you take a little care.
In Python, leading whitespace and newlines are syntactically significant. In Go, newlines are in many cases syntactically significant. In both of them space around many keywords is significant (try to write packagemain in Go, see how it goes), and you can't put whitespace in names.
Sorry, I forgot, you can also do this in Python:
def my_func():a=1;return a;
I've wondered what the story was on Go's dependency management, so I'm glad someone brought it up at the end of the keynote. Pike said that it was up to the community to develop tools to deal with that. This is what happened in the Clojure community when Leiningen became the de facto standard, but its dependency management builds on a pre-existing system (Maven). I am curious if this is on anyone's radar, or if it isn't considered a problem.
Take some popcorn and go through the discussions on golang-nuts mailing list.
There is a big discussion between those that think a language without dependency management tooling does not make sense in modern times.
And those that think it should be abolished from the face of earth and replaced with git revisions and pure open source, regardless of industry needs.
There is a big discussion between those that think a language without dependency management tooling does not make sense in modern times.
And those that think it should be abolished from the face of earth and replaced with git revisions and pure open source, regardless of industry needs.
Ruby's dependency management (rubygems) also came from the community and is now part of the standard library. That seems like a good model to follow.
Dependency management for Go is definitely on people's radar. https://github.com/tools/godep has been getting some traction.
Dependency management for Go is definitely on people's radar. https://github.com/tools/godep has been getting some traction.
Same with Python/pip with 3.4
Isn't "go get ..." the dependency management tool for Go?
Not really.
Only works for source code packages, not binary dependencies.
There isn't a way to specific source code versions/tags in a portable way. Also makes the import paths dependent on your repositories.
Only works for source code packages, not binary dependencies.
There isn't a way to specific source code versions/tags in a portable way. Also makes the import paths dependent on your repositories.
> [go get] Only works for source code packages, not
> binary dependencies.
> There isn't a way to specific source code versions/tags
> in a portable way.
___
[0] http://peter.bourgon.org/go-in-production/#dependency-manage...
[1] https://github.com/tools/godep
Vendoring is a practice stuck in C and C++ archaic tooling support ideas.
I am on the side for proper dependency management.
> It's one of Go's greatest strengths, actually.
Which will keep it outside the boring closed source enterprise commercial library tooling.
I am on the side for proper dependency management.
> It's one of Go's greatest strengths, actually.
Which will keep it outside the boring closed source enterprise commercial library tooling.
> I am on the side for proper dependency management.
Responses to dependency management and generics from Go supporters always sound like la-la-la hands-in-the-ears denial to me.
"X? We don't need no stinkin' X".
"X? We don't need no stinkin' X".
It's true: not all features yield net benefit.
My car doesn't have a blender, a mini-fridge, or a hot tub. Some cars do. I don't think my car is worse off because of their lack.
Along the same lines, my mother used to always buy cars that were manual transmission and without power windows or locks, because they were features which made the car cost more, broke often, and were expensive to fix. The minor conveniences they afforded were not worth the costs.
Along the same lines, my mother used to always buy cars that were manual transmission and without power windows or locks, because they were features which made the car cost more, broke often, and were expensive to fix. The minor conveniences they afforded were not worth the costs.
I'm curious to know what you think proper dependency management looks like.
Vendoring is also a practice that Google and other large tech companies use extensively. Just because something is old doesn't mean it's a bad idea.
My C, C++ and Java Ant scars in Fortune 500 consulting projects tell me otherwise.
That's fine. Some do it badly, and some do it well.
So why is Google moving away from Ant to Gradle in Android, while having Pub Packages for Dart?
Does not seem very supportive of vendoring.
Does not seem very supportive of vendoring.
I don't know anything about Android or Dart development, so I can't speak for them. All I can say is that internal Google development has been happily using vendoring of third-party code for many years (and not just C/C++ code), so I'm confident in saying that vendoring Go code can work just fine for "boring closed source enterprise commercial library tooling".
It is, but it doesn't do versioning, and people often like to target specific versions of the libraries that their programs depend on.
Finally! Thanks for all the effort!
I am watching the keynote, it looks interesting. I don't know Go at all, though I know several languages including C.
I don't quite know what he is talking about when he talks about main and initialization. Can anyone elaborate on this for me?
I hate to say this because I feel like a jerk in doing so, but I'm about 25 minutes in and the little gopher that scrolls across the screen (some sort of advertisement, I think) is so distracting. It is awful.
I don't quite know what he is talking about when he talks about main and initialization. Can anyone elaborate on this for me?
I hate to say this because I feel like a jerk in doing so, but I'm about 25 minutes in and the little gopher that scrolls across the screen (some sort of advertisement, I think) is so distracting. It is awful.
Function main() in package "main" is the entry point for a Go application but it is not the first code that gets executed when you start a Go app. Each package can have an init() function which gets executed in the order of dependency (if pkg A imports pkg B then B.init() is executed before A.init()) before main.main() is executed.
It's slightly more complicated than that: In addition to the init() function, variables on the package level can be initialized during initialization too.
For example: http://play.golang.org/p/tvlX7cqaaB
This is important for package level variables such as arrays. Since there are only a very limited number of types which can be constants in Go, everything else which you'd use like a constant needs to be initialized.
For example: http://play.golang.org/p/tvlX7cqaaB
This is important for package level variables such as arrays. Since there are only a very limited number of types which can be constants in Go, everything else which you'd use like a constant needs to be initialized.
If we go in details, we can also add that goroutines created in init() or at init time are effectively started only after all init() functions finish.
I see. Thank you.
Not a Go expert, but I think it has to do with global variables/constants in modules. In C, what can run before main() is extremely limited. In C++, much more can happen before main(), i.e. running constructors for static objects, and the initialization order is undefined (this is a pretty well known problem).
I guess in Go you can also have relatively elaborate static initialization, so it has a similar problem as C++? Interested if any Go users can elaborate on this.
I guess in Go you can also have relatively elaborate static initialization, so it has a similar problem as C++? Interested if any Go users can elaborate on this.
Like in the Object Pascal/Modula-2 language family, you can define a package initialization sections.
There are executed before control reaches main, and you need to have import relationships into consideration.
There are executed before control reaches main, and you need to have import relationships into consideration.
So, in the keynote, Rob underlines again that there'll be no generics. Ever.
Path to getting generics thus becomes:
1. A preprocessor that eats ggo (generic go) files and emits go. This is is like the original C++ which translated to C for compilation.
2. Someone integrates ggo into go to speed it all up.
Path to getting generics thus becomes:
1. A preprocessor that eats ggo (generic go) files and emits go. This is is like the original C++ which translated to C for compilation.
2. Someone integrates ggo into go to speed it all up.
> So, in the keynote, Rob underlines again that there'll be no generics. Ever.
No. He said there were no plans for generics, which has been the story for some time. The official FAQ still states [0]:
> Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.
> Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
It is my understanding that what Mr. Pike means by there being no plans for generic is in relation to the sentence
> We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.
[0] http://golang.org/doc/faq#generics
No. He said there were no plans for generics, which has been the story for some time. The official FAQ still states [0]:
> Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.
> Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
It is my understanding that what Mr. Pike means by there being no plans for generic is in relation to the sentence
> We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.
[0] http://golang.org/doc/faq#generics
>No. He said there were no plans for generics, which has been the story for some time.
No, the official apologist story is: we will add them as soon as we find a way to avoid all tradeoffs of the 3 different approaches to generics.
And when asked how are they going to find this "magic bullet" solution since noone seems to be looking for it, some Go devs wrote HN comments to say that "we are looking into them [generics]".
I'm a little offended, because nobody admitted what Rob said at the conference -- and they even tried to convince us of the contrary. That was like 2-3 months ago.
No, the official apologist story is: we will add them as soon as we find a way to avoid all tradeoffs of the 3 different approaches to generics.
And when asked how are they going to find this "magic bullet" solution since noone seems to be looking for it, some Go devs wrote HN comments to say that "we are looking into them [generics]".
I'm a little offended, because nobody admitted what Rob said at the conference -- and they even tried to convince us of the contrary. That was like 2-3 months ago.
At the very end of the keynote, he fields questions from the audience.
Predictably, he is asked about generics (54 mins in). His reply is very clear:
"There are no plans for generics. I said we're going to leave the language; we're done."
Predictably, he is asked about generics (54 mins in). His reply is very clear:
"There are no plans for generics. I said we're going to leave the language; we're done."
By "the language" he means Go major-version-1. There will be no generics in Go 1, that's clear. The path is wide open for Go 2, though.
Nowadays I consider Go as a better C, except for those scenarios where C is being used as a portable assembler.
Other than that, I spend my time with other languages.
Rob said something interesting at the end, it appears they are leaving the language to the community and stepping out.
Other than that, I spend my time with other languages.
Rob said something interesting at the end, it appears they are leaving the language to the community and stepping out.
> Rob said something interesting at the end, it appears
> they are leaving the language to the community and
> stepping out.
At 54:51 in response to the generics question, "I said we are going to leave the language, we are done".
What else does one use C for? Applications that are too latency-sensitive for garbage collection maybe, but Go doesn't help there.
Lots of apps are better with C, not just with regards to latency sensitivity (e.g games).
E.g an app that would process a multimedia file offline (so latency is of no concern) still runs circles around most other languages if its done i C or C++.
And of course 90% or something of desktop apps are written in C/C++.
People act as all those apps, which is what we use everyday, don't exist: browsers, editors, media players, terminals, OSes, mailers, etc etc. Even web apps use those as their substrate.
E.g an app that would process a multimedia file offline (so latency is of no concern) still runs circles around most other languages if its done i C or C++.
And of course 90% or something of desktop apps are written in C/C++.
People act as all those apps, which is what we use everyday, don't exist: browsers, editors, media players, terminals, OSes, mailers, etc etc. Even web apps use those as their substrate.
Object Pascal, Ada, Modula-2,...
Sure, I don't disagree with those (and Fortran, Obj-C, up to Rust someday).
Just wanted to highlight that most desktop programs people use by the millions are in fact written in C/C++ (statistically) -- and it's not all about GC, web programming and services.
Just wanted to highlight that most desktop programs people use by the millions are in fact written in C/C++ (statistically) -- and it's not all about GC, web programming and services.
AIUI the main reason for using C for multimedia processing is to have inline assembler to make the best use of SIMD; aside from that it's certainly possible to write a video transcoder in Haskell (I've seen it done, for ARM where there didn't used to be such powerful SIMD options available).
Which is not even part of the C language standard.
Any compiler for any language can have SIMD support, it is just a matter of the compiler writers bothering to provide such support.
And if the language does not support it, I don't see why developers are so afraid of touching a Macro Assembler.
Any compiler for any language can have SIMD support, it is just a matter of the compiler writers bothering to provide such support.
And if the language does not support it, I don't see why developers are so afraid of touching a Macro Assembler.
Sadly for too many user space applications that are better served with safer languages, having native compilers available, that tend to be ignored by many.
In one of the talks (I believe Q/A), he said "Go does have generics, they are called interfaces".
This is a point that folks new to Go often miss. I oftentimes see people compare "interface{}" to "Object" in Java, which is not true.
(If you don't believe me, note that not everything in Java is actually an Object - since there are multiple typekinds[0], that means that not every type can be used where Java expects to see an Object). That is part of the reason for the mess surrounding the so-called wrapper types like Integer (which are themselves neither objects (wrappers are passed by value, not reference) nor primitives (they are in most[1] cases unboxed to primitives, but are not themselves the same things as primitives).
Aside from the fact that Java didn't add generics until 1.5 (if I remember correctly), which certainly didn't stop its popularity, it cannot be emphasized enough that the need for generics is dramatically reduced if one actually understands how to use interfaces idiomatically in Go and understands how they are different from "interfaces" in Java or other languages[2].
While I occasionally run into a situation in which Java-like generics would make things marginally easier, they're few and far between; interfaces bridge far more of the difference than non-Go programmers often realize. And has has been explained to death already (both at Gophercon and on the mailing list) - generics are not out of the question for a hypothetical Go 2, but there are going to be no more changes to the language syntax for Go 1.
[0] I counted either 5 or 6 at one point when I was using Java heavily in university, but that was several years ago so don't quote me on that exact number.
[1] emphasis on "most" - there are some very "fun" edge cases that you can find here!
[2] I'm reminded of how Haskell has both "class" and "return" as keywords that have nothing to do with their Java counterparts - I think Go's "interface" is along the same lines - it's the same identifier/term, but a very different meaning.
(If you don't believe me, note that not everything in Java is actually an Object - since there are multiple typekinds[0], that means that not every type can be used where Java expects to see an Object). That is part of the reason for the mess surrounding the so-called wrapper types like Integer (which are themselves neither objects (wrappers are passed by value, not reference) nor primitives (they are in most[1] cases unboxed to primitives, but are not themselves the same things as primitives).
Aside from the fact that Java didn't add generics until 1.5 (if I remember correctly), which certainly didn't stop its popularity, it cannot be emphasized enough that the need for generics is dramatically reduced if one actually understands how to use interfaces idiomatically in Go and understands how they are different from "interfaces" in Java or other languages[2].
While I occasionally run into a situation in which Java-like generics would make things marginally easier, they're few and far between; interfaces bridge far more of the difference than non-Go programmers often realize. And has has been explained to death already (both at Gophercon and on the mailing list) - generics are not out of the question for a hypothetical Go 2, but there are going to be no more changes to the language syntax for Go 1.
[0] I counted either 5 or 6 at one point when I was using Java heavily in university, but that was several years ago so don't quote me on that exact number.
[1] emphasis on "most" - there are some very "fun" edge cases that you can find here!
[2] I'm reminded of how Haskell has both "class" and "return" as keywords that have nothing to do with their Java counterparts - I think Go's "interface" is along the same lines - it's the same identifier/term, but a very different meaning.
> This is a point that folks new to Go often miss.
It's still not true that interfaces are generics, though.
> Aside from the fact that Java didn't add generics until 1.5 (if I remember correctly)
But that was a big mistake in Java: they had to implement them using type erasure and primitives didn't work with them (due to backwards compatibility), and they had to duplicate the collections library to have non-generic and generic collections (again due to backwards compatibility).
> [2] I'm reminded of how Haskell has both "class" and "return" as keywords that have nothing to do with their Java counterparts - I think Go's "interface" is along the same lines - it's the same identifier/term, but a very different meaning.
I don't think the difference is that stark—interfaces in Java and interfaces in Go are essentially the same thing. The facts that all values can be wrapped in an interface (which is also true for C#, I believe) and that interface matching is structural instead of nominal are relatively minor.
It's still not true that interfaces are generics, though.
> Aside from the fact that Java didn't add generics until 1.5 (if I remember correctly)
But that was a big mistake in Java: they had to implement them using type erasure and primitives didn't work with them (due to backwards compatibility), and they had to duplicate the collections library to have non-generic and generic collections (again due to backwards compatibility).
> [2] I'm reminded of how Haskell has both "class" and "return" as keywords that have nothing to do with their Java counterparts - I think Go's "interface" is along the same lines - it's the same identifier/term, but a very different meaning.
I don't think the difference is that stark—interfaces in Java and interfaces in Go are essentially the same thing. The facts that all values can be wrapped in an interface (which is also true for C#, I believe) and that interface matching is structural instead of nominal are relatively minor.
So disappointed, again, that this has nothing to do with my alma mater, the U of MN.
I mean, there is a precedent for this sort of thing.
http://iubio.bio.indiana.edu/soft/util/gopher/gophercon1.txt
[1]: https://en.wikipedia.org/wiki/Gopher_%28protocol%29
[2]: gopher://gopher.floodgap.com/
[3]: https://addons.mozilla.org/en-US/firefox/addon/overbiteff/
[4]: gopher://sdf.lonestar.org/