Go 1.8 is out
-
https://twitter.com/brianhatfield/status/634166123605331968
https://twitter.com/brianhatfield/status/692778741567721473
https://twitter.com/brianhatfield/status/767812346760859648
https://twitter.com/brianhatfield/status/767890817587539968
https://twitter.com/brianhatfield/status/804355831080751104BUT BEN, I DON'T WANT TO USE GO WHY CAN'T I USE SOMETHING LIKE PYTHON BUT WITH THAT GARBAGE COLLECTOR AND WITH NO GLOBAL INTERPRETER LOCK
shush
-
-
-
What are the axes and what are all the lines?
-
@Jaloopa The axes are used to intimidate people into using Go, and the lines are recordings of their screams.
Or it might be something to do with execution time and GC load.
-
@ben_lubar
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.364ccn532"Our garbage collector is revolutionary because we optimized it for minimal pause times." - Yeah, right…
-
Was performance really the most important issue they could have tackled?
My impression is, most people are lukeworm about go due to its half baked module system and the lack of some powerful constructs (eg. generics), leading to fiddly verbose code.
-
@cartman82 also, duck-typed interfaces. Who the hell thought it was a good idea in statically compiled language!?
-
@GÄ…ska said in Go 1.8 is out:
@cartman82 also, duck-typed interfaces. Who the hell thought it was a good idea in statically compiled language!?
Not sure about that.
From what little I've seen, I haven't had problems with that. As time goes by, I'm less and less of a fan of single-inheritance.
-
@cartman82 said in Go 1.8 is out:
As time goes by, I'm less and less of a fan of single-inheritance.
I have no idea how that statement is in any way related to duck-typing. I'm honestly confused.
-
Languages are irrelevant. Turn it into a common language infrastructure and then we'll talk.
-
-
-
-
@asdf said in Go 1.8 is out:
Go is building a garbage collector (GC) not only for 2015 but for 2025 and beyond …
Hmm. This statement seems oddly familiar.
-
@cvi Tomorrow's garbage collector today!
-
@cvi said in Go 1.8 is out:
@asdf said in Go 1.8 is out:
Go is building a garbage collector (GC) not only for 2015 but for 2025 and beyond …
Hmm. This statement seems oddly familiar.
a garbage collector for the next ten years.....?
DAMMIT
FBMACJEFF! YOU RUINED ANOTHER LANGUAGE FOR EVERYONE ELSE!
-
@RaceProUK said in Go 1.8 is out:
@cvi Tomorrow's garbage collector today!
I'd buy that for a dollar!
No... wait... I think I'm jumbling my references now...
-
@Onyx said in Go 1.8 is out:
I'd buy that for a dollar!
-
@Onyx said in Go 1.8 is out:
@RaceProUK said in Go 1.8 is out:
@cvi Tomorrow's garbage collector today!
I'd buy that for a dollar!
No... wait... I think I'm jumbling my references now...
I'll gladly pay you Tuesday for a garbage collector today.
-
@accalia said in Go 1.8 is out:
@Onyx said in Go 1.8 is out:
I'd buy that for a dollar!
I was going for Robocop, but sure, Smash TV works.
-
@Onyx said in Go 1.8 is out:
@accalia said in Go 1.8 is out:
@Onyx said in Go 1.8 is out:
I'd buy that for a dollar!
I was going for Robocop, but sure, Smash TV works.
one was riffing on the other, so sure. :-)
also, nice ID. you've done this before!
-
@accalia said in Go 1.8 is out:
a garbage collector for the next ten years.....?
Oh, was it phrased that way originally? Can't remember. Seemed close enough, though. ;-)
-
@cvi said in Go 1.8 is out:
@accalia said in Go 1.8 is out:
a garbage collector for the next ten years.....?
Oh, was it phrased that way originally? Can't remember. Seemed close enough, though. ;-)
probably not, i was drawing a closer analog to make the joke work.
-
@asdf said in Go 1.8 is out:
I have no idea how that statement is in any way related to duck-typing. I'm honestly confused.
Duck typing interfaces is go's alternative to OOP.
But it's been a while, maybe I'm misremembering.
-
@cartman82 said in Go 1.8 is out:
Duck typing interfaces is go's alternative to OOP.
Well, but the opposite of duck typing is explicit interfaces that you have to implement explicitly, which has nothing to do with inheritance.
-
@cartman82 said in Go 1.8 is out:
As time goes by, I'm less and less of a fan of single-inheritance.
I prefer single inheritance and explicit interfaces to multiple inheritance, if only because it's easier to manage name clashes (at least, that's how it is in the languages I use regularly).
-
@RaceProUK said in Go 1.8 is out:
if only because it's easier to manage name clashes
Hm? Name clashes with multiple inheritance are just as easy to handle as name clashes with multiple interfaces.
The only thing that makes multiple inheritance annoying to use is the diamond inheritance problem. In languages where every class inherits from a base class "Object", you would always have to deal with that.
-
@RaceProUK said in Go 1.8 is out:
I prefer single inheritance and explicit interfaces to multiple inheritance
Also note that in C++, many interfaces are implemented as concepts, not as abstract base classes. So it actually uses a mixture of duck typing and multiple inheritance where other languages would use interfaces.
-
@ben_lubar said in Go 1.8 is out:
BUT BEN, I DON'T WANT TO USE GO WHY CAN'T I USE SOMETHING LIKE PYTHON BUT WITH THAT GARBAGE COLLECTOR AND WITH NO GLOBAL INTERPRETER LOCK
BUT BEN, I DON'T WANT TO USE GO WHY CAN'T I USE SOMETHING LIKE PYTHON BUT WITH THAT GARBAGE COLLECTOR AND WITH NO GLOBAL INTERPRETER LOCK JUST AN INSANE PACKAGE MANAGEMENT AND WEIRDER SYNTAX
-
@asdf said in Go 1.8 is out:
Also note that in C++, many interfaces are implemented as concepts, not as abstract base classes.
That's because static polymorphism and dynamic polymorphism are two separate concepts in C++ that don't play together at all.
One thing I love about Rust is that traits work both for static and dynamic polymorphism, which means library developers don't have to spend any time thinking which approach will be better for most future users of their library.
-
@RaceProUK said in Go 1.8 is out:
@cartman82 said in Go 1.8 is out:
As time goes by, I'm less and less of a fan of single-inheritance.
I prefer single inheritance and explicit interfaces to multiple inheritance, if only because it's easier to manage name clashes (at least, that's how it is in the languages I use regularly).
Multiple inheritance only makes sense when there is no other option, like you have your class already derived but want to enable shared from this.
-
@GÄ…ska said in Go 1.8 is out:
One thing I love about Rust is that traits work both for static and dynamic polymorphism, which means library developers don't have to spend any time thinking which approach will be better for most future users of their library.
Rust has awesome concepts, but I won't use it for new projects until they finally make their borrow checker a bit smarter (flow-sensitive), so you don't have to put unnecessary blocks everywhere.
Also, I'm missing something similar to macros that can modify the attributed AST. In their current state, where you have no type information at all, macros are not even close to a replacement for templates.
-
@asdf said in Go 1.8 is out:
many interfaces are implemented as concepts, not as abstract base classes
What does that mean? Not sure I've heard of concepts in that context before
-
@Jaloopa said in Go 1.8 is out:
What does that mean? Not sure I've heard of concepts in that context before
For example, Iterator is a concept in C++, not an interface. Which means that certain operators, functions and typedefs are expected to be implemented in an iterator, so that you can use it like any other iterator in a template (or in regular code).
-
There are two people in the world that like Go — @ben_lubar, and the hivemind at Google that wrote it.
And we're not sure if that's just @ben_lubar's sockpuppet.
-
@pydsigner said in Go 1.8 is out:
the hivemind at Google that wrote it.
And we're not sure if that's just @ben_lubar's sockpuppet.I heard it was just Ben's DF AI. Built a fortress, harvested some drunk cats (or whatever dwarves do) and then wrote Go.
-
@cvi said in Go 1.8 is out:
@asdf said in Go 1.8 is out:
Go is building a garbage collector (GC) not only for 2015 but for 2025 and beyond …
Hmm. This statement seems oddly familiar.
I'd say disturbingly familiar.
-
@cvi said in Go 1.8 is out:
@asdf said in Go 1.8 is out:
Go is building a garbage collector (GC) not only for 2015 but for 2025 and beyond …
Hmm. This statement seems oddly familiar.
: "How do you suppose it was that we gained sub-millisecond garbage collection?"
: "It cannot be..."
: "Search your weblogs. You know it to be true..."
: "Luke, we used a CDN."
: "GOOOOOOOOOOOOOOOOOOOOOOOOOO"— Code Wars V: The Trojan Disc-Horse Strikes Back
-
@pydsigner Imagine if Go banned all of us from using their language.
Ben would not be happy.
-
@anonymous234 But the rest of us would.
Filed under: The good of the many outweighs the good of the few.
-
@HardwareGeek But then how would I run my Python code with the most advanced garbage collector and no global interpreter lock?
Oh, right, IronPython.
-
@asdf said in Go 1.8 is out:
"Our garbage collector is revolutionary because we optimized it for minimal pause times." - Yeah, right…
This seems relevant to the "it's not a science" thread:
It has been known since 1984 that most allocations “die young” i.e. become garbage very soon after being allocated. This observation is called the generational hypothesis and is one of the strongest empirical observations in the entire PL engineering space. It has been consistently true across very different kinds of programming languages and across decades of change in the software industry: it is true for functional languages, imperative languages, languages that don’t have value types and languages that do.
And the article as a whole seems related to the "Linus on Innovation" thread, comparing innovative garbage collection techniques with Go's iteratively improving the old stuff approach.
So does anyone know the state of the art on computed disposal? That is, the compiler figuring out (whenever possible) where things can get freed and directly freeing it at the right places and times instead of waiting for it to be collected?
-
@Dreikin said in Go 1.8 is out:
@asdf said in Go 1.8 is out:
@ben_lubar
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.364ccn532"Our garbage collector is revolutionary because we optimized it for minimal pause times." - Yeah, right…
This seems relevant to the "it's not a science" thread:
It has been known since 1984 that most allocations “die young” i.e. become garbage very soon after being allocated. This observation is called the generational hypothesis and is one of the strongest empirical observations in the entire PL engineering space. It has been consistently true across very different kinds of programming languages and across decades of change in the software industry: it is true for functional languages, imperative languages, languages that don’t have value types and languages that do.
And the article as a whole seems related to the "Linus on Innovation" thread, comparing innovative garbage collection techniques with Go's iteratively improving the old stuff approach.
So does anyone know the state of the art on computed disposal? That is, the compiler figuring out (whenever possible) where things can get freed and directly freeing it at the right places and times instead of waiting for it to be collected?
Go's compiler puts things on the stack unless it absolutely needs to put them on the heap. For example, you can allocate a bunch of pointers to structures and pass them around, but if they never escape the scope of the function they were allocated in, it'll just put them on the stack in the first place.
Go's garbage collector doesn't have to deal with the objects that "die young" because they were never on the heap in the first place.
-
@anonymous234 said in Go 1.8 is out:
@HardwareGeek But then how would I run my Python code with the most advanced garbage collector and no global interpreter lock?
Oh, right, IronPython.
Gee, I wonder why people might want to have a small static binary instead of a giant framework for their microservice...
-
@Dreikin said in Go 1.8 is out:
So does anyone know the state of the art on computed disposal?
I'm not 100% up to speed, but compilers can do a hell of a lot where they know enough. “Know enough” requires determining where a memory object comes into being, where it ceases to be talked about through known references, whether the functions you call modify anything, and knowing that nobody's playing shenanigans with address arithmetic. Once you've got all that (actually pretty common where you've got the right annotations on your library functions) then it can work out where you've got genuine short-lived memory, and that's a candidate for migration to the stack (and other generalised trickery).
Compilers can also insert a lot of information about where variables are and when they're holding meaningful data. OTOH, when things absolutely must live on the heap and absolutely need to be passed around all over, everything gets more complicated. I've yet to figure out how to tell a compiler to assume that it is working with strictly a single thread and that memory objects don't cross thread boundaries (except in special areas) as that would allow the heap to be tamed more thoroughly, but that might be my lack of study…