"Engineering is programming integrated over time" -- Titus Winters. i need this quote framed somewhere (i am not a c++ dev lol, love you guys all the same)
I've been saying this for years (since I worked at Amazon in 2003/4/5). It's very gratifying to learn that this person has come to the same conclusion. It was so frustrating to be stuck with an old version of RH and an old version of gcc at Amazon then. My argument then was that they should give developers desktops that had everything new, and a test environment that had all the old stuff. Stupid dependencies would get sanded off over time. Depending on a particular version is really inefficient and terribly brittle. It's the wrong answer. I've always felt that way. I've really disliked tools for Python like virtualenv because they encourage a model I think is fundamentally broken.
True. I too worked at Amazon in 2015 and this thing hasn't changed. At google we have we have all the developer machines always at head (by default). We can go back in time to a different past snapshot of "Google" which is never recommended and only done to reproduce/debug old issues. We can do all the development/testing/debugging locally and finally commit to make the "new head".
I worked at Amazon in 2015. I really didn't like the versioning and stupid dependencies among the different versions of different libraries. Now I am at google and the developer experience is blissful
Concerning absl::Duration. Why not write a absl::int96 (or however you want to do your safe and saturating arithmetic), and then use std::chrono::duration? You could even type alias this to absl::Duration. The advantage of this technique is that now your absl::int96 work is available for all kinds of other needs, in addition to addressing a need in time keeping. And you assure your users that you are using a time-tested and familiar interface (chrono).
We could, but compiler messages would be more confusing, and then we're more reliant on QOI for standard library chrono support with alternative reps on every platform. We chose to keep it controlled, but honestly it probably boiled down to "we already have this and the two approaches are very close".
1:10:19 "I don't want you extending my types." It's merely your library. It's MY app. If I want to accept the possibility of my app breaking in the future after updating to a newer abseil, that's my burden to gauge. UFC = 👍.
One question, if you can automatically change usage of some library in code base, then why you need to do this at all? This mean that this code base do not depends on most of this api. This is equivalent to crating couple of wrappers and use them in your code and change manually only this couple of function not whole code base.
Just a guess since I don't work for Google, I think it's short for Alpha(B)et Standard Library. I'm guessing based on the purpose of the library and that ABSL is their chosen prefix.
It's mentioned in the follow-up talk "Hands-On with Abseil" The library was originally abcl for abc library, but that couldn't go public for legal reasons. So they took the way people pronounced the name internally and invented a new spelling.
hearing the words at 1:23:10 is... well, disheartening. It is one of the problems that affect millions and costs a lot of resources during development. "Buy another CPU" is not a solution for development - if you have the time and money to create large build-systems that are available to everyone ok. But if you need to change some parts of the code right then and there for say a live-hotfix.... yeah, it is not nice if you know that your small bugfix, cause it is in a template-heavy reagion linked by many, will take many hours to compile. This is a problem not just for the compilers and build-tools but of the language it self - the way includes, global lifetime etc works can force a compiler to translate the exact same files docents or even hundreds of times just to compile the project once. And templates are already costly as they are, if you then have constexpr too then yeah - the language forces the compilers to do a lot of work there. The answer also kinda goes against what the rest of the talk says: "Hey, with these changes you can save a lot of resources in the long run - but for compiletime no, we don't care".
"Engineering is programming integrated over time" -- Titus Winters. i need this quote framed somewhere (i am not a c++ dev lol, love you guys all the same)
I've been saying this for years (since I worked at Amazon in 2003/4/5). It's very gratifying to learn that this person has come to the same conclusion.
It was so frustrating to be stuck with an old version of RH and an old version of gcc at Amazon then. My argument then was that they should give developers desktops that had everything new, and a test environment that had all the old stuff. Stupid dependencies would get sanded off over time.
Depending on a particular version is really inefficient and terribly brittle. It's the wrong answer. I've always felt that way. I've really disliked tools for Python like virtualenv because they encourage a model I think is fundamentally broken.
True. I too worked at Amazon in 2015 and this thing hasn't changed.
At google we have we have all the developer machines always at head (by default). We can go back in time to a different past snapshot of "Google" which is never recommended and only done to reproduce/debug old issues. We can do all the development/testing/debugging locally and finally commit to make the "new head".
I worked at Amazon in 2015. I really didn't like the versioning and stupid dependencies among the different versions of different libraries.
Now I am at google and the developer experience is blissful
Concerning absl::Duration. Why not write a absl::int96 (or however you want to do your safe and saturating arithmetic), and then use std::chrono::duration? You could even type alias this to absl::Duration. The advantage of this technique is that now your absl::int96 work is available for all kinds of other needs, in addition to addressing a need in time keeping. And you assure your users that you are using a time-tested and familiar interface (chrono).
We could, but compiler messages would be more confusing, and then we're more reliant on QOI for standard library chrono support with alternative reps on every platform. We chose to keep it controlled, but honestly it probably boiled down to "we already have this and the two approaches are very close".
1:10:19 "I don't want you extending my types."
It's merely your library. It's MY app. If I want to accept the possibility of my app breaking in the future after updating to a newer abseil, that's my burden to gauge. UFC = 👍.
I hope Chandler is presenting this year!
Great talk. thanks google
Great talk Titus!
Google is great at many things... I like this
Great talk!
One question, if you can automatically change usage of some library in code base, then why you need to do this at all? This mean that this code base do not depends on most of this api. This is equivalent to crating couple of wrappers and use them in your code and change manually only this couple of function not whole code base.
Where does the name Abseil come from? I couldn't find that on Google (yet).
Just a guess since I don't work for Google, I think it's short for Alpha(B)et Standard Library. I'm guessing based on the purpose of the library and that ABSL is their chosen prefix.
It's mentioned in the follow-up talk "Hands-On with Abseil"
The library was originally abcl for abc library, but that couldn't go public for legal reasons. So they took the way people pronounced the name internally and invented a new spelling.
Programming. The act of creating programs
hearing the words at 1:23:10 is... well, disheartening. It is one of the problems that affect millions and costs a lot of resources during development.
"Buy another CPU" is not a solution for development - if you have the time and money to create large build-systems that are available to everyone ok. But if you need to change some parts of the code right then and there for say a live-hotfix.... yeah, it is not nice if you know that your small bugfix, cause it is in a template-heavy reagion linked by many, will take many hours to compile.
This is a problem not just for the compilers and build-tools but of the language it self - the way includes, global lifetime etc works can force a compiler to translate the exact same files docents or even hundreds of times just to compile the project once. And templates are already costly as they are, if you then have constexpr too then yeah - the language forces the compilers to do a lot of work there.
The answer also kinda goes against what the rest of the talk says:
"Hey, with these changes you can save a lot of resources in the long run - but for compiletime no, we don't care".
Thats my rational mind
I waited for 29 minutes to find out what "live at head" means. I have decided I don't need to know that badly.
41:49